CODEWITHSUNDEEP
c#.netdll
user589195
user589195

Reputation: 4240

Errors trying to load an assembly in C#

Ok this question is more about understanding what the issues are as I dont think anyone will be able to tell me how to fix the problem.

I am writing a .net 4 application and I have a 3rd party dll ( hasp dongle protection ) that I want to reference.

Visual studio allows me to create the reference fine and use classes contained within the dll within my code.

The first issue occurs when the program is run and the dll is actually loaded. I then get the following error.

System.BadImageFormatException: Could not load file or assembly 'hasp_net_windows.dll' or one of its dependencies. is not a valid Win32 application

This weblink states how to fix this error. Coud someone expalain what the issue is and why im getting it.

After following this advice I then set the main project build to x86 and I then get another error replacing the other. The new error is:

System.IO.FileLoadException: Mixed mode assembly is built against version 'v1.1.4322' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information

This weblink states how to fix the error, but I dont have an app.config in my project and want to avoid having one if at all possible. If someone could explain what the issue is again that would be helpful?

Please let me know if you require anymore information.

Upvotes: 3

Views: 4365

Answers (3)

Abel
Abel

Reputation: 57149

The answer by Adam Houldsworth notwithstanding, I'd like to add that it is possible to do it without an app.config. However, this requires a tiny bit more work and potentially a proper understanding of COM interop. Whether it's worth the trouble is up to you of course ;).

You can set useLegacyV2RuntimeActivationPolicy programmatically by using the ICLRRuntimeInfo::BindAsLegacyV2Runtime method.

A quick rundown on how to do this is posted in this blogpost. Take note of his warning though, which might make you think twice in using this approach:

This approach works, but I would be very hesitant to use it in public facing production code, especially for anything other than initializing your own application. While this should work in a library, using it has a very nasty side effect: you change the runtime policy of the executing application in a way that is very hidden and non-obvious.

Upvotes: 3

stenio
stenio

Reputation: 377

I cannot use an app.config file because the assembly is loaded via COM from a native program. I found the library that supports .net framework 4.0. here. In this scenario, no other solutions had worked for me.

Upvotes: 0

Adam Houldsworth
Adam Houldsworth

Reputation: 64467

The issue is the "bitness" of your application. Once chosen (32 bit or 64 bit) all DLLs within that process need to be the same. This exception tells me that one of your DLLs is the wrong "bitness".

You simply cannot have DLLs with different compilation targets within a given process, a process has "bitness" affinity.

If this is a third party unmanaged DLL then it is very likely 32-bit compiled.

Setting the build output as x86 for the root project (the one that creates the exe) should suffice as this will dictate the process that is created. Any other .NET projects can then simply be Any CPU and will fit in either the 32 or 64 bit runtimes.

Unfortunately for your second issue, the provided link is the way to solve it. There is nothing wrong with having an app.config in a project and you haven't stated why you don't want one.

Upvotes: 9

Related Questions