BadImageFormatException: Microsoft.Build.Tasks.CodeAnalysis

[phmonte]

BadImageFormatException: Microsoft.Build.Tasks.CodeAnalysis

[jp2masa]

The x86 version of the .NET Core SDK probably ships a x86 version of Microsoft.Build.Tasks.CodeAnalysis.dll, I think that it wouldn't work if it was x64.

[daveaglick]

@jp2masa I moved your second issue regarding resource loading problems to #11 - please continue the discussion on that issue there. I'm going to keep this one focused on bitness of the MSBuild libraries and plan to resolve that specific issue soon.

[daveaglick]

Can you please try commenting out this line:
https://github.com/daveaglick/Buildalyzer/blob/119b9cc55ba402ef67d211e9df86d0c5aa784ff9/Buildalyzer/ProjectAnalyzer.cs#L53

Also, would you mind providing the top of the stack trace so that I can see which specific line or method it's failing on.

Thanks!

[jp2masa]

Stack Trace:

Result StackTrace:
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 Buildalyzer.ProjectAnalyzer..ctor(AnalyzerManager manager, String projectPath)
   at Buildalyzer.AnalyzerManager.GetProject(String projectPath)
   at FrameworkTests.FrameworkTestFixture.GetProjectAnalyzer(String projectFile, StringBuilder log) in path\to\Buildalyzer\FrameworkTests\FrameworkTestFixture.cs:line 84
   at FrameworkTests.FrameworkTestFixture.LoadsProject(String projectFile) in path\to\Buildalyzer\FrameworkTests\FrameworkTestFixture.cs:line 34
Result Message:	System.BadImageFormatException: Could not load file or assembly 'Microsoft.Build.Tasks.CodeAnalysis, Version=2.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Not commenting the line: 12 tests fail. (BadImageFormatException)
Commenting the line: 8 tests fail. (project is null/arg is null)

[jp2masa]

If I run the tests from the command line (dotnet test), all tests pass, commenting or not the assembly load line. The Visual Studio test execution engine is x86, so probably that's the problem.

[daveaglick]

The Visual Studio test execution engine is x86, so probably that's the problem

Now that you mention it, I actually hit this earlier myself. Should have remembered. I usually use the Resharper test runner which is x64 by default, but briefly switched to the VS one and had similar problems. I resolved it by going to Test -> Test Settings -> Default Processor Architecture -> x64. Does that resolve it for you as well?

[jp2masa]

All the tests are passing now, but I still can't understand why it doesn't work in my application. The dotnet host is x64, so it should work.

[daveaglick]

Is the host application platform target explicitly x64 or just AnyCPU? Not that it should make any difference since AnyCPU is supposed to pick the x64 runtime when it's available, but maybe worth checking.

[jp2masa]

The target is AnyCPU, and I only have the .NET Core CLI x64 version installed.

[jp2masa]

Now I'm getting this exception: https://pastebin.com/VnuwCQKn

[daveaglick]

Oh, wow, you broke it good 😄.

On the one hand I think this is good because it means that you're actually getting past the previous problems and we're calling the MSBuild API successfully. On the other hand, this looks like it'll be nasty to track down since it's deep in the MSBuild libraries (looks like the method that kicks off the problem is Microsoft.Build.Shared.AssemblyResources.GetStringFromEngineResources). Seems like something might be off with the resources - perhaps there are extra MSBuild properties we need to set to correctly handle resources.

Is the project you're trying to analyze open source and available somewhere I could get it to try and reproduce?

[daveaglick]

Also, what platform are you running on?

[kentcb]

I was getting the same thing:

(the stack trace is exactly the same as provided by @jp2masa).

In my case, I was attempting to use Buildalyzer from a .NET 4.7 console application. Based on the above discussions, I checked the compiler settings and found this:

Unchecking that check box gets me past this error.

[daveaglick]

@kentcb Thanks - I think I know how to get around this. MSBuild ships both x64 and x32 binaries by default, but I'm pretty sure Buildalyer is defaulting to the x64 path. I'll take a look at how to switch to the x32 libraries if the host application is detected as a x32 process.

[daveaglick]

It's looking more and more like a x86 .NET Framework application building a .NET Core SDK-style project via the MSBuild APIs isn't a supported scenario by MSBuild and the project system. The Microsoft.Build.Tasks.CodeAnalysis.dll assembly that holds the Microsoft.CodeAnalysis.BuildTasks.Csc task is built for x64 only. As far as I can tell, there's no x86 or AnyCPU equivalent library (which makes sense given that it includes some native code).

I'll update the table in the readme to make this clear and leave the issue a little while longer until I'm certain, but otherwise there isn't much we can do about x86 .NET Framework hosts using the SDK.

[daveaglick]

@jp2masa That's an excellent point! I forgot that there was a totally separate x86 SDK distribution. Going to try installing it to see what the path difference is (and what dotnet --info returns in that case).

[daveaglick]

@jp2masa That did the trick - just needed to add a check and manually change the path we look at (since dotnet --info will use whichever one is first in the PATH).