I just experienced this System.BadImageFormatException.
Could not load file or assembly ‘System.Fabric, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. An attempt was made to load a program with an incorrect format.
The unit test shall test a Azure Service Bus connection. Yes, sure it is a unit test and the service bus connection actually should be mocked away to only check the behavior and function of the class. I needed to do a short test due to another issue in Azure Service Fabric and did a short shot with a test. The assembly which classes shall be tested references Azure Service Fabric assemblies via nuget packages, but the assembly
- is not a service fabric service and
- shall be actually tested without Azure Service Fabric environment, as I wanted to double check an issue that appears in Service Fabric.
The setup looks like his:
The “Cloud.DimensionManager” actually contains the Azure Service Fabric stateless Service. The Cloud solution is the one that does all the hard lifting-publish-and-packaging-work which is the default one backed in in Visual Studio. Cloud.Common, Cloud.Common.Contracts and Cloud.Common.Tests are the ones of interest here.
There are several questions raising:
I guess I need to have a look onto how dot net loads assemblies?
There is a need to store Service Bus Configuration settings inside of the configuration system of Azure Service Fabric. The current class should get told which settings these are, I do use moq for replacing a service and provide those settings directly. Looks like this, be patienced, this is just a showcase, so certainly I will not keep these settings directly in code.
When not running in testing environment, these components above get their dependencies driven by AutoFac. AutoFac is currently the only DI framework that allows for injecting dependencies and do some kind of auto-magic-wireing also for Azure Service Fabric services themselves. Nice article here about it, certainly there is a nuget package.
I had some strange problems starting the Service Bus instance within Azure Service Fabric which led to the issue above. Looked like this, didn’t tell me too much even after applying all my google fu.
So I thought simple set up a short test and try these classes without that environment.
I really wonder how dot net determines that Azure Service Fabric assemblies are necessary exactly at this point in time. The “ServiceFabricConfigurationReader” has a dependency that abstracts away the “FabricRuntime” static. I didn’t use the implementation due to the replacement by moq, I really don’t know how dot net assumes, it needs to load it exactly where I push the mocked object to the queue client. May be you guys know?
Nevertheless, double checked all dependencies in test assembly which I actually didn’t want to have and it still didn’t work. I removed the interface and hardcoded all the values and it just worked out without that message. So there is some kind of magic in loading assemblies, taking into account dependencies of classes to load assemblies.
BadImageFormatException is often..a compilation issue
I sit back and thought about this. I will not be able to change the load mechanism of assemblies, but I still wondered about the exception I got within Azure Service Fabric and felt quite nerved about the fact, that “just set up these unit tests and check it out” really consumed much more time than I was willing to spend.
Watched the BadImageFormatException raised an educated guess, I believe. I did have something like this before. So after sitting back for some settings, I did straight go to having a look onto the target platform.
I did not set the target platform to match x64.
— Update —
The actual problem arised only in network of my company. It turned out, I didn’t have the same issue letting communication run via my phone or from home – or letting it run directly hosted in Azure. The company runs a proxy driven by Sophos. Calls to Azure Service Bus are blocked with message “ssl, cert check, certificate”. It didn’t accept the certificate of the https connection that the Azure Service Bus will use for communication. Having solved this, everything works like a charm. Lesson learned.
