regasm fails, cannot load type
-
I have a .NET DLL that has the following inheritance structure (each object inherits from the object above it):
BaseObject (VB6 COM DLL) COM Interop DLL (.NET) Abstract BaseObject (.NET) Abstract BaseObject2 (.NET) Concrete Object (.NET)To complicate matters, the Concrete .NET Class needs to be accessible from COM. I have set the appropriate attributes to make this happen, and everything works fine on my machine, and some others too. To register on another machine, I use RegAsm. However, on some XP machines, regasm is failing, with the error:RegAsm error: Could not load type XX.XX.AppBase from assembly XX.XX.XX, Version=0.9.1616.28364, Culture=neutral, PublicKeyToken=null because the format is invalid.where XX.XX.AppBase is the first abstract base object. All machines are running .NET 1.1. I have tried to work around the problem by using .reg files to register the DLL, but that just defers the error message until the application tries to use the object. Has anyone any ideas on how I can resolve this, or what causes it? -
I have a .NET DLL that has the following inheritance structure (each object inherits from the object above it):
BaseObject (VB6 COM DLL) COM Interop DLL (.NET) Abstract BaseObject (.NET) Abstract BaseObject2 (.NET) Concrete Object (.NET)To complicate matters, the Concrete .NET Class needs to be accessible from COM. I have set the appropriate attributes to make this happen, and everything works fine on my machine, and some others too. To register on another machine, I use RegAsm. However, on some XP machines, regasm is failing, with the error:RegAsm error: Could not load type XX.XX.AppBase from assembly XX.XX.XX, Version=0.9.1616.28364, Culture=neutral, PublicKeyToken=null because the format is invalid.where XX.XX.AppBase is the first abstract base object. All machines are running .NET 1.1. I have tried to work around the problem by using .reg files to register the DLL, but that just defers the error message until the application tries to use the object. Has anyone any ideas on how I can resolve this, or what causes it?Sometimes I had similiar problems using RegAsm. I don't know whether they help, but I have a few advices: -Clear all Registry Entries made from previous attempts to register your Assembly (search the registry e.g. for the dll-names or UUIDs if any are given in your Code). -If not already done, type an unique Versionnumber in 'AssemblyInfo.cs' (Important: Don't leave any '*' in the Versionnumber. The '*' shall cause the VS to generate a Versionnumber. I think it's the Buildnumber. But this simply doesn't work correctly, s.t. regasm may try to register a seemingly older version over a newer one.) - If it still doesn't work: Try to 'export' as few symbols as possible. That means (in C#): Use 'public' only on functions that are used by other dlls or via com (e.g. implemented Interface-functions must be public). Use 'internal' for other functions instead. As far as I understood, public in C# is for com like dllexport in C. Please tell me if any of the advices helped.
-
Sometimes I had similiar problems using RegAsm. I don't know whether they help, but I have a few advices: -Clear all Registry Entries made from previous attempts to register your Assembly (search the registry e.g. for the dll-names or UUIDs if any are given in your Code). -If not already done, type an unique Versionnumber in 'AssemblyInfo.cs' (Important: Don't leave any '*' in the Versionnumber. The '*' shall cause the VS to generate a Versionnumber. I think it's the Buildnumber. But this simply doesn't work correctly, s.t. regasm may try to register a seemingly older version over a newer one.) - If it still doesn't work: Try to 'export' as few symbols as possible. That means (in C#): Use 'public' only on functions that are used by other dlls or via com (e.g. implemented Interface-functions must be public). Use 'internal' for other functions instead. As far as I understood, public in C# is for com like dllexport in C. Please tell me if any of the advices helped.
The problem turned out to be that my DLL exposed an ADO recordset. This was not a problem on machines with Visual Studio.NET installed, because they have ADODB.DLL in the GAC. However, most user machines do not. So the solution was to copy ADODB.DLL from my local machine (C:\Program Files\Microsoft.NET\Primary Interop Assemblies\ADODB.DLL) to the target machine, and then install it to the GAC (gacutil -i ADODB.DLL).