Sorry, this was my mistake. I sent you the link to download the runtime of .NET 6.0, when actually it seems we needed the SDK. Try the one below instead:
https://dotnet.microsoft.com/download/dotnet/thank-you/sdk-6.0.100-windows-x64-installer

Thanks for confirming this.

The next step is to try and see if we can build the project on your grid node without NCrunch involved. Please try the following steps:

1. Copy your test solution to the grid node to a temporary directory
2. Find the installed instance of msbuild.exe on your grid node (usually something like 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin' or the build tools equivalent)
3. Open a command prompt to your temporary directory containing the test project
4. Perform a package restore step for the test project using MSBuild, for example:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild" MyTestProject.csproj /t:Restore
5. Execute msbuild.exe over the test project, for example:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild" MyTestProject.csproj

Is MSBuild able to build the project correctly?

Thanks for sharing these details.

The error confirms that this is a platform install issue and is not specific to NCrunch. The installation of MSBuild on this machine is unable to find the correct install path of the DotNet targets.

In theory, if you can solve the install issue and the project builds using MSBuild, NCrunch should then be able to work with your project without problems.

Unfortunately, we cannot offer support for issues that are not caused by problems within NCrunch, but this might be something worth taking a look at: https://github.com/dotnet/msbuild/issues/2532.

Great to hear!



Most of the newer tooling was built for later versions of the Dotnet SDK. It doesn't surprise me that there are problems now using VS2019 tools with earlier versions of .NET Core. I would recommend leaving v6 of the SDK installed for stability reasons.



I was unable to reproduce this issue in any of our environments. I would recommend making the environment variable fix standard in all of your grid nodes if you're concerned about this issue. I doubt this fix will cause any side-effects, and it might save you trouble if the environments start producing the same problem.

Hi Remco,

It seems that updating VS2019 Build Tool to 16.11.7 build has fixed the issue with NCrunch.

BTW I tried to make the test running MsBuild via prompt and it gives an error instead. Anyway, just FYI, if you want to take a look at the details you can find them here

Hi, thanks for sharing these details.

The error itself seems to be caused by the build system being unable to resolve netstandard.dll, which is usually situated in either the Nuget package cache on the machine or one of the various SDK directories.

Again, I cannot reproduce this problem on my side, which makes it hard to give firm guidance on how to resolve it.

Looking at the log, it seems that 5.0.403 is the Dotnet SDK version being used on the grid node. Could you check whether this is consistent with the most recent version of the installed SDK on your client machine? I'm wondering if this issue could be caused by a difference in installed SDK versions between the machines. Given the history we've had with your environments it might be a good idea to have all your systems running on Dotnet v6.0.100.

Could you please send through a new log produced with the 'Build log verbosity' NCrunch setting set to 'Diagnostic' on your client machine? This will add detailed information about package and assembly resolution activities occurring inside the build and may be quite revealing (I would also recommend examining this log yourself when experiencing build issues).

I've spent the last two days trying to set up an environment to reproduce the issue you've described. Perhaps needless to say, I'm not impressed with the stability of the platform involved here.

Here are my current conclusions when attempting to build projects using the MSBuild tools for VS2019 and Dotnet 6.0.100 on a clean installation of Windows 10:

- The standard installer for the MSBuild Tools does not actually install the latest version of this toolset. After installing it, you need to go back into the installer and deliberately update the product

- Setting the MSBuildSDKsPath environment variable to "C:\Program Files\dotnet\sdk\6.0.100\Sdks" is absolutely required and the toolset will not work without this

- When installing the MSBuild tools, it's important to select a range of different workloads that might be relevant to the projects you attempt to build. If you don't do this, the tools won't build _any_ projects at all, even if they are ubiquitous (i.e. netstandard)

- You absolutely must perform the 'msbuild.exe myproject.csproj /t:Restore' step on the netstandard project on the machine prior to attempting to build these projects either directly or through NCrunch. Most of the required files won't be installed by the .NET SDK or MSBuild tools even if they're always needed, and they need to be pulled down over a network via Nuget using a restore step before they will be present on the machine. NCrunch generally tries to copy SDKs it expects will be required but the install paths and dependency patterns of platform SDKs have become so complex and varied that it is not recommended to rely on this.

After following the above steps and installing the NCrunch grid node, the node was able to successfully build the sample netstandard protobuf project you provided on behalf of a VS2019 client using v6.0.100 of the Dotnet SDK. I did not experience the package resolution error shown in your log files.

My suspicion at the moment is that there are critical files missing from your "C:\NCrunch Grid Node\Snapshots\.nuget" directory. It might be worth cleaning out this directory to see if resyncing with the client resolves the problem. Otherwise, you might be able to transfer over a clean set of packages from another location, such as the .nuget directory under the current user profile on the machine, or one of the client machines that can already build these projects under NCrunch.

Thanks for showing this. When you perform a /t:Restore in the NCrunch workspace, you are replacing the platform bindings in the workspace with new bindings that are set up for the grid node. This isn't a solution we can implement in NCrunch, as it significantly slows the build system on the nodes and also requires the nodes to have an active internet connection to external servers (which we try to avoid).

The fact that it fixes the issue is something I find interesting though. Would it be possible for you to share a copy of all the files in the workspace before and after you do this action? I'd like to see how the bindings compare. We may be able to narrow down the problem by making selective changes to the bindings.

Thanks! This is extremely interesting. The protobuf-net.csproj.nuget.g.props file contains a number of paths that don't appear to have been correctly mapped by NCrunch. It's not clear to me yet why this fails in your environment but not others. I'm going to take a deeper look at this and will get back to you.