sdk: dotnet test with xUnit and full .NET framework causes System.BadImageFormatException
Steps to reproduce
Create a web application that targets full .NET framework, e.g. with:
"frameworks": { "net461": { } },
Create a class library with xUnit, testhost and web application as dependencies - e.g.:
{
"version": "1.0.0-*",
"testRunner": "xunit",
"dependencies": {
"xunit": "2.1.0",
"dotnet-test-xunit": "1.0.0-rc2-build10015",
"Microsoft.AspNetCore.TestHost": "1.0.0-rc2-final",
"WebApp": "*"
},
"frameworks": {
"net461": { }
}
}
Create a unit test in class library that uses the web application:
public class IntegrationTests
{
[Fact]
public void Test()
{
var builder = new WebHostBuilder();
builder.UseStartup<Startup>();
}
}
Expected behavior
Tests are executed properly
Actual behavior
Project WebApp (.NETFramework,Version=v4.5.1) was previously compiled. Skipping compilation.
Project WebApp.Tests (.NETFramework,Version=v4.6.1) will be compiled because inputs were modified
Compiling WebApp.Tests for .NETFramework,Version=v4.6.1
Compilation succeeded.
0 Warning(s)
0 Error(s)
Time elapsed 00:00:01.4138420
xUnit.net .NET CLI test runner (32-bit win81-x86)
Discovering: WebApp.Tests
Discovered: WebApp.Tests
Starting: WebApp.Tests
System.BadImageFormatException : Could not load file or assembly 'WebApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Stack Trace:
at WebApp.Tests.IntegrationTests.Test()
Finished: WebApp.Tests
=== TEST EXECUTION SUMMARY ===
WebApp.Tests Total: 1, Errors: 0, Failed: 1, Skipped: 0, Time: 0,193s
Environment data
dotnet --info output:
.NET Command Line Tools (1.0.0-preview1-002702)
Product Information:
Version: 1.0.0-preview1-002702
Commit Sha: 6cde21225e
Runtime Environment:
OS Name: Windows
OS Version: 6.3.9600
OS Platform: Windows
RID: win81-x64
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 30 (1 by maintainers)
Visual Studio Fix
Menu Bar -> Test -> Test Settings -> Default Processor Architecture -> X64
After upgrading my .NET Core project which targets net461 to csproj I have this issue again when trying to run dotnet test in the command line it always runs the x86 build.
I ran into the same issue today on Windows 10 x64. It seems the dotnet test runner always runs as 32 bit executable and hence expects x86 binaries. Forcing both the ASP.NET Core and the xUnit test project to build x86 assemblies works for me as a stopgap measure.
"buildOptions": { "platform": "x86" }I did a little testing today. The problem is if you try to test an executable project/web app, referencing
Microsoft.AspNetCore.Server.Kestrel(or any project that indirectly references that package, like aMicrosoft.AspNetCorepackage for example)Steps to reproduce:
Create ConsoleApp with this as a ConsoleApp1.csproj:
Test class in the console app that will be tested:
Create xUnit test project with this as .csproj:
The test method class:
Expected behavior
running
dotnet xunitcauses test to pass.Actual behavior
running
dontet xunitcauses the test to faildotnet xunitoutput:Removing the
Microsoft.AspNetCore.Server.Kestrelreference from the Console App causes the test to pass Changing the project type fromConsole ApplicationtoClass Library, even with theMicrosoft.AspNetCore.Server.Kestrelreference present, causes the test to pass Runningdotnet testcauses the tests to pass as wellEnvironment Data
dotnet infooutput:Additional notes
Running tests in Visual Studio 2017 works properly every time, only the cli tools seem to be broken
I tried running tests with different versions of a
dotnet-xunitpackage as well as different versions ofMicrosoft.AspNetCore.Server.Kestrelpackage. The results were always the same.I made a simple test repo that has 5 projects, showcasing different project type/references combination:
Running tests with dotnet xunit causes 2 out of 4 test methods to fail with
System.BadImageFormatException@RehanSaeed You are my savior 👍
@RehanSaeed THANK YOU! A thousand times THANK YOU ! The Visual Studio setting you pointed out fixed got things working here!
Thanks but anyway - it should be fixed.