none
.NET COM Component not being offloaded RRS feed

  • Question

  • I created a COM component in .NET using following steps as I found at an MSDN article.

    http://msdn.microsoft.com/en-us/library/zsfww439(VS.71).aspx

    First create a class library project in C# or VB .Net . This class library must have one defaut parameterless constructor since this is requirement of constructing a COM component.

    Next sign the assembly using a strong key pair.

    Next register the assembly dll using regasm utility.

    You get a COM component that any COM client application can consume.

    There is no use of unmanaged components or objects in the class library and I have made sure to write code in a way that GC would like!

    But I find even that the COM component does not seem to be offloaded long after its use is over in the COM client.

    This I realised this when  I rebuilt the DLL and tried to replace the DLL at the location used by the COM client application and I got the message that the DLL is in use

    I could replace the DLL only after closing the client application.

    The code in the COM client is very simple.

    Dim x as Variant
    set x = CreateObject(MyCOMObject.MyClass)
    x.MyMethod
    set x = Nothing

    Whats wrong here?


    &=1
    Wednesday, July 9, 2008 1:25 PM

Answers

  • Problem gone!

    I don't know how but once I created a setup for installing the COM dll using vsdrpCOMRelativePath for the Primary Output.

    Once I installed the DLL through setup, I found the COM component does not linger around.

    To be sure that the application isn't accessing the COM component from somewhere else I uninstalled the dll and got the 'Cannot create automation object'.

     



    &=1
    • Marked as answer by Zhi-Xin Ye Monday, July 14, 2008 2:15 AM
    Thursday, July 10, 2008 5:44 AM

All replies

  • Guessing at this, I don't see how the framework could implement DllCanUnloadNow().  Assemblies can only be unloaded if they were loaded in a non-default domain.  The CLR itself cannot be unloaded either.  Even if COM calls FreeLibrary(), the JIT compiled code stays resident.  I'm not getting decent Google hits to back-up my guess.
    Hans Passant.
    Wednesday, July 9, 2008 5:31 PM
    Moderator
  • Problem gone!

    I don't know how but once I created a setup for installing the COM dll using vsdrpCOMRelativePath for the Primary Output.

    Once I installed the DLL through setup, I found the COM component does not linger around.

    To be sure that the application isn't accessing the COM component from somewhere else I uninstalled the dll and got the 'Cannot create automation object'.

     



    &=1
    • Marked as answer by Zhi-Xin Ye Monday, July 14, 2008 2:15 AM
    Thursday, July 10, 2008 5:44 AM