How to start separate processes integrated in one wpf application in c# and how to communicate between them?
What I want is somthing like Internet Explorer.
In this case I want to Integerate several applications into one individual application with separate processes
The simplest way is to use the System.Diagnostics.Process class and named pipes.
But, generally, this would hurt the maintenability (see other responses).
For processes running on different machines, you better have a look at WCF.
Related
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.
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.
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)
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?
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.
Mutex is one of solution for exclusive control of multiple processes.
***But Mutex will sometimes occur dead lock. Be careful if you use.
How would I make it so that I have one main program with a background process that "listens" for catches (via a function like sendDebugInfo(Exception e) for example) and then unhide the second console and display the message but if the user closes the debug window it doesn't exit the program.
If the above isn't clear enough here is a simple version:
Console application 1 function helloWord() is used
Console application 1 function helloWorld() sends a String to a second console window (but within the same project)
The second console displays "hello world".
You are really asking about inter-process communication (IPC).
There are many ways to achieve IPC. I suggest you have a look at Named Pipes. They are easy to use and quite reliable.
http://msdn.microsoft.com/en-us/library/system.io.pipes.aspx
The basic idea behind Named Pipes is that you have a named resource that you can write messages to in one process and read messages from in the other process. The message can be anything you want. The processes connect to the pipe simply by using the pre-agreed name for it.
Just for clarification, saying that you want two console applications running in different threads is somewhat misleading. Console applications typically run on different processes entirely and since threads are not shared between processes two console applications running in different threads is the norm. However when you say this explicitly it sounds like you're trying to run them on the same process but different threads which I'm not even sure is possible.
That said, Eric J. is right you really seem to be asking about IPC which can be performed in a number of ways. Named pipes is one way and TCP loopback is another. If you want these applications to run on separate machines at some point you're going to want to use TCP. Otherwise named pipes are a lot easier to deal with.
I'd suggest reading up on IPC, figuring out which method suits your needs and try to make it work. When you run into a specific issue like "my messages aren't getting through" or something then you should come back and search for a similar question or create a new question.
Not really sure how to ask this question because I really don't know what I'm talking about. I have two DLLs (.NET), each is an AddIn that runs in two different application processes i.e. application one loads DLL one and application two loads DLL two. I wanted these DLLs to be able to communicate while loaded. In each DLL, I know the exact class that will be instantiated by the host process and I want these two living objects in each process to be able to communicate (call methods on each other). This seems like it would be possible. Has anyone done something like this before?
Although some might say a dprecated technology .Net Remoting is suited to this kind of inter-process object instance communications on the same host.
try to specify your requirements better please... there is .NET remoting to access and consume instances of objects running in another process/machine but should be used only when required.
in general WCF can be used to communicate between applications and processes but again it depends if you only want to call methods or also and absolutely have object level IPC.
I design an application back-end. For now, it is a .NET process (a Console Application) which hosts various communication frameworks such as Agatha and NServiceBus.
I need to periodically update my datastore with values (coming from the application while it's running).
I found three possible ways:
Accept command line arguments, so I can call my console app with -update.
On start up a background thread will periodically invoke the update method.
Create an updater.exe app which will do the updates, but I will have code duplication since in some way it will need to query the data from the source in order to save it to the datastore.
Which one is better?
Use the simplest thing that will work. Sounds like option 1 is the way to go based on the info you have given.
Option 2 has threads, threads always complicate programs, more difficult to debug and write, greater chance of bugs.
Option 3, would mean that you have two apps, if you make a change you will have to deploy new versions of both, increasing maintenance costs.
Hi everyone I want to ask all of you one question related to application domain.
In .Net appdomain acts as a security boundary and two applications can run in two different domains within same process, but when i try to run multiple instances of an exe it shows in different processes in task manager.
Why is it so?
Why does it not show in same process with different appdomains?
Also is there is a way to do this i.e. multiple windows application in different appdomain inside same process.
Appdomain is a feature of the .NET framework. When you run exe's in Windows, they are started as separate processes, no matter what they are, the Windows loader doesn't care.
Theoretically, you can run any number of apps in the same appdomain, but why would you want that, if you don't need its benefits?