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.
Remco NCrunch Developer
#12687
27 Sep 2018 23:28 UTC
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.
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.
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.
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.
Remco NCrunch Developer
#12689
28 Sep 2018 06:13 UTC
Would you be interested in trying the build below to see if this solves the issue?
NCrunch_Console_3.21.0.3.msi
NCrunch_Console_3.21.0.3.zip
NCrunch_GridNodeServer_3.21.0.3.msi
NCrunch_GridNodeServer_3.21.0.3.zip
NCrunch_LicenseServer_3.21.0.3.zip
NCrunch_VS2008_3.21.0.3.msi
NCrunch_VS2010_3.21.0.3.msi
NCrunch_VS2010_3.21.0.3.zip
NCrunch_VS2012_3.21.0.3.msi
NCrunch_VS2012_3.21.0.3.zip
NCrunch_VS2013_3.21.0.3.msi
NCrunch_VS2013_3.21.0.3.zip
NCrunch_VS2015_3.21.0.3.msi
NCrunch_VS2015_3.21.0.3.msi.7z
NCrunch_VS2015_3.21.0.3.zip
NCrunch_VS2017_3.21.0.3.msi
NCrunch_VS2017_3.21.0.3.msi.7z
NCrunch_VS2017_3.21.0.3.zip
NCrunch_Console_3.21.0.3.msi
NCrunch_Console_3.21.0.3.zip
NCrunch_GridNodeServer_3.21.0.3.msi
NCrunch_GridNodeServer_3.21.0.3.zip
NCrunch_LicenseServer_3.21.0.3.zip
NCrunch_VS2008_3.21.0.3.msi
NCrunch_VS2010_3.21.0.3.msi
NCrunch_VS2010_3.21.0.3.zip
NCrunch_VS2012_3.21.0.3.msi
NCrunch_VS2012_3.21.0.3.zip
NCrunch_VS2013_3.21.0.3.msi
NCrunch_VS2013_3.21.0.3.zip
NCrunch_VS2015_3.21.0.3.msi
NCrunch_VS2015_3.21.0.3.msi.7z
NCrunch_VS2015_3.21.0.3.zip
NCrunch_VS2017_3.21.0.3.msi
NCrunch_VS2017_3.21.0.3.msi.7z
NCrunch_VS2017_3.21.0.3.zip
Installing 3.21.0.3 didn't seem to make a difference.
The BadImageFormatException is still there.
The BadImageFormatException is still there.
Remco NCrunch Developer
#12695
28 Sep 2018 08:15 UTC
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.
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.
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.
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.
Remco NCrunch Developer
#12700
29 Sep 2018 00:31 UTC
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.
Remco NCrunch Developer
#12702
29 Sep 2018 06:04 UTC
I realise this issue isn't troubling you anymore, but in case it does bite again, I'm hopeful that the build below will resolve it:
NCrunch_Console_3.21.0.4.msi
NCrunch_Console_3.21.0.4.zip
NCrunch_GridNodeServer_3.21.0.4.msi
NCrunch_GridNodeServer_3.21.0.4.zip
NCrunch_LicenseServer_3.21.0.4.zip
NCrunch_VS2008_3.21.0.4.msi
NCrunch_VS2010_3.21.0.4.msi
NCrunch_VS2010_3.21.0.4.zip
NCrunch_VS2012_3.21.0.4.msi
NCrunch_VS2012_3.21.0.4.zip
NCrunch_VS2013_3.21.0.4.msi
NCrunch_VS2013_3.21.0.4.zip
NCrunch_VS2015_3.21.0.4.msi
NCrunch_VS2015_3.21.0.4.msi.7z
NCrunch_VS2015_3.21.0.4.zip
NCrunch_VS2017_3.21.0.4.msi
NCrunch_VS2017_3.21.0.4.msi.7z
NCrunch_VS2017_3.21.0.4.zip
NCrunch_Console_3.21.0.4.msi
NCrunch_Console_3.21.0.4.zip
NCrunch_GridNodeServer_3.21.0.4.msi
NCrunch_GridNodeServer_3.21.0.4.zip
NCrunch_LicenseServer_3.21.0.4.zip
NCrunch_VS2008_3.21.0.4.msi
NCrunch_VS2010_3.21.0.4.msi
NCrunch_VS2010_3.21.0.4.zip
NCrunch_VS2012_3.21.0.4.msi
NCrunch_VS2012_3.21.0.4.zip
NCrunch_VS2013_3.21.0.4.msi
NCrunch_VS2013_3.21.0.4.zip
NCrunch_VS2015_3.21.0.4.msi
NCrunch_VS2015_3.21.0.4.msi.7z
NCrunch_VS2015_3.21.0.4.zip
NCrunch_VS2017_3.21.0.4.msi
NCrunch_VS2017_3.21.0.4.msi.7z
NCrunch_VS2017_3.21.0.4.zip
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.
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.
Post a reply
Log in to reply.