1

We have a C# .NET Core 3.1 app which needs to call a legacy .NET Framework 32-bit DLL (and we don't have the source code).

The only way I can think to do is is to either force our whole app to target 32-bit only, or make a web service / microservice which wraps the 3rd party function to make it available over HTTP.

However I just wondered if there are any alteratives to HTTP for something like this, given that the calls will be local to the application and the processes will always be on the same machine. I am presuming there is no way to 'wrap' the 32 bit DLL and reference it directly, so I guess two processes which communicate is the only solution, but does that have to be HTTP or is there another way?

Edit:

The main thing I am trying to avoid was the inconvienence of having to have a separate project and web host for this one DLL.

NickG
  • 9,315
  • 16
  • 75
  • 115
  • Maybe this can help you: https://stackoverflow.com/questions/359331/access-x86-com-from-x64-net – TheTanic Feb 15 '21 at 11:39
  • 4
    There are lots of other ways. Database. File system. Queues. Sockets. etc etc See also https://stackoverflow.com/questions/58549763/how-should-ipc-be-handled-in-net-core . – mjwills Feb 15 '21 at 11:39
  • @mjwills yeah I looked at named pipes, sockets etc but the more I look into it, I think that if there's no way to just "wrap" the DLL to make it 64 bit compatible, then HTTP is actually easier than the older/legacy methods. – NickG Feb 15 '21 at 11:42
  • 2
    The "current" solution would be gRPC services. They are http/2 based, but they don't need iis. Microsoft removed remoting (that was the "original" interprocess communication way of .NET) in .NET Core. Microsoft removed WCF too from .NET Core. There is a [github](https://github.com/CoreWCF/CoreWCF) with a .NET core replacement for WCF, but they say it isn't production-ready – xanatos Feb 15 '21 at 11:44
  • TCP socket communication wouldn't care if the communicating processes are 32 or 64 bit. Neither would any kind of message queue (e.g. msmq), or virtually any other transport / communication protocol you could think of. They're usually designed such that the details of the communicating systems are abstracted away...each side must simply adhere to a common format and procedure for sending messages. How each side actually implements that is irrelevant to the act of communicating. You have a huge array of possibilities. Choose whatever makes the job easiest for your scenario. – ADyson Feb 15 '21 at 12:17
  • So in conclusion, yes you need a second program to wrap around the other DLL, and it needs to listen for incoming messages and be able to respond to them. But they needn't be HTTP messages, necessarily. – ADyson Feb 15 '21 at 12:20
  • `The main thing I am trying to avoid was the inconvienence of having to have a separate project and web host for this one DLL`...you can't really avoid the separate project, but you can likely avoid the web host part, if you use a different means of communication. If you look at it more positively, you'd then have a separate API for this DLL which could be re-used almost like a microservice, if you have other apps which might want to make use of it. – ADyson Feb 15 '21 at 13:23
  • 1
    One possible approach, which would work if the DLL hosting app only needs to be accessible to one instance of your main app, is to have the main app start the host app and communicate with it via its standard IO pipes (stdin/stdout/stderr). – glenebob Feb 15 '21 at 14:33

1 Answers1

1

If I understood it correctly, you'd like to run two processes on the same machine that should communicate with each other.

The first process is your x64 process doing it's normal stuff and a second x86 mini application that should host your 3rd party library and provide some interface to access the methods of this library.

IMHO the most easiest way (today) would be to setup a little console application running asp.core providing an REST API. But that's only true, if your 3rd party host should be stateless, gets all needed parameters on each call and can immediately answer your requests.

If you need to configure some local state within the host application (through some calls) and / or the requests need more time to answer (cause the library just needs several minutes to compute the result) you could also design all these things also with REST. For example the long running request returns immediately an operation id and through a second REST call you could request the current state of the processing.

But this is maybe not really REST anymore. In that case maybe named pipes are a better candidate, cause it is a really bi-directional communication. But be aware that you are closer to the metal and you have to take care for communication breaks, incomplete messages, etc.

Oliver
  • 43,366
  • 8
  • 94
  • 151