assembly registration problems

2464
1
Jump to solution
08-16-2012 12:52 AM
Highlighted
New Contributor II
I have been working on a project at work for the last 5 months and today an new error occurred.

Firstly the specs: it's a developed with VB .NET targeting .NET 3.5 and using ArcObjects 10.0 for ArcMap
It's a legacy project and I have ported it from .NET 2.0 and ArcObjects 9.2 (some code from much earlier)

Anyhow everything was going well, just ironing out a few final kinks at the end of the project when a build process started throwing errors:
"Cannot register assembly "projectName.dll". Exception has been thrown by the target of an invocation."


When I ran ESRIRegAsm.exe  with /e it displays:
"Managed Exception: The type initializer for 'projectName.className' threw an exception. ... Operation Failed 01EAFB18 or 006AFB18 or some other random code


For diagnostic purposes I excluded the named class from the project but the same error was reported in another class, tried this trick again and the error repeats in another. (most likely the first type processed)

So I did some research and found http://forums.arcgis.com/threads/1162-Issue-with-ESRIRegAsm which lead me to examine the

    <ComRegisterFunction(), ComVisibleAttribute(False)> _     Public Shared Sub RegisterFunction(ByVal registerType As Type)         ' Required for ArcGIS Component Category Registrar support         ArcGISCategoryRegistration(registerType)          'Add any COM registration code after the ArcGISCategoryRegistration() call      End Sub

and
    Private Shared Sub ArcGISCategoryRegistration(ByVal registerType As Type)         Dim regKey As String = String.Format("HKEY_CLASSES_ROOT\CLSID\{{{0}}}", registerType.GUID)         EditTasks.Register(regKey)      End Sub

methods.  However they all look very boilerplate and automatically generated.

One point to note is that everything was working fine (code/build/run) just 10 minutes earlier.

Is anyone able to offer any advice?
0 Kudos
1 Solution

Accepted Solutions
Highlighted
New Contributor II
This issue has now been resolved.
The problem was not ArcObjects/ESRI related.

The projects had been converted from VB6 using the VB Migration Partner.

One quirk of VB Migration Partner is that:
   1) it adds a static constructor to every class it converts
   3) these constructors call an empty method of its VisualBasic6_Support module
   2) these method calls force execution of the VisualBasic6_Support static constructor
   4) the VisualBasic6_Support static constructor calls InitializeLibrary from one of the VB Migration Partner .dlls
   5) the default behaviour of InitializeLibrary includes scaning through all dlls found in the current directory

For whatever reason this scan was throwing an unhandled exception causing the behaviour I described earlier.
However InitializeLibrary can be configured to skip this scan, and now everything is working as it should.

So it turned out that while the exception was being caused by the call to RegisterFunction, it was occurring due to code in the static constructor i.e. before the RegisterFunction code is executed.

View solution in original post

0 Kudos
1 Reply
Highlighted
New Contributor II
This issue has now been resolved.
The problem was not ArcObjects/ESRI related.

The projects had been converted from VB6 using the VB Migration Partner.

One quirk of VB Migration Partner is that:
   1) it adds a static constructor to every class it converts
   3) these constructors call an empty method of its VisualBasic6_Support module
   2) these method calls force execution of the VisualBasic6_Support static constructor
   4) the VisualBasic6_Support static constructor calls InitializeLibrary from one of the VB Migration Partner .dlls
   5) the default behaviour of InitializeLibrary includes scaning through all dlls found in the current directory

For whatever reason this scan was throwing an unhandled exception causing the behaviour I described earlier.
However InitializeLibrary can be configured to skip this scan, and now everything is working as it should.

So it turned out that while the exception was being caused by the call to RegisterFunction, it was occurring due to code in the static constructor i.e. before the RegisterFunction code is executed.

View solution in original post

0 Kudos