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

Notification

Icon
Error
Target "_SplitProjectReferencesByFileExistence" cannot be found in customized projects.
Options
Previous Topic Next Topic
robmen
#1 Posted : Wednesday, May 6, 2015 8:18:11 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/6/2015(UTC)
Posts: 23
Location: United States of America

Thanks: 4 times
Was thanked: 1 time(s) in 1 post(s)
I'm trying out NCrunch on the WiX toolset's build. We do some pretty advanced things in our MSBuild projects to ensure consistency across the many, many projects that make up the WiX toolset. It seems one (or more) of those advanced tricks are confusing NCrunch. We get the following error that seems to be common for those that customize their project files:

Quote:
System.Exception: An exception was thrown in the remote environment: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> nCrunch.Common.UserException: Errors occurred while trying to load the project file:
The target "_SplitProjectReferencesByFileExistence" does not exist in the project.
at nCrunch.Compiler.RemoteBuildRunner.(FilePath ,   , String , String , DirectoryPath , String )
at nCrunch.Compiler.RemoteBuildRunner.AnalyseComponentBuild(FilePath projectFilePath, BuildXml buildXml, String useBuildConfiguration, String useBuildPlatform, DirectoryPath solutionDir, String solutionName, List`1 importExpressionsToEvaluate)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at nCrunch.TaskRunner.Ipc.IpcMessageProcessor.(CallMethodMessage )
at nCrunch.TaskRunner.Ipc.IpcMessageProcessor.ProcessMessageReturningResult(Byte[] data)
at nCrunch.TaskRunner.Ipc.RemoteInstance.[T](Byte[] )
at nCrunch.TaskRunner.Ipc.RemoteInstance.Invoke(IMessage msg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at nCrunch.Compiler.IRemoteBuildRunner.AnalyseComponentBuild(FilePath projectFilePath, BuildXml buildXml, String useBuildConfiguration, String useBuildPlatform, DirectoryPath solutionDir, String solutionName, List`1 importExpressionsToEvaluate)
at nCrunch.Core.BuildManagement.BuildProcessLauncher..(IRemoteBuildRunner )
at nCrunch.Core.BuildManagement.BuildProcessLauncher.(Action`1 , ProcessorArchitecture , GridClientId , IBuildableProject , CustomEnvironmentVariable[] )
at nCrunch.Core.BuildManagement.BuildProcessLauncher.AnalyseComponentBuildInExternalProcess(FilePath projectFilePath, BuildXml buildXml, String useBuildConfiguration, String useBuildPlatform, DirectoryPath solutionDir, String solutionName, List`1 importExpressionsToEvaluate, ProcessorArchitecture processorArchitecture, VisualStudioVersion vsVersion, CustomEnvironmentVariable[] customEnvironmentVariables)
at nCrunch.Client.ComponentLoader.SnapshotComponentFactory.(ProcessorArchitecture )
at nCrunch.Client.ComponentLoader.SnapshotComponentFactory.CreateSnapshotComponentFromXml(FilePath projectFilePath, BuildXml projectXml, FilePath solutionFilePath, String[] additionalFilesToIncludeAtSolutionLevel, Boolean isLoadedFromFile, ISnapshotConfig snapshotConfig, VisualStudioVersion vsVersion)


I tried building some of our projects using the simple command: "msbuild -t:_SplitProjectReferencesByFileExistence". It always worked. So, the target is available in our projects as long as the Imports are fully resolved. I'm a bit at a loss how to debug the issue any further. Verbose logging to the output window is not providing anything obviously useful.

If you'd like to reproduce the issue, you can get the projects from "https://github.com/wixtoolset/wix4". I'm attempting to enable NCrunch on the "src\Wix.sln".

I'm hoping there is a fix somewhere (either a reasonable fix to our MSBuild files or additional handling in NCrunch). I'm considering getting licenses for my entire company but loading the WiX toolset projects is fundamental to our work and most of our other projects use an MSBuild structure that is the similar as the WiX toolset's (and experience the same NCrunch issue described above).

If there is additional information I can provide, do let me know. Thanks.
Back to top
Remco
#2 Posted : Wednesday, May 6, 2015 8:54:35 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Hi,

I wish I had a quick and simple solution to this, but in truth it depends entirely on what you are trying to achieve, and whether it is actually possible to achieve it using NCrunch.

NCrunch was designed and tested against specific project types as derived from VS project templates, such as C#, VB.NET, F#, etc. It hasn't been tested against custom project structures because ... well ... there's no way to know how they're customised.

Projects are expected to export specific build targets, most importantly targets that are declared inside Microsoft.Common.targets. This targets file also contains the declaration for _SplitProjectReferencesByFileExistence, which explains why the error message you are receiving is usually caused by projects that are experiencing problems importing their major dependencies.

I may be able to give more information about which targets are expected by NCrunch, but I feel you should know what you're up against. You're walking in uncharted territory.

What is the reason for the customisation of your projects? Do they contain code in any published .NET language? Do they have a project referencing structure? Are they required in order to run your tests, or is it possible to just ignore the customised projects and continue to build and run tests over the rest?
Back to top
robmen
#3 Posted : Wednesday, May 6, 2015 9:23:29 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/6/2015(UTC)
Posts: 23
Location: United States of America

Thanks: 4 times
Was thanked: 1 time(s) in 1 post(s)
Remco;7279 wrote:
I may be able to give more information about which targets are expected by NCrunch, but I feel you should know what you're up against. You're walking in uncharted territory.


Well, that's not very encouraging. <smile/>

Remco;7279 wrote:
What is the reason for the customisation of your projects? Do they contain code in any published .NET language? Do they have a project referencing structure? Are they required in order to run your tests, or is it possible to just ignore the customised projects and continue to build and run tests over the rest?


At quick count, there are 79 .csprojs and 32 .vcxprojs that define the product (i.e. not counting test projects). To standardize the build configuration for all of those projects, they all import build files from [root]\Tools\. When we need to make a build configuration change, we make a single change in the appropriate .props or .targets file and all the projects are updated.

Adding a new project is also simple. Remove most the default stuff VS project templates provide (not the AssemblyName <smile/>), add a reference to [root]\Tools\WixBuild.targets (via this: "$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildProjectDirectory), wix.proj))\tools\WixBuild.targets") and you know you have the correct configuration. It is very easy to maintain.

We did the work to make sure everything is "just MSBuild". The projects all open and build within Visual Studio without issue. The projects all build from the command-line MSBuild exactly the same. I was encouraged that NCrunch seemed to be MSBuild based and hoping this issue would boil down to NCrunch not loading all of the Imports. Note that our Imports are not dynamically generated but do have properties in them that are resolved by the properties present in the project, props, and/or targets files. In the end everything ends up Importing Microsoft.Common.targets which is why I can do "msbuild -t:_SplitProjectReferencesByFileExistence" from the command-line on any of our projects.

It'd be really cool if you had a half hour or so and could try loading our "src\Wix.sln". If there is something we could do to simplify the Imports but keep the centralization of configuration (the most important [aka: vital] feature of our current MSBuild design), I could look into that. Right now I just don't have any information to know how to even start tackling the problem.

Or I suppose you could say that you're not interested in dealing with customized projects with NCrunch. I would understand that and drop the whole thing. <smile/>
Back to top
Remco
#4 Posted : Wednesday, May 6, 2015 9:32:15 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Ok - this information really helps .. and I think that this problem may well be caused simply by NCrunch's inability to resolve your custom .targets files. There are some known issues with parsing using expressions such as $([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildProjectDirectory), wix.proj))\tools\WixBuild.targets") in project import tags under NCrunch (which have sadly proved to be unfixable given the current state of MSBuild).

This means a solution to the problem may be as simple as ensuring your [root]\Tools directory is included in the NCrunch workspace. Try adding it to the 'Additional files to include' NCrunch solution-level configuration setting to see if this makes any difference.
Back to top
robmen
#5 Posted : Wednesday, May 6, 2015 4:36:23 PM(UTC)
Rank: Member

Groups: Registered
Joined: 5/6/2015(UTC)
Posts: 23
Location: United States of America

Thanks: 4 times
Was thanked: 1 time(s) in 1 post(s)
Remco;7281 wrote:
This means a solution to the problem may be as simple as ensuring your [root]\Tools directory is included in the NCrunch workspace. Try adding it to the 'Additional files to include' NCrunch solution-level configuration setting to see if this makes any difference.


Unfortunately, I did try that. I did find and read through all the documentation related to the error message, like http://www.ncrunch.net/document...atform-and-configuration (from your previous posts here, thanks <smile/>). So I tried using the "Additional files to include" and added lots of different combinations of our base files. I wasn't getting any feedback from NCrunch logging so I was basically wandering around in the dark. <smile/>

If you wanted, I'd be happy to screen share what I was doing some 30 minutes (I'm often up late PDT so I could hit a NZ/AUS timezone) but, again, you may need to debug NCrunch a bit because I wasn't seeing anything in log.
Back to top
Remco
#6 Posted : Wednesday, May 6, 2015 9:46:25 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Something also worth trying is to swap out the $([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildProjectDirectory), wix.proj))\tools\WixBuild.targets") expression with a simple relative path just to see if this is the cause of the problem. Does this make any difference?
Back to top
robmen
#7 Posted : Wednesday, May 6, 2015 11:05:19 PM(UTC)
Rank: Member

Groups: Registered
Joined: 5/6/2015(UTC)
Posts: 23
Location: United States of America

Thanks: 4 times
Was thanked: 1 time(s) in 1 post(s)
Remco;7288 wrote:
Something also worth trying is to swap out the $([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildProjectDirectory), wix.proj))\tools\WixBuild.targets") expression with a simple relative path just to see if this is the cause of the problem. Does this make any difference?


Unfortunately, no change. Is there some way to see the workspace and project that NCrunch is trying to load? I'm able to do "msbuild -t:_SplitProjectReferencesByFileExistence" in all these changes I've made. What is NCrunch seeing?
Back to top
Remco
#8 Posted : Wednesday, May 6, 2015 11:12:13 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Taking another look at the error, it seems that the error is being thrown at load time rather than build time. This means that NCrunch is basically just trying to open the project in its original location using the MSBuild API.

I've taken a look at the source code you've linked to. Unfortunately the code won't build in my environment (I have too much pre-release MS software installed for it to function), but I've tried to run through it as best I can. Looking at the extent of the customisations, I honestly don't think this solution is worth the fight. The entire build system has been replaced with many dependencies and high complexity. Even if we can get these projects to load, I don't think you'll ever get the builds and tests to run in a meaningful way without heavily redesigning the solution. Sorry, I don't think I can help you on this one.
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.071 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download