• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Exporting .NET entry points to unmanaged code

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    Exporting .NET entry points to unmanaged code

    Ok, I have some .NET code which does some allegedly useful things for some shiny new .NET code. Obviously this just calls it.

    There are in fact, only about half a dozen entry points and they are also all static.

    The code is in fact a replacement for some existing API's. These are currently accessed from a variety of clients. 'C'. Cobol, VB5, VB6 and also some C# and VB.Net; may be others nobody has told me about.

    I need to make the new code accessible to the old clients. I see two methods, but wonder if there may be others which may be easier. I'm not too bothered about the fact the existing clients have to change, that can be done.

    1. Use COM

    Create a C# DLL which expose the methods on a COM visible class, the clients can then call that.

    Pro: Simple for the VB5/6. Can be implemented in the Assembly with the new code. Major pain (but not impossible) for the C and Cobol clients
    Con: Call overhead through Com, registering etc on deployment. But the overhead isn't really an issue since they are functional rather than chatty

    2. Use C++

    Create a mixed C++/CLR DLL; decorate the methods to expose a flat API.

    Pro: Basically the same interface as currently exists, save it is different DLL
    Con: Forces a bridge to be inserted between the application and the new code providing service.

    ---------
    Any other methods I should consider (I can move forward to any version of Visual Studio and the framework if needed).

    In an ideal world I would just like to decorate the static methods with a mythical [MakeThisAvailableAsAFlatAPI] attribute.

    I don't envisage any problems with parameters since they are all primitive data types and one block of data so should be able to marshal these without difficulty.

    #2
    No idea, but the .NET C# -> COM marshalling is pretty sweet. Works very nicely for a C++ client but from your comments using COM in C is much more messy?
    Originally posted by MaryPoppins
    I'd still not breastfeed a nazi
    Originally posted by vetran
    Urine is quite nourishing

    Comment


      #3
      I've done option 2 a couple of times before, and the reason was the COM option just got very headachy, and when you're dealing with more complicated data structures and memory allocation it starts to feel like a lot of hard work.

      But I've no idea about calling C++/CLR from VB or Cobol. And C++/CLR is a bit of a black art.
      Will work inside IR35. Or for food.

      Comment


        #4
        Cheers Guys,

        I've done the COM route quite often only headaches have really been around registration of the DLL etc and the fact that static methods are not visible. However producing a COM object which just calls the static method is not a problem.

        The existing code just calls an API and the developers view (understandably) is "well it should just carry on doing that.

        The guy with the C client started muttering about "CoCreateInstance and all that".

        So, given it is all just a pure wrapper I can do both the Com variant to give the VB guys what they want (they prefer a com interface to the existing API and in fact implemented that internally).

        I will also do 2; which since I am only wrapping looks OK and decorate as external for flat api calls. The 'C; guy then gets the choice of a com or flat interface. This also means that the flat API will continue to exist for the Cobol (which I will have to change, but moving that to use COM is a major effort which needs a Cobol -> C wrapper to do the creation and invocation anyway).

        Comment


          #5
          I've used this many times to call .NET assemblies from C and C like languages.

          https://sites.google.com/site/robert...managedexports

          Works a treat. Simply install the nuget package and mark the entry points with DllExport attribute.

          Here's a tutorial that shows it being used with the C like language MQL5 used in a trading platform.

          https://www.mql5.com/en/articles/249
          Last edited by DimPrawn; 10 November 2015, 09:43.

          Comment


            #6
            Originally posted by DimPrawn View Post
            I've used this many times to call .NET assemblies from C and C like languages.

            https://sites.google.com/site/robert...managedexports

            Works a treat. Simply install the nuget package and mark the entry points with DllExport attribute.

            Here's a tutorial that shows it being used with the C like language MQL5 used in a trading platform.

            https://www.mql5.com/en/articles/249
            DP,

            Thanks, that is very useful. The nuget way certainly seems easiest to save writing C++ wrappers and export those.

            Todays cureveball though. It appears a Linux variant of the new code is going to be required in the future.

            So, that would suggest either using Mono (which they are not keen on for reasons that I do not yet know) or rewriting the damn thing in C anyway.

            Comment


              #7
              You're aware of the official 'Mono' stuff going on? Big changes now they've open-sourced a lot of .NET and so on, though it's not my area so you might already be more informed than me.
              Originally posted by MaryPoppins
              I'd still not breastfeed a nazi
              Originally posted by vetran
              Urine is quite nourishing

              Comment

              Working...
              X