Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Interop / December 2003

Tip: Looking for answers? Try searching our database.

COM Interop Registration Failing in VS Build

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Kevin Westhead - 24 Nov 2003 18:23 GMT
I'm trying to build an assembly with a COM-visible type that derives from a
COM-invisible type in another assembly. Here is a simplified overview of the
hierarchy:

support.dll
=======
[ComVisible(false)]
public abstract class Settings
{
 public abstract void Read(SerializationInfo info);
 public abstract void Write(SerializationInfo info);
}

test.dll
====
< _
 ClassInterface(ClassInterfaceType.None), _
 ComVisible(True), _
 ProgId("Test.TestClass.1.0"), _
 Guid("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx") _
> _
Public NotInheritable Class TestClass
 Inherits Settings
 Implements ITestClass ' Default interface.

 <ComVisible(False)> _
 Public Overrides Sub Read(info As SerializationInfo)
   ' Implementation of Read.
 End Sub

 <ComVisible(False)> _
 Public Overrides Sub Write(info As SerializationInfo)

   ' Implementation of Write.
 End Sub

End Class

Both test and support live in the same solution, and test references support
as a project (i.e. Add Reference->Projects).

The problem I'm seeing is that whenever I build the solution (test.dll has
"Register for COM Interop" enabled), I get the following build error:

"COM Interop registration failed. Could not find a type library for assembly
'support'."

The support.dll assembly isn't supposed to be registered for COM interop,
which is why there is no type library. If I disable "Register for COM
Interop" on test.dll and manually register it using "regasm /codebase /tlb"
then it is successfully registered. Alternatively, if I make the Settings
class COM-visible and enable "Register for COM Interop" on both assemblies
then the build succeeds. Is there an explanation for this behaviour? Why
does VS need a type library for support.dll when in fact there is no
COM-visible type information contained in the assembly? Is there anyway I
can get this working without having to make Settings COM-visible or calling
regasm manually?

TIA.

Signature

Kevin Westhead

"Ying-Shen Yu[MSFT]" - 25 Nov 2003 07:57 GMT
Hi Kevin,

I tried you code on my machine, however the solution compiles through with
registering COM interop successfully.  Here is my steps and repro code.
please let me know if I missing some thing.
1. Create a c# library project
2. replace the code in class1.cs with the code
<code>
using System.Runtime.InteropServices;
public class SerializationInfo{}//dummy class for compile through

[ComVisible(false)]
public abstract class Settings
{
    public abstract void Read(SerializationInfo info);
    public abstract void Write(SerializationInfo info);
}
</code>
3. add a new vb library project to the current solution ,reference that c#
library project, replace the code in class1.vb with the code
<code>
Imports System.Runtime.InteropServices

Public Interface ITestClass'dummy interface for compile through
End Interface

< _
 ClassInterface(ClassInterfaceType.None), _
 ComVisible(True), _
 ProgId("Test.TestClass.1.0"), _
 Guid("07562C10-B2CE-4594-A234-C5D3881B8D69") _
> _
Public NotInheritable Class TestClass
   Inherits Settings
   Implements ITestClass ' Default interface.

   <ComVisible(False)> _
   Public Overrides Sub Read(ByVal info As SerializationInfo)
       ' Implementation of Read.
   End Sub

   <ComVisible(False)> _
   Public Overrides Sub Write(ByVal info As SerializationInfo)

       ' Implementation of Write.
   End Sub

End Class
</code>
4. change the project settings of vb library project, check the register
for COM interop.
5. click "rebuild solution", VS.NET build these two assemblies and register
the vb class library for COM interop  successfully.

Maybe the problem lies somewhere else, please give me more info on this
problem if you still have question on this issue.
Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
You should not reply this mail directly, "Online" should be removed before
sending.
Kevin Westhead - 02 Dec 2003 23:35 GMT
> I tried you code on my machine, however the solution compiles through with
> registering COM interop successfully.  Here is my steps and repro code.
> please let me know if I missing some thing.

<snip>

> Maybe the problem lies somewhere else, please give me more info on this
> problem if you still have question on this issue.
> Thanks!

Thanks for looking into this, but I'm afraid I missed out some key
information. The abstract base class needs to implement a COM interface, and
it is this that is causing the problem. Here is a more complete example:

***Class1.cs***

using System;
using System.Runtime.InteropServices;

namespace ClassLibrary1
{

 [
   ComImport(),
   Guid("0000010C-0000-0000-C000-000000000046"),
   InterfaceType(ComInterfaceType.InterfaceIsIUnknown)
 ]
 public interface UCOMIPersist
 {
   void GetClassID(out Guid clsid);
 }

 [ComVisible(false)]
 public abstract class Class1 : UCOMIPersist
 {

   protected Class1() : base()
   {
   }

   public abstract Guid ClassId
   {
     get;
   }

   void UCOMIPersist.GetClassID(out Guid clsid)
   {
     clsid = ClassId;
   }

 }

}

***Class2.vb***

Option Explicit On
Option Strict On

Imports System
Imports System.Runtime.InteropServices

Namespace ClassLibrary2

 < _
   ClassInterface(ClassInterfaceType.None), _
   ComVisible(True), _
   Guid("4651D5FA-573D-42dd-8C34-07202759A5C2"), _
   ProgId("ClassLibrary2.Class1.1.0") _
 > _
 Public NotInheritable Class Class1
   Inherits ClassLibrary1.Class1

   Public Sub New()
     MyBase.New()
   End Sub

   <ComVisible(False)> _
   Public Overrides ReadOnly Property ClassId() As Guid
     Get
       Return New Guid("4651D5FA-573D-42dd-8C34-07202759A5C2")
     End Get
   End Property

 End Class

End NameSpace

Implementing the UCOMIPersist interface in the C# class means that the VB
class cannot be registered without a type library for the C# assembly.
Unfortunately, enabling "Register for COM Interop" on the C# assembly
results in the following build error: "COM Interop registration failed.
There are no registrable types in the built assembly." Running regasm
manually on the VB assembly with /tlb results in a type library being
created for the C# assembly automatically, and therefore regasm succeeds. Is
there any way I can avoid the requirement of a type library for the C#
assembly or at least be able to create it as part of the build using
"Register for COM Interop"?

Signature

Kevin Westhead

Robert Gruen [MSFT] - 05 Dec 2003 00:01 GMT
Kevin,

I've looked into the behavior you've illustrated here and it this is by
design.  

Basically the IDE recognizes that there isn't an instantiable class within
the assembly and will not register the tlb for COMInterop.  Hence the error
message that you are seeing.

The IDE does not perform any checks to see if there are any classes that
are inheriting from the assembly, if it did then it would be smart enough
to register the tlb so that everything worked in this scenario.  However,
this scenario isn't encountered often and hence this is why the IDE doesn't
perform this type of check.

If all you want to do is to automate this entire process you can simply do
this by adding an instantiable class to the C# assembly:

public Class2
{
}

Since the class is instatiable the IDE will generate the TLB and register
it and everything will be kosher.

Thanks!  Robert Gruen
Microsoft, VB.NET

This posting is provided "AS IS", with no warranties, and confers no rights.
Kevin Westhead - 09 Dec 2003 11:28 GMT
> I've looked into the behavior you've illustrated here and it this is by
> design.
[quoted text clipped - 18 lines]
> Since the class is instatiable the IDE will generate the TLB and register
> it and everything will be kosher.

Thanks for clearing the IDE behaviour up, however I'm still not sure why a
typelib is required in the first place. It seems that implementing an
interface, declared with ComImportAttribute, on the base class adds this
requirement, yet the given interface is never included in the resulting
typelib for the assembly containing the base class or the assembly
containing the derived class anyway. I'm probably just being thick here, but
I still don't understand the need for a typelib given that it contains no
relevant information, i.e. it doesn't seem right that I have to add (and
document) dummy public classes in certain assemblies.

Signature

Kevin Westhead

Robert Gruen [MSFT] - 09 Dec 2003 15:01 GMT
Kevin,

You are absolutely correct in your statements about not needing a tlb for
the base class.  This is the reason you are able to compile and register
the class that implements the interface without any problems (when it's in
a solution by itself or when compiling/registering from the command line).  
You don' thave to include the dummy class if you don't want to.  The only
thing the dummy class does for you is allows you to circumvent the behavior
of the IDE where it's generating this error message.  If you wanted to you
could exclude the base class from your solution and you'd be able to work
without any problems.  

I hope this clears things up for you.

Thanks!  Robert Gruen
Microsoft, VB.NET

This posting is provided "AS IS", with no warranties, and confers no rights.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.