We've got a T4 template that is generated as part of the build. In 3.17 this worked fine, but in 3.18 we are getting the following error
..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\TextTemplating\Microsoft.TextTemplating.targets (340, 5): An Exception was thrown while running the transformation code. The process cannot continue. The following Exception was thrown:
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.CodeAnalysis, Version=2.8.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.CodeAnalysis, Version=2.8.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
at Microsoft.VisualStudio.TextTemplating.CompilerBridge..ctor(String source, Boolean debug, IEnumerable`1 references, String cmdLineArguments)
at Microsoft.VisualStudio.TextTemplating.CompilerBridge.Create(SupportedLanguage language, String source, Boolean debug, IEnumerable`1 references, String cmdLineArguments)
at Microsoft.VisualStudio.TextTemplating.TransformationRunner.Compile(String source, String inputFile, IEnumerable`1 references, Boolean debug, SupportedLanguage language, String compilerOptions)
Is there any setting that may have changed regarding the way package folders are pulled into the build?
Our template runs a process that comes from an exe loaded as a nuget package, so maybe the environment is no longer seeing that process as run from the correct folder?
The VS and MSbuilds are completing and generating code correctly, only the NCrunch build is failing.
I can't think of any changes in v3.18 that could be directly responsible for this issue. But the error itself is interesting. The TextTemplating build task under the directory mentioned above seems to have a dependency on Microsoft.CodeAnalysis v2.8, but the file isn't actually collocated with the TextTemplating binaries. Which means that this task has been engineered with the assumption that the Microsoft.CodeAnalysis.dll file is sitting in a search path for the build process. This means the file would probably need to be either in the build directory itself, or otherwise installed in the GAC.
Does turning on the 'Copy referenced assemblies to workspace' setting make any difference in the behaviour you're seeing? Have you had any other changes on your machine other than installing v3.18?
smitchamb wrote:I downgraded and it is still happening, so i must be something in the project related to the code analysis stuff.
It's not clear to me here what the difference is that causes this to happen in your NCrunch environment and not in others. But resolving the problem should hopefully be as simple as copying the missing binary into the same directory as the .targets file ("Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\TextTemplating") or otherwise installing it in the GAC.
Alternatively, if you're able to share with me a sample project that can demonstrate the issue (you can upload code through the contact form), I can look a bit deeper and try to figure out why this is happening.
I had recently updated to VS 15.7.6 and now I've updated to 15.8 and my other NCrunch problems are failing to build. Prior to 15.8 this project worked fine. No code changes or other configuration changes have been made.
WARNING - ..\..\..\..\program files (x86)\microsoft visual studio\2017\professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets (2110, 5): MSB3245: Could not resolve this reference. Could not locate the assembly "Microsoft.Win32.Primitives, Version=4.0.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
Again, the builds work fine and the resharper test runner is able to run these tests fine.
It's looking to me like MS have changed some of the assembly resolution logic inside MSBuild as part of the 15.8 update. I've just done some testing on my end to try and reproduce this using the bug report you sent through, but so far I've had no luck in getting it to fail. Is there any chance you can share a minimal code sample that can produce this problem?
The original error has been confirmed in VS 15.7.6 with NCrunch 3.14 and 15.7.5 with NCrunch 3.12. I haven't had a chance to make a minimal implementation of that either, but I'll try to get both tomorrow. I'm pretty crippled without NCrunch.
https://bit.ly/2nIMWBr this link has a zip file with a minimal solution that exposes the issue. I've removed all the nuget packages except for Microsoft.* and System.* and Newtonsoft.Json because ASP.NET depends on it.
Thanks! It looks like this reproduces the problem for me (System.Net.Http resolution). I'll let you know as soon as I have more information. You can remove the download link if you're uncomfortable about having this code online.
I've managed to find a solution to this problem. The issue comes from a change introduced in VS 15.8 that forcefully redirects assembly references out to shim assemblies in a different location of the disk. From what I can tell, this appears to affect projects that make use of .NET Standard libraries. The redirection also seems to happen inside NCrunch's loading of projects, so it confuses NCrunch's view of which dependencies are actually required for the project and where they should be referenced from.
I'll publish a build fairly shortly with a fix included ... I'm going to hold it for a few hours to see if there's a way to include a fix for a different VS 15.8 issue in the same build.
Note that this build does change the grid protocol. If you're running grid nodes, you'll need to update them before you can use them with a v3.19 client.
I loaded 3.19, and in my full project I'm still getting some issues, but only in the Test projects.
One project builds, but fails at runtime due to being unable to find System.Net.Http, other projects are still failing to build. I'm going to dig a little more and then update here.
It looks like this change is related to including System.Runtime nuget package 4.3.0 which has an assembly version of 4.2.1. The projects are actually getting their version from the Visual Studio directory. The version in the NCrunch directory has an assembly version of 4.1.1.0
An error occurred while analysing this project after it was built: System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ---> System.IO.FileNotFoundException: Could not load file or assembly 'file:///C:\Users\smitcham\AppData\Local\NCrunch\83660\7\_ncrunchreferences\System.Runtime.dll' or one of its dependencies. The system cannot find the file specified.
File name: 'file:///C:\Users\smitcham\AppData\Local\NCrunch\83660\7\_ncrunchreferences\System.Runtime.dll'
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)
at System.Reflection.Assembly.LoadFrom(String assemblyFile)
at nCrunch.Common.CustomAssemblyResolver.(IEnumerable`1 , ParsedAssemblyName )
at nCrunch.Common.CustomAssemblyResolver.ResolveAssembly(ParsedAssemblyName parsedAssemblyName)
at nCrunch.Common.CustomAssemblyResolver.(Object , ResolveEventArgs )
at System.AppDomain.OnAssemblyResolveEvent(RuntimeAssembly assembly, String assemblyFullName)
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
Thanks for sharing these details. The v3.19 build above includes a change that turns off the redirection of assemblies to the VS directory during NCrunch's load of the project, since this was interfering with the identification of the 'true' assemblies being referenced. From our testing and on the sample project that you provided, this looked to have resolved the issue and any downstream problems ... but it seems now like that isn't the case..
Is there any instruction you can give me on how to modify your sample project to produce these other problems? I would hope that it should be possible to get this to work without the 'Copy assembly references to workspace' issue, since this will inhibit your build performance.
smitchamb wrote:I'll see if I can cut down the project again leaving one of the test projects in place that is failing and post it.
Thanks :) Sorry, I hate asking people to do this. I had a go at arranging a few dependencies around the sample you gave me to try and produce the problem, but had no luck. Maybe this is tied to specific dependencies.
Another user has reported an issue that seems very similar and is probably the same thing. I'm wondering if you'd like to try the build below to see if this solves the problem for you.