Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
InvalidProjectFileException - regex cannot be evaluated
Options
Previous Topic Next Topic
lukesch
#1 Posted : Saturday, May 10, 2014 12:26:26 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/10/2014(UTC)
Posts: 13

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
I'm having trouble getting my project to build. A regex is failing to be evaluated. Looks like some issue about not using the c drive? Any idea?

NCrunch: If you are experiencing problems in getting this project to build, have a look at http://www.ncrunch.net/d...ng_project-build-issues
Microsoft.Build.Exceptions.InvalidProjectFileException: The expression "[System.Text.RegularExpressions.Regex]::Replace(c:\users\lukesch\appdata\local\ncrunch\26724\13\my\anonymized\path\foo.csproj, h:\\enlistments\\utah-ssd\\sources\\c:\users\lukesch\appdata\local\ncrunch\26724\13\my\anonymized\path\foo.csproj\\([^\\]+)\\.+, $1)" cannot be evaluated. parsing "h:\\enlistments\\utah-ssd\\sources\\c:\users\lukesch\appdata\local\ncrunch\26724\13\my\anonymized\path\foo.csproj\\([^\\]+)\\.+" - Insufficient hexadecimal digits. f:\CxCache\.MsBuild.Corext.awrN7H5j-hWFzJEfNTACZw\Environment.ex.props
at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
at Microsoft.Build.Evaluation.Expander`2.Function`1.Execute(Object objectInstance, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation)
at Microsoft.Build.Evaluation.Expander`2.PropertyExpander`1.ExpandPropertyBody(String propertyBody, Object propertyValue, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation, UsedUninitializedProperties usedUninitializedProperties)
at Microsoft.Build.Evaluation.Expander`2.PropertyExpander`1.ExpandPropertiesLeaveTypedAndEscaped(String expression, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation, UsedUninitializedProperties usedUninitializedProperties)
at Microsoft.Build.Evaluation.Expander`2.PropertyExpander`1.ExpandPropertiesLeaveEscaped(String expression, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation, UsedUninitializedProperties usedUninitializedProperties)
at Microsoft.Build.Evaluation.Expander`2.ExpandIntoStringLeaveEscaped(String expression, ExpanderOptions options, IElementLocation elementLocation)
at Microsoft.Build.Evaluation.Evaluator`4.EvaluatePropertyElement(ProjectPropertyElement propertyElement)
at Microsoft.Build.Evaluation.Evaluator`4.EvaluatePropertyGroupElement(ProjectPropertyGroupElement propertyGroupElement)
at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
at Microsoft.Build.Evaluation.Evaluator`4.Evaluate()
at Microsoft.Build.Evaluation.Evaluator`4.Evaluate(IEvaluatorData`4 data, ProjectRootElement root, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, ILoggingService loggingService, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCache projectRootElementCache, BuildEventContext buildEventContext, ProjectInstance projectInstanceIfAnyForDebuggerOnly)
at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation)
at Microsoft.Build.Evaluation.Project.CreateProjectInstance(ILoggingService loggingServiceForEvaluation, ProjectInstanceSettings settings)
at Microsoft.Build.Evaluation.Project.Build(String[] targets, IEnumerable`1 loggers, IEnumerable`1 remoteLoggers)
at Microsoft.Build.Evaluation.Project.Build(ILogger logger)
at nCrunch.VSIntegration2010.MSBuildIntegration.BuildableProject2010.Build(Boolean verboseLogging, IList`1 errors, IList`1 warnings)
at nCrunch.Compiler.RemoteBuildRunner.#=qaSoGvCxNvdw7HJsNBIudng==(ComponentBuildParameters #=q5emwq8yLNkycCnCOvVzwcQ==, IList`1 #=qGKXSCly11_a1gDkbn01C6A==, IList`1 #=qmsky7ZYB4orKMnsJL_jzJw==)
Back to top
Remco
#2 Posted : Saturday, May 10, 2014 12:30:08 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Hi,

Thanks for sharing this issue. It looks like the project above contains a build customisation that wasn't designed to work with the translated file paths used by NCrunch. Is this a project you've designed yourself? Or is it part of a wider toolset? Can you share the project element that contains the regex?
Back to top
lukesch
#3 Posted : Saturday, May 10, 2014 12:55:14 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/10/2014(UTC)
Posts: 13

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
My build team may have customized some things in the project file -- we're still using msbuild under the covers. Perhaps it's something about environment variable resolution. I don't know if $(VARNAME) is standard or if it's causing regex to choke. This is my project file:

Code:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="(- BROKEN LINK -)">
  <PropertyGroup>
  <MinorComp>Stages</MinorComp>
  </PropertyGroup>
  <Import Project="$(EnvironmentConfig)" />
  <PropertyGroup>
    <RootNamespace>Foo.Stages</RootNamespace>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <ProjectGuid>{DE405C25-F649-436E-AAE6-C72B18799E11}</ProjectGuid>
    <AssemblyName>Foo.Stages</AssemblyName>
    <OutputType>Library</OutputType>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="a.cs" />
    <Compile Include="b.cs" />
    <Compile Include="c.cs" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="System" />
  </ItemGroup>
  <ItemGroup>
    <Pass2Publish Include="$(TargetDir)\Foo.Stages$(TARGETEXT)">
      <TargetPath>$(DISTRIB_PRIVATE_BIN_PATH)\Foo.Stages$(TARGETEXT)</TargetPath>
    </Pass2Publish>
  </ItemGroup>
  <Import Project="$(ExtendedTargetsPath)\Microsoft.CSharp.targets" />
</Project>
Back to top
 |  Edit by user
Remco
#4 Posted : Saturday, May 10, 2014 11:27:58 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Thanks for sharing this code.

Your project build looks to be very, very heavily customised. I can try to help with getting this project building with NCrunch, but I should warn you that it's likely to be well outside the conditions under which NCrunch has been tested. NCrunch manipulates the build process fairly heavily, so custom builds can be difficult to support out of the box. I guess you could say that it's like trying to integrate with something that you've never seen before and cannot test against :) Assuming that the regex problem can be solved, I can't guarantee that we won't encounter other issues behind it.

As the call to System.Text.RegularExpressions.Regex]::Replace isn't shown above, I assume that this call resides within one of the included target files. Is there any chance you can show me this code? It looks as though it's making an assumption about the state of a file path variable that's being passed to it - an assumption that doesn't hold true under NCrunch's build. Something that would be useful is if it is possible to perform some analysis of the various inputs that arrive at the flawed path. If you can trace these back to their source input, then compare these source inputs with a non-NCrunch build process to identify the difference between them, I may be able to introduce a fix. NCrunch's build integration is intended to be as close to a normal build as possible, so the important thing here is to identify the precise element where it is different, then we have a chance at solving this problem.
Back to top
lukesch
#5 Posted : Monday, May 12, 2014 8:38:33 PM(UTC)
Rank: Member

Groups: Registered
Joined: 5/10/2014(UTC)
Posts: 13

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
You were right. This regex is coming from the imported environment f:\CxCache\.MsBuild.Corext.awrN7H5j-hWFzJEfNTACZw\Environment.ex.props

Can you make sense of what's happening here in the context of NCrunch?

Code:
  <PropertyGroup>
    <!-- Define required macros -->
    <InetrootRegex>$([System.Text.RegularExpressions.Regex]::Escape($(INETROOT)))</InetrootRegex>
    <GROUP>$([System.Text.RegularExpressions.Regex]::Replace($(MSBuildProjectFullPath.ToLower()), `$(InetrootRegex.ToLower())\\sources\\([^\\]+)\\.+`, `$1`))</GROUP>
    <MAJORCOMP>$([System.Text.RegularExpressions.Regex]::Replace($(MSBuildProjectFullPath.ToLower()), `$(InetrootRegex.ToLower())\\sources\\$(GROUP)\\([^\\]+)\\.+`, `$1`))</MAJORCOMP>
    <MINORCOMP Condition="'$(MINORCOMP)'==''">$(MSBuildProjectName)</MINORCOMP>
    <DISTRIB_ROOT>$(INETROOT)\DISTRIB</DISTRIB_ROOT>
  </PropertyGroup>
Back to top
Remco
#6 Posted : Monday, May 12, 2014 10:30:19 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Sorry, I think you might need to take this problem up with your build team. It looks like the purpose of this regex is to try and extract the name of a directory towards the end of a file path, but from just an extract of code I'm afraid that I'm not sure how to troubleshoot it for you. The values inside the regex depend upon other values further up in the build process, and it would take access to the entire end-to-end build along with the capability to run it normally in order to properly debug.

Considering that the paths seem to involve Inetroot, I wonder if this is some kind of deployment code? If so, maybe you can get away with disabling it for NCrunch.

Try adding the following condition to the PropertyGroup:

<PropertyGroup Condition="$(NCrunch) != '1'">
Back to top
lukesch
#7 Posted : Monday, May 12, 2014 11:15:41 PM(UTC)
Rank: Member

Groups: Registered
Joined: 5/10/2014(UTC)
Posts: 13

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
PropertyGroup condition was a good idea but it didn't work. I think you're right about the regex. I was able to get ncrunch to build by modifying it (see below). However I think ncrunch is now putting binaries into the same output dir as VS uses causing contention/locking issues. Is the goal to have ncrunch build into a different directory than VS? Mabe I can do something clever to make that happen.

Code:

  <PropertyGroup>
    <!-- Define required macros -->
    <InetrootRegex>$([System.Text.RegularExpressions.Regex]::Escape($(INETROOT)))</InetrootRegex>
    <GROUP>$([System.Text.RegularExpressions.Regex]::Replace($(MSBuildProjectFullPath.ToLower()), `.*?\\sources\\([^\\]+)\\.+`, `$1`))</GROUP>
    <!--GROUP>$([System.Text.RegularExpressions.Regex]::Replace($(MSBuildProjectFullPath.ToLower()), `$(InetrootRegex.ToLower())\\sources\\([^\\]+)\\.+`, `$1`))</GROUP -->
    <MAJORCOMP>$([System.Text.RegularExpressions.Regex]::Replace($(MSBuildProjectFullPath.ToLower()), `.*?\\sources\\$(GROUP)\\([^\\]+)\\.+`, `$1`))</MAJORCOMP>
    <!--MAJORCOMP>$([System.Text.RegularExpressions.Regex]::Replace($(MSBuildProjectFullPath.ToLower()), `$(InetrootRegex.ToLower())\\sources\\$(GROUP)\\([^\\]+)\\.+`, `$1`))</MAJORCOMP-->
    <MINORCOMP Condition="'$(MINORCOMP)'==''">$(MSBuildProjectName)</MINORCOMP>
    <DISTRIB_ROOT>$(INETROOT)\DISTRIB</DISTRIB_ROOT>
  </PropertyGroup>
Back to top
Remco
#8 Posted : Tuesday, May 13, 2014 7:55:44 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
That's great news - you're making good progress here. I don't think it will be difficult to adjust the build to output the binaries using a relative path. NCrunch must always output assemblies using a relative path, as absolute paths will do exactly what you've described - dump the files in the same place as Visual Studio.

Normally the output directory for the assembly is controlled by the 'OutputPath' MSBuild property. In most cases, this is handled via property declaration near the top of the .proj file. I think the key thing is to find out if the build customisations are impacting this value (or any important value derived from it, such as the 'OutDir' property) in order to override the output path.

The conditional structure I used above can be used to implement NCrunch 'hacks' anywhere in your build process. If your output path is defined using an absolute path, for example:

<PropertyGroup>
<OutputPath>c:\MyOutputs</OutputPath>
</PropertyGroup>

.. Then a solution may be as simple as:

<PropertyGroup>
<OutputPath Condition="$(NCrunch) == '1'">bin</OutputPath>
<OutputPath Condition="$(NCrunch) != '1'">c:\MyOutputs</OutputPath>
</PropertyGroup>
Back to top
1 user thanked Remco for this useful post.
lukesch on 5/13/2014(UTC)
lukesch
#9 Posted : Thursday, May 15, 2014 12:42:18 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/10/2014(UTC)
Posts: 13

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
I was able to get this working completely by making the regex changes above as well as fixing up the outputpath as you mentioned
Code:
  <PropertyGroup>
       <OutDir>$(TARGETDIR)\</OutDir>
       <OutputPath>$(TARGETDIR)\</OutputPath>
       <OutDir Condition="$(NCrunch) == '1'">$(MSBuildProjectName)\target\</OutDir>
       <OutputPath Condition="$(NCrunch) == '1'">$(MSBuildProjectName)\target\</OutputPath>
  </PropertyGroup>


Thanks so much for your help! I was able to demo this tool to my team and they thought it was awesome.
Back to top
Remco
#10 Posted : Thursday, May 15, 2014 1:16:27 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Excellent! Enjoy the product! :)
Back to top
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.072 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download