Out of the box (after fixing lot's of other errors with my project set up I didn't even know about before NCrunch =D), I get this cryptic error loading a project.
Errors occurred while trying to load the project file:
The target "_SplitProjectReferencesByFileExistence" does not exist in the project.
This project in particular actually has no code, so it shouldn't affect any test runs. It's used to hold media content files used in a web app.
Any ideas what might cause this and how I could fix it to make all projects "Build Successful"?
NCrunch makes use of this particular build target while loading projects and interrogating them for information. If the target isn't present, my guess would be that this project is custom designed and isn't making use of any standard .NET build targets (please do correct me if this guess is wrong - as I'd otherwise like to know which frameworks it may be using).
If the project doesn't contain any code, is it possible that no other projects are depending on it? If it contains no testable code, you're probably best to just switch it off with the Ignore this component completely configuration setting.
Seeing the age of this post, I'm surprised, but I'm hitting this error in the latest build of NCrunch v3.5, with a .NET Core library targeting .NET Standard 1.6 and .NET 4.6. In my case, this project contains code that is under test so I can't just ignore it.
The _SplitProjectReferencesByFileExistence problem appears when the build system doesn't contain the expected targets, which can happen if NCrunch doesn't properly recognise the target platform of the project being built. These problems have always been solved with functional fixes, so I guess the error itself was never improved.
The problem you're likely facing is that NCrunch isn't able to work with projects set to target multiple frameworks at the same time. This is a new .NET Core feature and it's rather complex, so it may take a few weeks to work out. For the time being, I recommend looking into alternative structures for your projects, such as 'shared' projects or two projects files sharing the same directory.
Remco wrote:The problem you're likely facing is that NCrunch isn't able to work with projects set to target multiple frameworks at the same time.
These projects were indeed multitargeting different frameworks, so I've just gone through the solution and removed all multitargeting from all the projects. However, the error seemed persistent, even after deleting all the NCrunch files in my working copy (The _NCrunch_Solution directory, all the .ncrunchsolution and .ncrunchproject files, and all the .ncrunch*.user files too).
I tried NCrunch out on a brand new solution, and obviously it worked just fine, but when I copy-pasted the contents of one of the project files exhibiting this error into one of my brand new project files, suddenly I started seeing the error in that project too. Paring the project file back to the barest minimum code didn't resolve the problem, and I couldn't see anything in the following that would cause this error:
[h]It turned out the problem was that I needed to change TargetFrameworks to TargetFramework.[/h]
It's interesting that this only causes a build error in NCrunch, and not in VS or the dotnet CLI tool. Might it be possible to catch this error and provide some guidance to the user on how to resolve it, or handle the situation more gracefully, like VS and dotnet CLI do?
alastairs wrote:
[h]It turned out the problem was that I needed to change TargetFrameworks to TargetFramework.[/h]
It's interesting that this only causes a build error in NCrunch, and not in VS or the dotnet CLI tool. Might it be possible to catch this error and provide some guidance to the user on how to resolve it, or handle the situation more gracefully, like VS and dotnet CLI do?
Good catch. I'll have to think carefully about this one. This is actually a surprisingly difficult thing to handle reliably under NCrunch because of the way MSBuild evaluation is handled. At the moment NCrunch actually needs to parse this out of the file before it can invoke any MSBuild logic, and the parsing needs to fall back onto the 'old' integration style for projects that don't declare the element. We're at the stage now where there are so many different project types now supported that placing an error for a missing element is almost certain to cause some other unknown project type to start failing.