Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C#
  4. [Updated] AnyCPU and exposing functionality via COM

[Updated] AnyCPU and exposing functionality via COM

Scheduled Pinned Locked Moved C#
comcsharpbusinessbeta-testinghelp
3 Posts 2 Posters 1 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    Matt T Heffron
    wrote on last edited by
    #1

    (I'm not sure if this would be better asked in the COM forum... or QA...) Is there a way to implement C#-implemented functionality via COM (for adding to legacy code) in such a way that I need build only an AnyCPU targeted dll that can then be used via COM either 32 or 64 bit? ================ Update May 18, 2016: As it turns out, setting the build target to AnyCPU and selecting the "Register for COM interop" in the build settings does work. It appears to register the class in both HKCR and HKCR\Wow6432Node\CLSID (and the interfaces and type library in both, as well). In my defense, this was originally written in C#, and the 32 bit COM requirement was added, so I first went down the explicit 32 bit COM path, and then I tried to add the 64 bit COM. If I had known about the COM up front I probably would have just done it this way in the first place. And lest anyone blame the provider of the requirements... I started this side project because I overheard coworkers discussing how to solve this conceptual issue and what they were thinking was only going to give the appearance of solving the issue. I thought that the correct solution shouldn't be difficult, so I started. When I told them what I'd accomplished, then they informed me of the COM requirement (for use by the legacy application). ================ I have a C# assembly that implements some functionality and it works fine when invoked from within C#. There's one entry point class which implements the functionality, and exposes a support class's functionality via another interface. Like:

    public class DSS
    {
    // implement functionality, methods, etc. including:
    public ITSF TSF { get; private set; }
    }
    public interface ITSF
    {
    string Prop1 { get; set; }
    // etc.
    }

    I have enabled COM using the [assembly: ComVisible(true)] in the AssemblyInfo.cs. I then added [ComVisible(false)] for things I didn't want visible to COM. (Doing it the other way around didn't seem to do the "right thing".)

    [ComVisible(false)]
    public class DSS
    {
    // implement functionality, methods, etc. including:
    public ITSF TSF { get; private set; }
    }
    [Guid("...")]
    [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
    public interface ITSF
    {
    string Prop1 { get; set; }
    // etc.
    }

    I wrote a separate class to wrap the entry point class, and it implements an interface to expose the functionality in a COM-friendly way. (I.e., d

    G 1 Reply Last reply
    0
    • M Matt T Heffron

      (I'm not sure if this would be better asked in the COM forum... or QA...) Is there a way to implement C#-implemented functionality via COM (for adding to legacy code) in such a way that I need build only an AnyCPU targeted dll that can then be used via COM either 32 or 64 bit? ================ Update May 18, 2016: As it turns out, setting the build target to AnyCPU and selecting the "Register for COM interop" in the build settings does work. It appears to register the class in both HKCR and HKCR\Wow6432Node\CLSID (and the interfaces and type library in both, as well). In my defense, this was originally written in C#, and the 32 bit COM requirement was added, so I first went down the explicit 32 bit COM path, and then I tried to add the 64 bit COM. If I had known about the COM up front I probably would have just done it this way in the first place. And lest anyone blame the provider of the requirements... I started this side project because I overheard coworkers discussing how to solve this conceptual issue and what they were thinking was only going to give the appearance of solving the issue. I thought that the correct solution shouldn't be difficult, so I started. When I told them what I'd accomplished, then they informed me of the COM requirement (for use by the legacy application). ================ I have a C# assembly that implements some functionality and it works fine when invoked from within C#. There's one entry point class which implements the functionality, and exposes a support class's functionality via another interface. Like:

      public class DSS
      {
      // implement functionality, methods, etc. including:
      public ITSF TSF { get; private set; }
      }
      public interface ITSF
      {
      string Prop1 { get; set; }
      // etc.
      }

      I have enabled COM using the [assembly: ComVisible(true)] in the AssemblyInfo.cs. I then added [ComVisible(false)] for things I didn't want visible to COM. (Doing it the other way around didn't seem to do the "right thing".)

      [ComVisible(false)]
      public class DSS
      {
      // implement functionality, methods, etc. including:
      public ITSF TSF { get; private set; }
      }
      [Guid("...")]
      [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
      public interface ITSF
      {
      string Prop1 { get; set; }
      // etc.
      }

      I wrote a separate class to wrap the entry point class, and it implements an interface to expose the functionality in a COM-friendly way. (I.e., d

      G Offline
      G Offline
      Garth J Lancaster
      wrote on last edited by
      #2

      I think Ive seen two 'part solutions' to this, - the first involved late loading with LoadLibrary from c# ... - the second involved modify the dll search path using ? SetDllDirectory Both techniques mean you had 32 and 64 bit builds of the assembly that used the COM library I'll see what I can dredge up, Im interested in this myself

      M 1 Reply Last reply
      0
      • G Garth J Lancaster

        I think Ive seen two 'part solutions' to this, - the first involved late loading with LoadLibrary from c# ... - the second involved modify the dll search path using ? SetDllDirectory Both techniques mean you had 32 and 64 bit builds of the assembly that used the COM library I'll see what I can dredge up, Im interested in this myself

        M Offline
        M Offline
        Matt T Heffron
        wrote on last edited by
        #3

        Garth, I think you misunderstood the issue. I have a C# assembly that is exposing functionality via COM. I will be using it both from a managed C# application and a legacy application: old, unmanaged C++ that can't be wholesale ported. (But ought to be!) I'd like to register a single AnyCPU dll so it can be used if the managed application is either 32 or 64 bit, as well as by the legacy app via COM. I suppose I can only register the 32 bit COM, at least for now. But can I do that with an AnyCPU dll, or do I still need to build two versions of the dll: 32 bit (==x86) for COM, and AnyCPU for managed app use?

        "Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed." - G.K. Chesterton

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups