We Keep Coding

Unable to load file or assembly mongocrypt

System.BadImageFormatException: 'Could not load file or assembly 'mongocrypt' or one of its dependencies. The module was expected to contain an assembly manifest.'
I have a project that runs Hangfire 1.7.5 with MongoDB 2.9.1.0. This project is used as a backend engine to perform various types of work.
In order to create endpoints for outside systems to call this engine, we have another project that uses the same versions of Hangfire and MongoDB to connect and pass in the jobs for processing.
I upgraded Hangfire and Mongo to the latest versions, 1.7.9 and 2.10.1.0 respectively in all the projects that were using these dlls. Using Visual Studio, when I run the web projects, I keep getting the above mentioned error. I get these like 4 to 5 times before the ASP.Net site loads up and allows me to access anything I need, including the data that is accessed via MongoDB. Just an inconvenience but still an exception when loading project.
I know that architecture of the CPUs might cause the System.BadImageFormatException but nothing in that sense has been changed. I am running everything on .net 4.6.1 and everything continues to run on AnyCPU configuration. If I change all these projects to x64 or x86, one or the other thing stops working. mongocrypt error continues to occur regardless of the CPU architecture.
I cant find anything on google or SO regarding mongocrypt. Any ideas?

Same thing happened to us.
It appears that in v2.10.0 a new dependency library was introduced libmongocrypt
that causes this error.
Try to go back to v2.9.3 to workaround this issue until it is fixed by mongodb programmers.
mongodblibmongocryptc#

How do I swap out a COM dll

I have a Windows Service written in Delphi, which utilities a dll, also written in Delphi. This dll uses a .Net dll to handle comm's.
All of these pre-date my time at the company, and no source is available for any of it.
The .Net dll contains a url to a web service, which needs to change. I’ve de-compiled the .Net dll , changed the brand and recompiled, but swapping out the old file for this new one results in the error
‘OLE error 80131040’
I’ve spent a lot of time Googling/researching this error but since I don’t have the source for the Delphi part, the answers I found were of no use.
Things I know:
• To prove the decompile/recompile process, I took the original, dll and used that as a test. Once recompiled it functioned perfectly.
• The only thing changed in the ‘modified’ dll is the URL of the web service.
• I ran Process Monitor against the service whilst using it, and identified several references in the registry (CLSID).
• I have generated a registry ‘merge’ file using Regasm, and applied this. All old references were replaced as far as I can see, but now my error has changed to ‘Class not registered’.
• Re-running the process monitor with these changes showed the service is STILL trying to get the original registry entry.
• I have scoured the registry for this entry (673DED65-BE57-36AF-AE8F-5BD418F1596E) and found nothing. I also let Agent Ransack loose doing a content search, which produced no results after 6 hours of searching.
• I know from archived versions of the dlls that these have been swapped out multiple times without the actual service ever being altered; therefore I can’t see how the registry key can be coded in to that program.
• I have checked the GAC and the assembly is not listed in there, even on the working version.
• I have tried adding to the GAC, but get an error about the assembly not being strongly named, so I don't think it's ever been in there?
So the question is, how is the service STILL getting a registry key that doesn't exist and isn't detailed anywhere as far as I can see? Have I missed a vital step somewhere?

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.

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.

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.

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.

C# "Method not found" exception on runtime without usage of reflection

I have a problem with getting above exception. I have a relatively simple structure separate in two dll.
First one contains a IEntityService, IEntity, with basic implementation. Second one contains the actual implementations as well as interfaces. so there is a IMachine service which implements IEntityService and MachineService which implements both IEntityService and EntityService. Similar situation happen for a Result collection( entity plus service). Additionally the service(Machine and result) are partial classes/interfaces where one of the class is auto generated.
Now in one of the ResultMachine I am trying to get a machine and in a case it do not exists I am creating it and saving. However when I am trying to save I got the "Method not found" when trying to access a saving method from a EntityService class. However if I wrap EntityService.Save method in a MachineService it is working without any exception.
Edited:
The code is not required. THe resolution was to re-link the reference. What was misleading for me that my dll is not in GAC, it is linked with VS. What is more it is not strongly signed, the only difference is version number.

We have got this error a few times, you can recreate the problem as follows:
Created project with 2 dll's (say a program dll and a test dll)
deploy program dll to GAC
Add new method
Create test to test the new method
build solution
run test (not in debug mode)
You will now get the method missing exception. The reason is that it is using the old version of the dll that is in GAC and does not have the method.
Some times it uses a cached version of the old dll, IISreset can help.
In your case check for any old versions of the dll.

My first instinct would be to check to make sure the assemblies contained the classes with the missing method. I suppose its possible that the assembly didn't get updated immediately?

When referencing the "same" type from different assemblies, make sure you are loading everything via the same path. Otherwise, identical types can actually be treated as if they are different.
See this article for more: Fusion Loader Contexts - Unable to cast object of type 'Whatever' to type 'Whatever'

This happened to me when I went in and tweaked my build settings to output to /bin/Debug rather than to just /bin in a case when I was also using IIS to host the site from the dev folder.
You need to have the binaries in the same folder as the service, in my case, and the tweak left old versions in the bin folder and put subsequent builds into the /bin/Debug folder (and /bin/Release).
Either keep the settings as is and have a post build action to copy the bits up one level, have different IIS applications for debug/release, or deploy to another folder altogether. The latter is probably most "correct" but for my purposes I just realized after much wheel-spinning, that I had different versions in the service's folder. HTH.

In my case I just deployed on a machine with .NET 3.0 (Windows XP) while the compile target has been .NET 3.5.
This error message is really not helpful.
Problem has been usage of DataContract from System.Runtime.Serialisation.

In .NET, is there a need to register the DLL?

Is it necessary to register a compiled DLL (written in C# .NET) on a target machine.
The target machine will have .NET installed, is it enough to simply drop the DLL onto the target machine?

I think you're confusing things a little. Registering a dll has never been needed in order to use it.
Using a dll requires only to load it (given a known location or if the library is in the system path) and get the address of the function you wanted to use.
Registering the dll was used when distributing COM or ActiveX objects which need to add certain entries to the windows registry. In order to use a COM service (for example) you need to reference a GUID — that is, a unique identifier — which allows you to get a handle to the dll that implements the service (or provide access to it). Sometimes you can make reference to a fully-qualified name and get the same results.
In order for all that to work the dll needed to be registered. This "registration" process just creates several entries in the registry, but mainly these two: one associating a GUID with the location of the dll (so that you can reference it through the GUID without knowing where is it exactly located) and a second one associating the full name with the GUID. But again, this is just for COM or ActiveX objects.
When you develop an application in .NET, the libraries referenced on your project are automatically loaded when they're needed without you having to worry about locating or loading them. In order to to that, the framework checks two locations for the referenced libraries.
The first location is the application path.
The second location is the GAC.
The GAC (Global Assembly Cache) allows you to effectively register a dll to be used throughout the system and works as an evolution of the old registering mechanism.
So basically you just need to put the dll in the same folder of the application.

You need to "drop" it into a directory where the application needing it will find it.
If there are multiple applications, or you want to "drop" the file somewhere other than the application directory, you generally need to either adjust the PATH variable, or register the assembly in the Global Assembly Cache (GAC).

It is usually enough to drop the dll into the folder of your app on the target machine.
If the dll must be available to other applications then you may want to consider the GAC.

If you wish to access the assembly via com+. An example would be using a type defined in a .NET assembly from a non .NET application, such as a VB6 winforms app.
If you plan on accessing the assembly from another .NET application, you don't have to do anything. If your assembly has a strong name, it probably is a good idea to drop it in the GAC. Otherwise, just drop it in the directory of the application that will be referencing it.

One of the great selling points of .NET for the Windows platform when it came onto the scene is that by default, .NET assembly DLLs don't have to be registered and can be consumed privately by an application by merely putting them in the same folder as the EXE file. That was a great stride forward because it enabled developers to avoid the fray of DLL/COM hell.
Shared DLL/COM modules proved to be one of the greatest design mistakes of Windows as it lead to instability of applications that users installed. Installing a new app could well screw up an app that had been working just fine - because the new app introduced newer versions of shared DLL/COM modules. (It proved in practice to be too much of a burden for developers to properly manage fine-grained version dependencies.)
It's one thing to manage versions of modules with a build repository system like Maven. Maven works extremely well doing what it does.
It's an entirely different matter, though, to deal with that problem in an end-user runtime environment spread across a population of millions of users.
The .NET GAC is by no means a sufficient solution to this age-old Windows problem.
Privately consumed DLL assemblies continue to be infinitely preferable. It's a no-brainer way to go as diskspace is extremely cheap these days (~$100 can by a terabyte drive at Fry's these days). There is nothing to be gained with sharing assemblies with other products - and yet company reputation to loose when things go south for the poor user.

Actually there is NO need to register a dll in .NET on the target machine.
If you reference a .dll in your application, click on the referenced .dll under references in your project, look at the properties and set Isolated to TRUE.
This will now automatically include this .dll in your project and your application will use the copy of the .dll included in your project without any need to register it on the target system.
To see a working Example of this look here:
http://code.msdn.microsoft.com/SEHE
The .dll in question will need to be registered on the system where you build your application for this to work properly. However once you build your project, there will not be any need to register the .dll in question on any system you deploy your application or program.
An additional benefit of using this method, is that even if in the future, another .dll is registered with the same name on the target system in question, your project will continue to use the .dll you deployed with. This is very handy where a .dll has many versions and you wish to maintain some stability, like using the one you tested with, yet all other applications will use the registered .dll unless they use the isolated = true method as well.
The example above is one of those cases, there are many versions of Skype4COM which is a Skype API .dll and can change often.
This method allows the above example to use the API .dll that the project was tested with, each time a user installs a new version of Skype, it is possible that a modified version of this .dll is installed.
Also, there are some Skype clients that do not install this .dll, the business version of the Skype client for example, is smaller, and does not include this .dll, so in this case, the project does not fail on that .dll missing and not being registered because it is included in the project as isolated = true.

An application can use a .NET dll by simply having it present in the same folder with the application.
However if you want other third-party applications to find the DLL and use it they would also have to include it in their distribution. This may not be desirable.
An alternative is to have the DLL registered in the GAC (Global Assembly Cache).