Using COM without registering.
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 15 of 15

Thread: Using COM without registering.

  1. #1
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,067

    Using COM without registering.

    In a C++ project, I need to call a C# created COM object (as a .dll)

    Is there a way to use such a COM object without having it be registered in the registry?


    The C# COM dll is just a "go between" our C++ code and a .NET library, there's no "COM contract" of any kind, the COM interfaces change each version. The fact it's COM and needs registration is annoying because it makes it hard to have multiple versions of our software installed (needed under some circumstances) and running at the same time.

    Ideally, I'd like a way to not have any registration at all. And just be able to do a LoadLibrary("c:\\TheRightPath\\com.dll") of the right dll and then get going from there. Is this doable (and how) ?

  2. #2
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,051

    Re: Using COM without registering.

    Registration-Free Activation of COM Components: A Walkthrough


    Quote Originally Posted by OReubens View Post
    The C# COM dll is just a "go between" our C++ code and a .NET library, there's no "COM contract" of any kind, the COM interfaces change each version.
    If so, why to mess with COM? Why not just build a managed C++ dll?
    Last edited by Igor Vartanov; March 5th, 2013 at 06:08 AM.
    Best regards,
    Igor

  3. #3
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,594

    Re: Using COM without registering.

    Quote Originally Posted by Igor Vartanov View Post
    If so, why to mess with COM? Why not just build a managed C++ dll?
    Yes, I agree that this is most probably the way to go: write a native wrapper around the .NET library. In fact that's a rather common technique in native-managed-interop. (AFAICT it's more common to do the opposite, i.e. write a managed wrapper to integrate a native library into a .NET project, but the techniques are similar.)

    You'd then have the original .NET library DLL, your wrapper DLL exposing a native C/C++ interface, and that would then be loaded by your native app. That's pretty much like the LoadLibrary() approach you're aiming for.
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

  4. #4
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,067

    Re: Using COM without registering.

    Any guides/totorials available for that managed wrapper thing ?

  5. #5
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,594

    Re: Using COM without registering.

    Many of the threads in the C++/CLI section deal with interop scenarios. However, already said, the opposite of your specific scenario, i.e. wrapping a native library to make it accessible to .NET code, is more common. Maybe you can have a look at some of the threads to get an overall impression of what native/managed interop is about. And of course I'll be happy to answer your related questions over there (if I can ).

    I don't know of any real interop tutorial, but perhaps others do and can point you there. And maybe I can put together a minimalistic "Hello World"-style native wrapper sample and post it in the C++/CLI section.
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

  6. #6
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,067

    Re: Using COM without registering.

    No it's indeed listed as I said in the OP.
    I have a library written in .Net C# (not by me), and I need to use this from a C++ native program.

    I know I need some kind of "glue" in between the library and my c++ code. That's what the COM is doing at the moment, a .net .dll exposing a COM object. I'll have a look over there over the weekend. if a C++/clr wrapper can do this better, then that'd be great.

  7. #7
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,594

    Re: Using COM without registering.

    So now I have set up a native wrapper sample and posted it in http://forums.codeguru.com/showthrea...wrapper-sample. It's rather a starting point for discussion than a complete tutorial, so comments are quite welcome of course.
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

  8. #8
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,067

    Re: Using COM without registering.

    Thanks

    got the basics of this working, the real challenge now will be to rewrite the C# com-dll code that uses the C# library into c++ code, which is a bit of an issue atm. I know native C++, but not /CLR and the C++/CLR syntax and framework usage is alien enough to feel like a fish on dry land. My collegue knows C# and .NET but doesn't know C++ and isn't comfortable with it either.

    From your other thread post:
    While I agree that from a performance perspective, there's probably little difference in either approach. The big advantage of the c++ wrapper is that you don't need to rely on global registration which is a big issue if you need to support multiple simultaneous versions (or even multiple different instances/installations of the same version) of your "glue" dll.



    One issue I noticed. when doing the FreeLibrary(hDotNetDll); I notice the .dll (and everything it needed) isn't actually being unloaded. Is this always the case for these .net things, is this simply delayed, or is unloading overridden ? Is there a way to force the actual unload.

  9. #9
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,594

    Re: Using COM without registering.

    Quote Originally Posted by OReubens View Post
    One issue I noticed. when doing the FreeLibrary(hDotNetDll); I notice the .dll (and everything it needed) isn't actually being unloaded. Is this always the case for these .net things, is this simply delayed, or is unloading overridden ? Is there a way to force the actual unload.
    Interesting. I didn't ever encounter that, simply because I never tried unloading a .NET DLL that had been loaded by a native app. At least when it comes to .NET apps, the framework can't unload individual DLLs, it just can unload application domains, which are sort of containers for .NET executable modules (assemblies). By default, a .NET app has a single application domain and DLLs are loaded into that. If a developers want the ability to unload DLLs (or specific groups of DLLs) without shutting down the entire app, they can explicitly create a separate application domain and load the DLL(s) into that. That application domain can then be unloaded later. (I think, however, function calls between application domains are slightly slower than intra-domain calls.)

    Probably your unloading issue is somehow related to the above. Fixing it isn't easy though, I'm afraid: If you write a .NET bootstrap loader DLL that is able to load your actual DLL into it's own application domain and unload that later, at least the "root" application domain created for the bootstrap DLL would remain loaded. There are some mechanisms to control interaction with the .NET runtime on a lower level, allowing finer control of what's going on, so they maybe can be used to fix the unloading issue. I have never used them yet, though, and would need to do quite a bit of research on that topic. If you find out anything interesting on your own, I'd be happy if you keep me informed.
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

  10. #10
    Arjay's Avatar
    Arjay is offline Moderator / MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    11,441

    Re: Using COM without registering.


  11. #11
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,067

    Re: Using COM without registering.

    The above is all C# which I don't know. I also don't get what it's all about. (neither does my collegue)
    From the perspective of the native C++ app. This native app doesn't use .net at all. except for the couple functions in the .net dll.

    Only when it loads the .net dll through LoadLibrary and calling one of the exported functions does it load the .net framework and whatever other dll's it needs (quite a lot of them)

    I would have expected that FreeLibrary(hDotNetDll) would have unloaded the wrapper dll and the entire .net framework along with it. But none of the sort happens, the .net dll remains loaded, and the entire .net framework with it.

    I'm not sure how these "application domains" even come to play in the native app. Don't your app domain suggestions imply that it's a .net issue and that whatever you do at the least the .net framework will always remain loaded even if it manages to unload the c++ wrapper dll ?

    --

    This .net dll (through the library) provides some features which are only needed when the main app is in a "shut down" state, or when opening configuration mode. In that case there's plenty of free memory. When the app is running, I really want that memory .net framework the wrapper and the .net library is using to be recuperated.

  12. #12
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,594

    Re: Using COM without registering.

    I find the article that Arjay linked to quite interesting. I think in essence the concept presented there is much like what I referred to as "bootstrap DLL". And as such I'm afraid it doesnt solve the "root app domain" issue I alluded to in post #9 either. However, it has been suggested by Arjay , so I think it's worth testing it in practice to verify I wasn't wrong actually. So I'll go and implement a port of that Idea stripped down to the minimum required in the demo project from the other thread to see what happens, when I find the time.

    Being able to simply explicitly unload the entire .NET runtime from your app's address space of course would be the coolest option, but that's one of the low-level things I mentioned that I'd need to do further research on.
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

  13. #13
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,051

    Re: Using COM without registering.

    Quote Originally Posted by OReubens View Post
    I would have expected that FreeLibrary(hDotNetDll) would have unloaded the wrapper dll and the entire .net framework along with it. But none of the sort happens, the .net dll remains loaded, and the entire .net framework with it.

    --

    This .net dll (through the library) provides some features which are only needed when the main app is in a "shut down" state, or when opening configuration mode. In that case there's plenty of free memory. When the app is running, I really want that memory .net framework the wrapper and the .net library is using to be recuperated.
    Is that really a problem, or you just imagine it could be, yet without any proof?
    Best regards,
    Igor

  14. #14
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,067

    Re: Using COM without registering.

    It really is a problem.

    The application has a much bigger virtual footprint, and a lot of extra memory gets being used by either loaded .dll images and memory being commited towards private data (local variables needed by the framework, whatever memory the .NET garbage collector is using as it's base memory pool etc. and the JIT compiled .NET binary to native code)

    If the memory is no longer actually accessed, then you'd thing it doesn't matter:
    * .dll images are demand loaded anyway. (well except for .NET ones since those aren't native and need JIT compilation)
    * Any other data will eventually be paged out and shouldn't be a bother

    Or so you'd think. In this case, the real problem comes from the fact that the dll's and all the extra allocated memory fragments and reduces the available memory address space. Not really that much of an issue for a Win64 build, but devastating for our Win32 build.

  15. #15
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,594

    Re: Using COM without registering.

    Just in case you haven't subscribed to it, I'd like to notify you that I've just posted an enhanced version of the wrapper demo over there in the companion thread in the C++/CLI section, which now supports unloading the wrapped managed DLL.
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center