I am setting up a new clean build server (TeamCity) with NCrunch console and am struggling a bit to make NCrunch play nice (dotnet build works fine).
1) Restore before build: Should the integration server always use use dotnet restore on netCore projects, and nuget restore for non-netCore projects, before NCrunch is invoked (maybe related to item 2 below?) ?
2) NCrunch package restore NCrunch reports "because package restore mode is disabled", is there a way to enable it and is this related to item 1 above somehow?
[InitialisationQueueTask-150] Not restoring NuGet packages for 'D:\TeamCity\buildAgent\work\....UnitTest.csproj' because package restore mode is disabled
3) /VS 2019 when no MsBuild16 exists: When I specify /VS 2019 as parameter so it hopefully uses MsBuild v16 (which is required by netCore v2.1.802),
[Core-15] Beginning end-to-end run of solution using tools from VS version 'VS2019'
but when running on a build agent without MsBuild16 installed, I get NCrunch build error
.csproj: 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:
[10:19:54][InitialisationQueueTask-69] The target "_SplitProjectReferencesByFileExistence" does not exist in the project.
[10:19:54][InitialisationQueueTask-69] at nCrunch.Compiler.ComponentAnalysisContext. ()
Nothing from NCrunch states that it cannot find "vs 2019 build tools" or whatever it needs to build projects. If I run it on an agent with MsBuild16 installed it works fine.
Expected: NCrunch at least emit some sort of warning that it cannot find "/VS 2019" related stuff.
4) With TeamCity, I can in a build config define which build agents are compatible by using e.g. the MSBuild parameter (see picture below).
When using NCrunch however I only have "/VS" switch, and that is troublesome since no build agent has "visual studio" installed but rather build tools/msbuild.
Is there a way I can use this MsBuild path to NCrunch instead of using a "VS" switch?
[img=https://i.imgur.com/ZX79NS2.png]TcAgentParameters[/img]
GreenMoose wrote:
1) Restore before build: Should the integration server always use use dotnet restore on netCore projects, and nuget restore for non-netCore projects, before NCrunch is invoked (maybe related to item 2 below?) ?
Yes. Prior to running NCrunch over your solution inside your build, you should always perform a restore step on the solution itself.
In older versions we used to do this while loading projects, but it proved to be extremely inefficient to do this and was better done inside the user's build system itself. So we deactivated it.
GreenMoose wrote:
2) NCrunch package restore NCrunch reports "because package restore mode is disabled", is there a way to enable it and is this related to item 1 above somehow?
[InitialisationQueueTask-150] Not restoring NuGet packages for 'D:\TeamCity\buildAgent\work\....UnitTest.csproj' because package restore mode is disabled
This is a leftover message from when we used to do this automatically. Presently there is no configuration setting to turn the package restore mode on, as we couldn't really see why anyone would want it.
GreenMoose wrote:
3) /VS 2019 when no MsBuild16 exists: When I specify /VS 2019 as parameter so it hopefully uses MsBuild v16 (which is required by netCore v2.1.802),
[Core-15] Beginning end-to-end run of solution using tools from VS version 'VS2019'
but when running on a build agent without MsBuild16 installed, I get NCrunch build error
.csproj: 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:
[10:19:54][InitialisationQueueTask-69] The target "_SplitProjectReferencesByFileExistence" does not exist in the project.
[10:19:54][InitialisationQueueTask-69] at nCrunch.Compiler.ComponentAnalysisContext. ()
Nothing from NCrunch states that it cannot find "vs 2019 build tools" or whatever it needs to build projects. If I run it on an agent with MsBuild16 installed it works fine.
Expected: NCrunch at least emit some sort of warning that it cannot find "/VS 2019" related stuff.
Thanks, I think we can improve on this. We'll take a look :)
GreenMoose wrote:
4) With TeamCity, I can in a build config define which build agents are compatible by using e.g. the MSBuild parameter (see picture below).
When using NCrunch however I only have "/VS" switch, and that is troublesome since no build agent has "visual studio" installed but rather build tools/msbuild.
Is there a way I can use this MsBuild path to NCrunch instead of using a "VS" switch?
[img=https://i.imgur.com/ZX79NS2.png]TcAgentParameters[/img]
Presently, MSBuild is being versioned alongside VS itself. Historically, this hasn't always been the case. However, there is more to NCrunch's environment than just MSBuild. We do have a number of internal workarounds and code targeted to specific cases that behave differently under different versions of VS. Given that the primary use case of NCrunch is still as a Visual Studio plugin, the ability to differentiate behaviour based on VS version still makes more sense from an implementation standpoint than selecting a version of MSBuild. However, I do understand that it seems pretty weird to be passing in a /VS parameter when you don't have VS installed on the machine and you only really care about MSBuild. Part of the issue here is that the console tool still owes its roots to an engine that was originally only intended to be used as part of VS.
The code that searches for the build system should usually be able to find the MSBuild tools in place of VS. You might be interested to know that the method of finding these tools is actually the same as VS (they are internally represented as a version of VS). If this discovery code doesn't work, you can override it by setting the environment variable 'NCrunchVSInstallPath.VS2019' to the directory 3 levels below the path containing MSBuild.exe. So for example, if your MSBuild is at 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin', then you would set this value to 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise'.