Thursday, December 4, 2008

Regasm and GAC fun (MSB3217 and RA0000)

Problem: A project builds an assembly successfully but An indicates an error similar to the following:
C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2937,9): error MSB3217: Cannot register assembly "C:\Source\Blog\RegasmExamples2\bin\Debug\RegasmExamples2.dll". Method 'SomeProperty' in type 'RegasmExamples2.BrokenClass' from assembly 'RegasmExamples2, Version=, Culture=neutral, PublicKeyToken=null' does not have an implementation.
When using the "Register for COM interop" option in a .Net project


RegAsm : error RA0000: Method 'get_SomeOtherProperty' in type 'RegasmExamples2.BrokenClass2' from assembly 'RegasmExamples2, Version=, Culture=neutral, PublicKeyToken=72d8f57e6c124ae0' does not have an implementation.C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(3314,13): error MSB3073: The command "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm C:\Source\Blog\RegasmExamples\RegasmExamples2\bin\Debug\RegasmExamples2.dll" exited with code 100.
When using Regasm as a post build step in a .Net Project

Common Causes:

  • An interop assembly is in the GAC that has a different interface definition than the one that was referenced and built against but they have the same strong name. Remove the incorrect version of the interop from the GAC and identify the correct version of the interop and install it in the GAC if required.
  • An older version of the project's target assembly is installed in the GAC that does not implement the new interface definition but has the same strong name. Remove the build target from the GAC either manually or with a pre-build step.


  • The location of the assembly that is used when building is defined by the reference and may be different than the assembly probing sequence at runtime.
  • Regasm is a .Net application and will follow the standard assembly probing sequence. If an older build of the assembly is in the GAC (with the same assembly version, culture, and architecture) then it will use that binary.
  • This problem occurs most commonly when someone is monkeying around with interfaces (typically when "fleshing" them out) or as a regression when building mutliple versions of a product on a development machine and someone decided to make an interface "better" instead of extending it with a new one.

Tools to Diagnose:

  • File Monitor or ProcessMonitor by Sysinternals to monitor the build and registration
  • Reflector to view the interface definition of the assembly in the GAC