Could not load assembly. An attempt was made to load a program with an incorrect format error in VS 2010

Question

<p>I have a strange issue. We have vb.net projects that have been functioning just fine. We moved to VS 2010 and converted the project. When we build the project, which, uses com interop and imports some type libraries everything compiles. We can call regasm.exe on the resulting DLL with no issues.</p><p>Then some smart guy decided that the .NET runtime used should be 4.0. So that switch gets toggled. We build with no problem. But when we run regasm.exe we get an error RA0000: Could not load file or assembly ... An attempt was made to load a program with an incorrect format".</p><p></p><div class="t-paste-container">(from the VS x64 Wind64 Command Prompt</div>

---

R.D. Holland

Answer 1

Sorry about all that tag stuff in the above post but I made a major mistake by actually copying and pasting some text to the above post. After that with every character I typed into the window, and I mean every character, I get a message box:

Scrip Error

An error occurred in the script on this page

Line 1

Char 247274

Error Invalid argument

Code: 0

URL http://i1.social.s-

msft.com/Forums/RequestReduceContent/xxxxx

Do you want to continue running scripts on this page?

I can select "no" and the box goes away until I type another character (it appears in the post) and the box comes right back up. If I select "yes" it comes right back up. The same thing happened when I clicked "submit". The tag crap int he post didn't show up in my window. It showed up after the post occurred and the IDE updated the window.

This seems to always happen if I do a copy&paste operation. In this case I just cut text from the post window and pasted it back in a couple of lines later.

---

R.D. Holland

Answer 2

Hi Holland,

Thanks for your post.

According to the error information, the most usual reason for this is an “X86” assembly deployed to an”x64” sever. Please try to edit the Target Platform in the Project Build Properties to “Any CPU” or “X86” for your special situation. And rebuild the application.

If this doesn’t work for you, please feel free to let me know. 

---

Mark Liu-lxf [MSFT]
MSDN Community Support | Feedback to us

Answer 3

Mark,

The config is already "Any CPU". I can fix this in one of two ways. I can change to "x64" and build. Or I can remove the reference to a COM .tlb file (which the IDE creates an interop assembly from) and instead of using the IDE generated interop assembly, I can go to the command prompt and run tlbimp on the .tlb file myself to generate an interop assembly. Then I add a reference to the interop directly. At that point, the Any CPU config builds and I can run regasm.exe on the assembly created by the project.

---

R.D. Holland

Answer 4

Hi Holland,

>> I can fix this in one of two ways. …….At that point, the Any CPU config builds and I can run regasm.exe on the assembly created by the project.

Form your last reply, do I get the message that you figure this issue out?

---

Mark Liu-lxf [MSFT]
MSDN Community Support | Feedback to us

Answer 5

Mark,

Why is there a difference between importing the .tlb file using the IDE and running tlbimp.exe from the command line?

If I open the resulting interop assemblies in ildasm, I can see the difference that causes the problem. The assembly that is imported via the IDE is marked 32 bits only (which is incorrect):

.corflags 0x00000003    //  ILONLY 32BITRERQUIRED

If I use the tlbimp tool to manually create an interop assembly from the tlb file, I see this (which is correct):

.corflags 0x000000001  // ILONLY

So what I have figured out is why the "Any CPU" assembly won't load when running the framework64\regasmtool after building the Any CPU target with .NET4 runtime selected. I have not figured out why the IDE creates an invalid assembly when using .NET 4. That is a job for Microsoft.

---

R.D. Holland

Answer 6

Mark,

I forgot to mention one other problem in the IDE. Even if I create an x64 configuration, the IDE has yet another bug in it. In order to register the resulting assembly for COM interop, I have to check the "Register for COM interop" box on the "Compile" page of the project properties.

But when the project builds I see that the IDE is using the 32 bit regasm.exe tool. So the project fails miserably with this error:

c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3341,9): error MSB3097: File "U:\PRs\1889526\SEAddIn\bin\x64\Debug\SEAddIn.dll" is not a valid assembly.

---

R.D. Holland

Answer 7

Hi Holland,

The interop assemblies converted by IDE are 32 bit depends upon the version of .tlb file. The mainly different between importing the .tlb file using the IDE and running tlbimp.exe can be caused by using the embedded interop types which is the new feature of .framework 4.0.  Please check this link: Using COM Types in Managed Code: http://msdn.microsoft.com/en-us/library/3y76b69k.aspx

Using embedded interop types: Beginning with the .NET Framework version 4, you can instruct the compiler to embed type information from an interop assembly into your executable. The compiler embeds only the type information that your application uses. You do not have to deploy the interop assembly with your application. This is the recommended technique.

As we know, the interop assembly is used to provide the interface to invoke the COM component. But if there are some inner invoke in the COM objects, the compiler will embed only the type information that your application uses. The default value of embedded interop type is true. So you can try to use the primary interop assemblies (PIAs) to deploy applications that interoperate with COM objects instead of using embedded interop types.

As for your another question, would you like to show what is SEAddIn.dll, which version of it,32bit or 64 bit?  If it is converted by the tlbimp tool, what is the version of the original COM object, 32bit or 64 bit?

---

Mark Liu-lxf [MSFT]
MSDN Community Support | Feedback to us

Answer 8

Hi Mark,

I am very aware of the embedded interop types flag as that too is a major source of problems. So we always recommend that a .NET 4 client set the flag to false. Otherwise customers have problems that don't occur at compile time and instead occur at run time as they get .NET exceptions, some with cryptic error messages. As soon as a message has "interop", "type", "dispatch IDs" or any mention of "embed", "embedded" etc, we can fix the issue by having them set the flag to false. The bad thing about this is that these exceptions don't occur until a line of code is executed. So someone that buys Visual Studio 2010 and flips the .NET 4 switch on a project opened in 2010 (and converted), must make sure they execute every line of code that interacts with our COM application.

In the IDE, after importing the .tlb file, we set the embed interop types flag to false. But that doesn't affect the .corflag. It remains 32bitrequired and hence the .net client cannot be registered for com interop using the 64 bit edition of regasm.exe. It will of course register with the 32 bit edition of regasm.exe.

SEAddIn.dll is the name of my .Net client DLL produced by VB .NET. I am building an "Any CPU" configuration so it is "bit agnostic", or it should be as that's what the "Any" means in "Any CPU". Right?

The vb.net project that creates SEAddIn.dll references a COM type lib from our COM application. It is the resulting interop assembly that has the incorrect corflag set. The type lib is bit agnostic and has been around and been used by .NET clients since .NET came about (Since Visual Studio 2003).

---

R.D. Holland

Answer 9

It turns out there is a known bug in Visual Studio 2010. The work-around is for the user to open the proj file and under <PropertyGroup>

add

<PlatformTarget>AnyCPU</Platformtarget>

---

R.D. Holland