Hi, thanks for sharing this problem.

Generally, it's recommended to avoid absolute file path references like this one as it can cause problems with some things, like grid processing.

However, I've tried testing this with a simple scenario in which the assembly is stored on a different disk to the project file, and confirmed that NCrunch does still handle this scenario correctly by copying the file into the workspace and updating the reference in the generated file.

Is this file being referenced from inside a Nuget package directory that has been redirected to a different location? If so, there is a possible chance that NCrunch is considering the reference to actually be a Nuget package, in which case it would step away from trying to introduce the AssemblyReference inside the generated file because this is normally handled downstream by Nuget package references. If this is indeed the case, I recommend either replacing your Reference with a PackageReference or moving the file outside the Nuget package directory.

I'm sorry, but I cannot think of a way to allow you to resolve this problem without changing your build system.

NCrunch sits on top of a very complex platform consisting of layers of interaction between Nuget and MSBuild. In broad terms, a reference to an assembly is either done via Nuget or it's done through a direct assembly reference. Somehow, you've managed to create a reference that is technically both things at the same time, and NCrunch does not have a way to handle such a situation.

If the reason you're not able to move this assembly is because of compatibility with builds outside of NCrunch, the best I can suggest would be to add an environment variable that is used to specify the location of the assembly. You can then set this to a different location under NCrunch using the Custom environment variables setting.

If you're using a system with a centralised cache of assembly references, many of which happen to also be Nuget packages, you could try splitting the centralised cache into two separate directories - one for Nuget package assemblies and one to contain non Nuget packages that are centrally referenced using AssembyReference. In this way, the assembly can stay located outside the configured Nuget package cache while still being centrally stored and addressed.

Can you try setting the NUGET_PACKAGES environment variable on your machine to a different path to see if this makes any difference? (You'll need to restart VS before this will take effect).