MSBuild built assembly can not be registered, RegAsm (error RA000); Exact same .csProj with Visual Studio 2010 creates valid assembly?

Question

I have a simple C# project when built with MSBuild it builds an assembly that can't be registered with RegAsm (error RA000).

The exact same .csProj built with Visual Studio 2010 creates valid assembly and RegAsm registers successfully?

I am using C:\windows\microsoft.net\framework64\v4.0.30319\msbuild.exe

Both builds (MSBuild 4.0 and Visual Studio 2010) are being done as administrator privileges, so the authority to register is enabled.

• I am seeking a way to solve/understand/debug - this frustrating anomaly.
• Might there be a fix/SPx for MSBuild 4.0 that I am missing?
• Is there a tool to create a map like file (or other .dll formatter) so I can compare the two resulting assemblies for differences?

RegAsm output from MSbuild built bTest.dll:

Microsoft (R) .NET Framework Assembly Registration Utility 4.0.30319.1
Copyright (C) Microsoft Corporation 1998-2004.  All rights reserved.
RegAsm : error RA0000 : Failed to load 'C:\test\bTest.dll' because it is not a valid .NET assembly

RegAsm output from Visual Studio 2010 built bTest.dll:

Microsoft (R) .NET Framework Assembly Registration Utility 4.0.30319.1
Copyright (C) Microsoft Corporation 1998-2004.  All rights reserved.
Types registered successfully
Assembly exported to   'C:\test\bTest.tlb', and the type library was registered successfully

For the above the bTest.csProj file had the Register COM interop was unchecked and RegAsm was done as a post build step.

If builds are done with the Register COM interop checked, thus enabled; the Visual Studio 2010 builds correctly producing the bTest.tlb. However the MSBuild does not produce a bTest.tlb file and the resulting assembly still fails with the RegAsm 4.0 tool.

Thank you in advance.

Kevin Waite

Answer 1

I am using Jenkins, and this job had inherited this specific platform setting form being copied from another very similar job (that is also likely wrong, as I know understand).

Having this PlatformTarget=x86 renders the resulting assembly/.dll un-register-able. Be it with the Register COM Interop checkbox, or be it with the RegAsm tool. And I doubt such a tainted .dll is what is wanted.

If MSBuild uses these Jenkins defined command line arguments; the resulting .dll will be unregisterable. And of course Visual Studio 2010 builds are not doing this and thus build successfully...

-p:PlatformTarget=x86;Configuration=Release

Correcting to the following and job builds successfully and creates the *.tlb perfectly fine too!

-p:Configuration=Release

SOLVED!