none
CoCreateInstance fails - .NET 1.1 - COM - .NET 2.0 projects RRS feed

  • Question

  • Hi,

    I did a search, I could not seem to find the answer.

    My project is a C# dll using .NET 2.0 and COM Interop,the dll is registered in the registry properly(with runtime ver of 2.0).
    I have COM+ server component that consumes the dll.

    The box has both .NET 1.1 and 2.0 installed.

    Two scenarios:
    1. when I call the COM+ server component(that calls my C#.dll) from the client (unmanaged code), everything is great.
    2. However, when I call the COM+ server from .the client written in NET 1.1, the server fails to call CoCreateInstance (it cannot find the C#.dll in the registry).
       The flow is managed code (in .NET 1.1) calling unmanaged code (COM+), that in turn calls C#.dll (in .NET 2.0).

    From what I read, mscorre.dll would load both 1.1 and 2.0 CLR.
    I understand that CLR 1.1 would be loaded first, but when my COM server tries to load my .NET 2.0 dll, shouldn't it recoqnize that it requires CLR 2.0? It is as if (my suspicion) it tries to look in the registry for the dll with .NET 1.1 runtime version and it fails.

    Then the question is how one solve this?

    I would appreciate it if someone can point me to the right direction, thanks!!
    Friday, October 17, 2008 10:32 PM

Answers

  • There is no way that CLR V2.0 can be loaded into a process when V1.1 is already loaded.  What your manifest and config file accomplished was, presumably, to make sure that the very first time the CLR was needed, V2.0 got the selected instead of V1.1.  It is a fugly problem and the reason that .NET 3.0 and .NET 3.5 and .NET 3.5 SP1 still use the V2.0 version.  There's more insight into the problem in this thread.
    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Thursday, October 23, 2008 10:04 AM
    Tuesday, October 21, 2008 11:56 PM
    Moderator

All replies

  • There can be only one instance of the CLR in a process.  Whomever is first determines what version gets loaded.  If that's a .NET 1.1 program, by default the .NET 1.1 version of the CLR is loaded.  Blowing any future attempts to load .NET 2.0 assemblies.  You'll need to write an app.exe.config configuration file with the <requiredRuntime> element to override the default.  This versioning problem is the major reason you should never write a shell extension handler in managed code.

    Hans Passant.
    Saturday, October 18, 2008 1:36 PM
    Moderator
  • Thanks Hans, that makes sense.

    Regarding your suggestion to write an app.exe.config file, I assume you were referring to config file for the C#.dll, not for the client.

    My C#.dll does not have an exe application, hence, it does not have app.exe.config associate with it. It is used/called by unmanaged code component.
    So, to get around this, am I supposed to wrap my dll with an exe just so that I can use app.exe.config file to force CLR 2.0 to be loaded?

    or, should I write config file for my COM+ component?



    Monday, October 20, 2008 2:27 PM
  • No, dlls cannot have a .config file, it only works for whatever .exe loads the dll.  The CLR will find and use a .config file for an unmanaged .exe.  When you register the COM visible dll with Regasm.exe, it records what runtime version is required to use the assembly.  If you use the Regasm.exe from the V2.0 runtime directory (c:\windows\microsoft.net\framework\v2.0.50727), it should record the V2.0 version as the required CLR version.  Not 100% sure, verify by looking at the HKLM\Software\Classes\CLSID registry keys with Regedit.exe
    Hans Passant.
    Monday, October 20, 2008 3:13 PM
    Moderator
  •  That's what I gather that a dll cannot have a config file.
     Yes, I registered the dll with regasm.exe (v2.0), the registry shows the correct runtime version, as I mentioned earlier.

    When you say the following:
    The CLR will find and use a .config file for an unmanaged .exe. 

    Are you suggesting to write application.manifest and application.config for the COM+ application? Would CLR be able to find and read these files?  Ref: http://www.objectsharp.com/cs/blogs/bruce/archive/2004/02/06/269.aspx


    Monday, October 20, 2008 3:50 PM
  • Just FYI, writing application.manifest and application.config for the COM+ application is the answer.
    You can then specify the runtime version(http://msdn.microsoft.com/en-us/library/w4atty68.aspx) under application.config.

    The above works, my COM component is able to load my .NET 2.0 dll, when the client is .NET 1.1.

    Although, I wonder what is the implication on doing this? Is it possible that CLR 2.0 gets loaded first then causing an issue with the client that is in 1.1?

    • Marked as answer by Blackfield Tuesday, October 21, 2008 5:00 PM
    • Unmarked as answer by Blackfield Tuesday, October 21, 2008 6:03 PM
    • Edited by Blackfield Tuesday, October 21, 2008 6:07 PM
    Tuesday, October 21, 2008 5:00 PM
  • CLR 2.0 is quite compatible with 1.1 but there are of course differences.  Retesting your app would be recommended.
    Hans Passant.
    Tuesday, October 21, 2008 10:38 PM
    Moderator
  • Hans,

    You mentioned that there can be only one instance of the CLR in a process.

    However, in my scenario, when the .NET 1.1 client was fired for the first time, isn't the CLR 1.1 that get loaded first?
    Then, when my COM+ component was called by the client, then, and only then, the application.config for the dllhost.exe was read and the CLR 2.0 that was loaded?

    Your latest entry suggests that only CLR 2.0 would get loaded, thus it could cause possible compatibility issue with the .NET 1.1 client??

    This is the part that I am not clear about...

    I appreciate it if you can shed some light around this, thanks!

    Tuesday, October 21, 2008 11:22 PM
  • There is no way that CLR V2.0 can be loaded into a process when V1.1 is already loaded.  What your manifest and config file accomplished was, presumably, to make sure that the very first time the CLR was needed, V2.0 got the selected instead of V1.1.  It is a fugly problem and the reason that .NET 3.0 and .NET 3.5 and .NET 3.5 SP1 still use the V2.0 version.  There's more insight into the problem in this thread.
    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Thursday, October 23, 2008 10:04 AM
    Tuesday, October 21, 2008 11:56 PM
    Moderator