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

Notification

Icon
Error
Required dlls/tools in nuget package not being copied for ncrunch
Options
Previous Topic Next Topic
jamesdill_bnp
#1 Posted : Wednesday, January 3, 2018 12:31:29 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 9/9/2016(UTC)
Posts: 1
Location: United Kingdom
We have roughly 200 projects which reference a range of nuget packages which have made our life difficult - this is due to adding target files which require extra information in the nuget package itself. This then causes NCrunch to fail as it doesn't copy the entire nuget package to the working area, and fails to find specific files.

I can see this is mentioned multiple times eg: here, and here, etc.

An example, using a common package Microsoft.Net.Compilers (rather then many of the inhouse ones that also cause problems), would be:
Quote:
..\..\..\Packages\Microsoft.Net.Compilers.2.4.0\tools\Microsoft.CSharp.Core.targets (84, 5): The specified task executable location "C:\Users\username\AppData\Local\NCrunch\22412\77\Packages\Microsoft.Net.Compilers.2.4.0\build\..\tools\csc.exe" is invalid.


The solution that has always been suggested is to add "Additional Folders" to each project. The result of this is a huge amount of overhead, adding the references to each project, and maintenance issues when upgrading as the specific versioned directory needs to be re-added across all the projects. It also causes a large increase the NCrunch workarea size considerably (up to 30 GB sometimes), although not as critical as the maintenance concerns.

The change log for 3.12 has an item which I had hoped would fix this, and mean we can stop using these work arounds. This doesn't seem to be the case, and my question is, am I using anything incorrectly? Is there anything else / new we can do that would prevent using "Additional Folders"?

Change log I'm referencing is:
Quote:
Restructured NCrunch's handling of Nuget package directories so that these are no longer considered fixed to the
User\.nuget\packages directory, as it is now clear that Nuget package directories can be separately configured on a per-project
basis and can be in a range of different places depending on the install state of the machine. NCrunch should now also be able
to properly deal with multiple package directories. This should resolve a range of problems related to package discovery at
runtime, especially when using NCrunch over a grid or when automatically transferring packages to remote grid nodes.
Back to top
 |  Edit by user
Remco
#2 Posted : Thursday, January 4, 2018 12:42:38 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,976

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Hi James,

Thanks for posting!

As you probably know, NCrunch works by extracting your projects from your 'foreground' solution into isolated sandboxes, where it can then build them and link them together into runtime environments. For NCrunch's features to work correctly, it's important that each extracted project can be represented in the sandbox/workspace completely independently and it does not reference outside its isolated directory. This means that unless build dependencies are represented globally (i.e. under 'Program Files', 'User\.nuget', GAC, etc), there must be a copy made for each dependency that can be referenced by the isolated project relatively in its own workspace.

In this case, it looks as though your projects are making use of the Microsoft.Net.Compilers package as stored under the solution directory, referenced using a relative path through Nuget's packages.config file. For NCrunch to be able to have only one copy of the Microsoft.Net.Compilers package or for it to try and reference this from the foreground solution, it would need to reach into your build structure and rearrange the nuget referencing system to rewrite the path references. This would break a number of abstractions in nuget/msbuild, and just wouldn't be feasible to stabilise across all packages and on all versions of Nuget. So it isn't really possible to solve this inside NCrunch itself.

This means that you have three options here:

1. Continue as you are, with NCrunch making a copy of Microsoft.Net.Compilers for each project workspace. You may be able to trim down the range of files being copied by being more selective with your 'Additional files to include' setting. It's possible that not all the files in the Nuget package are required for the package to work at build time.

2. Change your project (.proj) files to avoid referencing Microsoft.Net.Compilers using a relative path, instead referencing it using an absolute path. NCrunch then won't need to have it stored in the workspace using a relative path and won't need it copied.

3. Stop using packages.config and use PackageReference instead. MS tooling is presently moving away from packages.config, so this is the option I would recommend.

The 3.12 change was applicable to PackageReference (not packages.config, which do not exist in a global space).
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.033 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download