Hi, thanks for sharing these problems.

.NET Core/Standard has a very different build model to .NET Framework in that it is heavily dependent on Nuget and associated tooling. Bindings to packages must be directed through the Nuget system as we cannot guarantee that a package is actually present on the machine responsible for the build. For this reason, NCrunch needs to invoke MSBuild to ensure packages are properly restored. If this step fails, there's quite a bit that can go wrong.

NCrunch is dependent on being able to invoke MSBuild.exe from the following location (varies slightly depending on VS SKU etc):
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe

This is done in the context of the NCrunch.EngineHost process.

In your environment, the O/S rejects the process invocation. This might be because the file is not in the expected place, or it is corrupt, or something is blocking the invocation (i.e. virus scanner, security settings, etc). Unfortunately I have no way to analyse this because it seems to be specific to your environment. I recommend checking that MSBuild is installed correctly and you're able to execute it via a non-administrative command line prompt. Also try temporarily disabling any security settings or scanners that may obstruct it.

The Nuget restore step executed indirectly by MSBuild also requires a network connection to Nuget to be able to restore the packages. There are things that can block this (i.e. security settings, firewall). This may not be a deal breaker if you already have the required packages installed, but NCrunch will likely warn you if it can't download packages that it might need downstream.



Can you confirm that you have the relevant version of the .NET Core SDK installed on this machine?



At this early stage of bootstrapping the engine, NCrunch doesn't yet know whether the xunit packages are required or not. They are listed internally as dependencies for NCrunch as a whole, because before we can load the necessary adapters to determine whether you're using xunit tests, we need to have every set up first. You can probably ignore this error. If you want to get rid of it, you can create a small sample project on your machine and add package dependencies to these packages so that Nuget will restore them into your package cache. Fixing the issue with MSBuild invocation/restoration will also likely fix this, because then NCrunch will just quietly restore these packages itself.


Edit: Can you also confirm that you're using the latest version of NCrunch and the latest version of VS2017?

Thanks for your patience here.

Something that I think would be worth trying on your machine is to create a small sample .NET Standard project with a .NET Core test project, then try running NCrunch over it and seeing if it fails.

This will help to determine whether the problem is triggered by something in your environment, or whether it's project specific. There is a possibility that it's being caused by a specific package or a referenced version of .NET Core/Standard.



This is absolutely a possibility. We have tested this scenario and to my knowledge it should work, but we don't test it as frequently as other use cases and the toolset is changing all the time. It may be worth installing a version of VS on the machine to see if this has any impact on the behaviour. If it does, we'll have a vital clue that might help us reproduce and resolve it.

We've had .NET Core and .NET Standard support in NCrunch for about two years now. This means that if there's a problem that's simple to analyse and/or is impacting many people, we're certain to have solved it already. The issues we're getting now tend to be more due to platform changes or very niche edge cases caused by less common configuration. This does, unfortunately, mean you are very unlucky. You've been hit with a problem that we haven't seen before and we haven't found a way to recreate it.

The only real way to progress from here is for you to deductively identify how to reproduce the problem in a sample solution. From there, we can almost certainly provide you with a fix or advice on how to resolve the issue. Sorry, if I had another option, I would honestly suggest it :(



This is very interesting. It says that the tool is first trying to use the build tools from VS2019 before it falls back to MSBuild 15 (which is VS2017). Have any VS2019 components ever been installed on this machine?



The Console Tool needs to perform a partial build to analyse the project file and resolve its dependencies. Under .NET Core, it also needs some level of platform integration to resolve packages. This does unfortunately introduce a dependency on MSBuild.



This is technically not an error message. When a build fails like this, NCrunch will cross-check the targets so that it might be more obvious when an SDK is missing on the machine. If you're confident you have everything you need already installed, then the information here is not useful.

Visual Studio has now been installed on the build agent.
That actually got rid of the NullReferenceException.
But now we get the same Win32Exception, quoted in my first post, I got on my own machine.


I didn't do anything on my own machine to fix this.
I just tried a small project as you suggested and it worked, after that it worked for our big project as well.
I only got a message indicating that the console tool could not access the folder where it writes its report, but the tests where executed.
I solved that by starting the console tool as administrator.
We never had that problem on the build agent (when it still worked, before we had any .NET Standard projects), so should not be a problem there.

As I didn't install or update any component on my machine and the grid node servers are the same, there must be something else missing on the build agent.
On my machine that was the step where the ncrunch console tool actually connected to the first grid node server.
What could be missing on the build agent that it throws this exception?

We hoped to get the regular NCrunch console tool report, but didn't get that, as the build ran into a timeout after 120 minutes.
TFS cancelled everything and the NCrunch report wasn't even created.

I have send the detailed output as logged in TFS via the contact form.
While it is far more detailed it unfortunately does not show the exception we get without the '-LogVerbosity Detailed' parameter.

I hope you see something in the log that will help us find a solution to this problem.

I just send the log with the verbosity medium via the contact form.
It took a while as the administrator got in just after I had the log and we decided to update NCrunch to the just released version and run the build again. (That didn't magically fix it.)

It shows the internal error on line 36643.

We have some other problems with the .NET Standard projects and a couple of guys that are not really happy with mixinig .NET Core/Standard with .NET Framework here.
So we decided that for now it is not worth the effort and will be going back to .NET Standard.
After that the NCrunch console tool will most likely not give us any more trouble.

If this is actually a problem in NCrunch and not our solution, I hope this will give you a clou as to what is going wrong and a way to fix it.

I just started a build with the /VS command line parameter.
The build is not done yet, but the NCrunch steps are done.
So the command line parameter worked.


It would be nice if the documentation of the console tool listed and explained the command line parameters.
There are two articles about the console tool in the documentation, but they both just link to the other one for details about the usage.

Tools/Console Tool: "For a full setup and usage guide, see the console tool usage guide."
Guides/Console Tool Usage: "For more detailed information about the tool, please refer to the console tool documentation."


The Win32Exception only happened once on my machine and once on the build machine.
So it seems to be some rare thing.
It seemed to happen just a bit later in the stack than the NullReferenceException.
So possibly the code somehow got past the point where the NullReferenceException happens and crashes two or three steps after that.


Thanks