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

Notification

Icon
Error
BadImageFormatException
Options
Previous Topic Next Topic
bitrocks
#1 Posted : Thursday, September 27, 2018 6:53:09 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 10/16/2017(UTC)
Posts: 5

Thanks: 1 times
After running without problems for a long time, NCrunch all of a sudden started to throw errors since yesterday:

An error occurred while analysing this project after it was built: System.BadImageFormatException: Could not load file or assembly 'System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058)

I'm using NCrunch 3.20.0.6 and pretty much all of the projects in the solution are on .net 4.7.1. About half of the unit test projects are throwing this error.

The only thing I did after the last time NCrunch ran flawlessly was to update some nuget packages. Undoing those changes however didn't fix the issue, nor did cleaning/rebuilding/reloading the solution.
Since a BadImageFormatException usually indicates a x86/x64 problem, I tried explicitly setting the Build process CPU architecture in the NCrunch configuration for the failling projects, but that doesn't fix anything, regardless of the chosen value.

I'm running out of ideas here. Any help would be appreciated.
Back to top
Remco
#2 Posted : Thursday, September 27, 2018 11:28:10 PM(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, thanks for sharing this problem.

Do you have any idea of what may have triggered this problem? We're aware of an assembly referencing issue introduced by VS15.8 which has been causing some serious grief these last few weeks. I'm wondering if this issue may be related.

Are any of the projects in your solution running .NET Core or NETStandard?

This problem won't be related to your CPU architecture. It's caused by an assembly being loaded from the wrong place. Possibly it's related to binding redirections.
Back to top
bitrocks
#3 Posted : Thursday, September 27, 2018 11:54:03 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 10/16/2017(UTC)
Posts: 5

Thanks: 1 times
Hi Remco,

I'm not sure what exactly started the issue. As I mentioned I was doing an update for a few nuget packages.
We're also in the process of moving a shared project from 4.7.1 to .net standard, but ran into issues with it, so reverted it back to 4.7.1 for now. But maybe that set something in motion that causes the issue?

So both these things are possible candidates. Given your reply I'd say the latter is most likely. We rolled back those changes, but maybe some files in some VS or NCrunch cache are still there and causing all this?

If there's anything I can do that will give us more info, let me know.
Back to top
Remco
#4 Posted : Friday, September 28, 2018 6:13:10 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)
Back to top
bitrocks
#5 Posted : Friday, September 28, 2018 7:11:45 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 10/16/2017(UTC)
Posts: 5

Thanks: 1 times
Installing 3.21.0.3 didn't seem to make a difference.

The BadImageFormatException is still there.
Back to top
Remco
#6 Posted : Friday, September 28, 2018 8:15:59 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)
I'm sorry to hear that. I guess this problem isn't what I thought it was :(

Is there any chance you can put together a sample project that can reproduce the issue? If I can get it happening on this end, I can take things apart and hopefully resolve it. You can submit code through the NCrunch contact form.
Back to top
bitrocks
#7 Posted : Friday, September 28, 2018 6:06:22 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 10/16/2017(UTC)
Posts: 5

Thanks: 1 times
Well, it's working again.

Not sure if it's of any help, but here's what I did today:

Unrelated to the NCrunch issue, we were moving from using package.config files to PackageReferences. That didn't go very easy so I ended up uninstalling all nuget packages, switching to using PackageReferences and then adding them again (thereby automatically excluding those that were no longer being used).

After this whole operation I tried NCrunch again and whaddayaknow... it works.

So I won't be able to make a sample project for you. I will if I run into this issue again.
Back to top
Remco
#8 Posted : Saturday, September 29, 2018 12:31:40 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)
Thanks for confirming. The other issues we've been finding related to the VS15.8 update were also related to packages.config, so this isn't a surprise. I guess there's more still in there to dig up. Thanks for taking the time to report the issue.
Back to top
Remco
#9 Posted : Saturday, September 29, 2018 6:04:40 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)
Back to top
windsorperma
#10 Posted : Wednesday, December 9, 2020 6:17:09 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/9/2020(UTC)
Posts: 1
Location: United Arab Emirates
The exception that is thrown when the file image of a dynamic link library (DLL) or an executable program is invalid. If you get a BadImageFormatException when interfacing with a native DLL, it almost always means that you are trying to interface with a 32-bit DLL while running in the 64-bit CLR, or vice versa. In most cases you might be facing the problem with your website after deploying on server.

Make sure that you are not having 32-bit / 64-bit conflict. So, you need to adjust your application pool to Enable 32-Bit or 64-Bit accordingly. Set the Target platform setting on your c# EXE project, not your class library project. Alternatively, you can ship both 32-bit and 64-bit DLLs with different file names, define separate P/Invoke stubs for each version, and decide which one to call at runtime. The easiest way to do this would probably be to wrap your native calls in an interface (e.g., INativeMethods) and choose which implementation to instantiate at runtime based on IntPtr.Size. With this method, you could still target AnyCPU.
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.078 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download