CODEWITHSUNDEEP
c#.netdll
Danielhobby
Danielhobby

Reputation: 33

C# Restricting DLL's to only one instance

I essentially want to make an api for an application but I only want one instance of that dll to be running at one time.

So multiple applications also need to be able to use the DLL at the same time. As you would expect from a normal api.

However I want it to be the same instance of the dll that the different applications use. This is because of communication with hardware that I don't want to be able to overlap.

Upvotes: 3

Views: 1870

Answers (5)

Leandro
Leandro

Reputation: 1555

This is an XY-Problem type of question. Your actual requirement is serializing interactions with the underlying hardware, so they do not overlap. Perhaps this is what you should explicitly and specifically be asking about.

Your proposed solution is to have a DLL that is kind of an OS-wide singleton or something like that. This is actually what you are asking about; although it is still not the right approach, in my opinion. The OS is in charge of managing the lifetime of the DLL modules in each process. There are many aspects to this, but for one: most DLL instances are already being shared between every process (mostly code sections, resources and such - data, of course, is not shared by default).

To solve your actual problem, you would have to resort to multi-process synchronization techniques. In Windows, this works mostly through named kernel objects like mutexes, semaphores, events and such. Another approach would be to use IPC, as other folks have already mentioned in their respective answers, which then again would require in itself some kind of synchronization.

Maybe all this is already handled by that hardware's device driver. What would be the real scenarios in which overlapped interactions with the underlying hardware would have a negative impact on the applications that use your DLL?

Upvotes: 1

Takuya Fujiwara
Takuya Fujiwara

Reputation: 75

Mutex is one of solution for exclusive control of multiple processes.

***But Mutex will sometimes occur dead lock. Be careful if you use.

Upvotes: 0

Jcl
Jcl

Reputation: 28272

You can't do that as you intend to do. The best way to do this would be having a single process (a DLL is not a process) which receives and processes messages, and have your multiple clients use an API (this would be your DLL) that just sends messages to this process.

The intercommunication of those two processes (your single process and the clients sending or receiving the messages via your API) could be done in many ways, choose the one that suits you better (basically, any kind of client/server architecture, even if the clients and the server are running on the same hardware)

Upvotes: 2

Ryszard Fiński
Ryszard Fiński

Reputation: 462

To ensure you have loaded one DLL per machine, you would need to run a controlling assembly in separate AppDomain, then try creating named pipe for remoting (with IpcChannel) and claim hardware resources. IpcChannel will fail to create second time in the same environment. If you need high performance communication with your hardware, use remoting only for claiming and releasing resource by another assembly used by applications.

Upvotes: 0

Anton Gogolev
Anton Gogolev

Reputation: 115711

DLLs are usually loaded once per process, so if your application is guaranteed to only be running in single-instance mode, there's nothing else you have to do. Your single application instance will have only one loaded DLL.

Now, if you want to "share" a "single instance" of a DLL across applications, you will inevitably have to resort to a client-server architecture. Your DLL will have to be wrapped in a Windows Service, which would expose an HTTP (or WCF) API.

Upvotes: 4

Related Questions