I'd like to have a List<int> that multiple instances of my application can access. At the moment I can cheat and use a global mutex but that hardly would work well after 10K ints. How do I get multiple instances of a program to share a list?
An easy way to do that is to put this data in a custom windows service.
Host in this service the data you want to share and provide access to this data using any kind of IPC. The simplest is WCF.
Another method may consists in having only one instance of the application. Instead of having on form in your app, manage multiple forms as separate "pseudo" instances. When firing the app again, check if the app is already launched and trigger a message to this app.
Lastly, as Raja suggest, use a queue to share data between apps. But this requires more information about how and when the list is populated.
Related
I have a three tier asp.net web app backed by SQL server express, with business logic in C#, and a web UI. I have a small collection of actions that exist as methods on objects in my business logic layer that need to run on a configurable, periodic basis. These actions rely on many other objects in my current app along with needing my data access layer to talk to SQL. Currently I manually log in to the admin site and kick off the actions via my UI as there are only two at the moment but that will grow.
A couple options I've considered but wanted thoughts on before I proceed...
I could create some scheduled tasks in Windows server to kick these actions off periodically but I want to know how would I expose these actions in the best way. I thought of creating a web service exposing them and building a tiny exe to call that web service but I would have to make sure that web service was locked down with security. Another option which I know a little less about would be exposing those actions via export and then building an app that could use them by referencing the DLL. It seems that app would get kind of large if it has to pull everything in to use unless I could componentize my app binaries more so it would only need a small binary or two.
Any thoughts on how I should approach this or pointers on content discussing this type of issue?
I had gone the way of tiny EXE that calls a WebService from main app and it seems to work well, but that was before I discovered Quartz.net.
Now I'd suggest use Quartz.net as a scheduler. From the site:
Jobs can be any .NET class that implements the simple IJob interface,
leaving infinite possibilities for the work Jobs can perform.
I want to be able to develop a windows service which is capable of running multiple instances each with different parameters.
Ideally I want to be able to maintain these parameters in a browser based control panel.
I have written a control panel in C# which saves the config data to an XML file.
From this I want to be able to configure the number of services to run, and what their parameters should be.
I want to be able to dynamically add and remove instances of the service as required.
My questions are:
1) Is this even possible?
2) Can I start a service with specific properties, from the control panel? (Maybe by using "NET START" with command line parameters?
[Edit]
I just saw something online regarding the ServiceController class; can this be used to add and remove instances of a service as well as start/stop services?
[/Edit]
Thanks for any help
Edit: My initial answer was factually wrong.
You can use command line parameters, either with NET START (which however will only accept parameters starting with a backslash) or with SC START (which will accept anything as a parameter).
You cannot start a service with dynamically chosen command line parameters. Parameters can also be specified at service registration time, in which case they remain constant thereafter.
However, starting multiple instances of a service sounds like the wrong idea. There is nothing stopping you from making just one instance of the service that you configure at runtime by communicating with it (e.g. with ServiceController.ExecuteCommand), which is what you should do IMHO.
To communicate with a service, see for example How to communicate with a windows service from an application that interacts with the desktop? and How to create and communicate with a C++ Windows Service in Visual Studio 2010?
I have three windows services in one C# project. Using the installer class (it contains three service installers and one process installer) I was able to install all of my services and start them as three different windows services.
Now I'm trying to run those services under one service name (I would like to see one service name in service control manager, not three). What would be the best approach to do this?
Thanks in advance!
You could just have one main service that spawns off the other executables as regular processes (see Process.Start(..)) which would not show up as windows services. That service would have to control the life time of the dependent processes (start them after the service was started /stop them before shutdown).
Create a new windows service and start 3 thread.
All you have to do is implement some principles of code reuse.
Move each of the respective work units into classes/libraries rather than services. Create a single service referencing the end result libraries. Your service intention is likely a timer of some sort, and possibly exposing API endpoints. Create the single service and activate the necessary classes from 3 unique timers (if needed - you might get away with a single timer activating 3 different class methods). Wrap events or API endpoints in a similar fashion. A services should contain little or no "business" logic, it should derive that work from referenced business libraries. Follow that practice and your question will mostly answer it's self.
I am working in VS 2008 C# and need to share an instance of an object created in one project with another project. I tried creating a static class in project1 and adding it as a link to project2, but the information wasn't saved. The static class was written in project1.
//object o = new object
//project1.staticObject = o
//project2.object = project1.staticObject
When I tried something like above, project2.object would be null. By adding a class as a link, is it creating a new instance of the static class in project2 or is it referencing the same class? If it is referencing the same class, shouldn't any information saved into the static class from project1 be accessible by project2? I know this isn't the most elegant manner of sharing data, but if anyone would help with this problem or provide a better manner of doing it, I would greatly appreciate it.
Thanks in advance.
Projects run in separate processes, so they can't share data in this manner. You'll need to persist the data in another type of store. I recommend using a database (hey, 20 gazillion websites, stock trading apps, airlines, etc can't be wrong).
If you don't want to use a database, you could open an IP connection between instances of the app and have a thread send packets of data to sync back and forth between the applications. Or, in your "server" app, add a web service that each process would call to update and retrieve information.
If you need really high-speed communication between the processes, sockets with a peer or star topology is a good way to go. If you're okay with some latency, having a web service (which works fine even if these aren't web apps) or a database could be a good solution. The right approach depends on your application.
WCF could also solve this problem. It effectively wraps the IP/socket layer and provides some nice object persistence/remote control capabilities, but I find it overly complex for most applications.
To share a single instance of an object among different processes (that's what I think you are intending to do) you need something that will maintain that object's state. You can look at the WCF and how to set up it's behaviour to act as a singleton so essentially every requester gets the same instance across the board.
http://msdn.microsoft.com/en-us/magazine/cc163590.aspx
Creating the link creates only applies to the source code. When you compile each project, it then has that single class definition available in both projects. The process you took does nothing for instances during runtime for sharing.
You can look at WCF or .NET Remoting, although .NET Remoting is now officially replaced by WCF.
If you are talking about sharing the same object between two processes, you can do that, the concept is called memory-mapped files. Here is some starter docs from msdn.
Though the docs and API use the term "FileMapping" quite a bit, you can use it just for sharing memory between two processes.
In .NET 4.0, you can use the System.IO.MemoryMappedFiles namespace. For your case, looks like .NET 3.5, you'll have to use some sort of interop to use the Win API.
like this
public class MyClass {
public static instance = new MyClass();
private List<int> idList;
}
.
I am using this class in two different window application. like this MyClass.instance.IdList.Add(1); All data in idList i am storing in file and fetching info from that file. I am adding value to idList in one app and I am fetching idList info in another app. but it is not showing idList content in second application which is added by first apllication. How to achive this?
Here are a few ways to share data between applications:
WCF would be my preferred way to do this and I will add some explanation here
1) Use of WCF
- Host a WCF service with following functionality [Effort: Moderate]
//Notice the use of Publisher -Subscriber pattern here (each app will subscribe to the service, the service could be hosted by all apps at certain endpoint i.e. net.pipe://localhost/NotificationService (Since multiple applications will try to host the same service only one would succeed and that's exactly what we want)
void Subscribe(object);
void Unsubscribe(object);
// Any client wanting to add an object to the list will call Add
void Add(object objectToAdd);
// Iterate through each subscribing app and send a notification that list changed
void Notify();
// Return the current state of list
IEnumerable<object> GetYourList();
2) Use of Clipboard [Effort: Simple]
3) Use of File system & listening to the file change notification
[Effort: Simple]
4) Memory Mapped Files [Effort: Simple-Moderate]
Maybe Remoting helps you. It allows you to let other applications access functions in your server application over the internet (or a local network). So the code is executed on the server application.
Here is an example: http://www.codeproject.com/KB/IP/Net_Remoting.aspx
Maybe you are aware of this already, but types declared static are local to a single process (application). Reading your example it appears that you are expecting the static instance to be shared and accessible between applications. This is not the case.
A standard way to do what you need is to create a 3rd application/process that exposes synchronised access to a list that both of the other applications can add/remove items from.
why not you are using xml as a mediator between two application. Use XML for the communication.
If you are gonna use .Net 4.0, you could use Memory Mapped Files.
I think this is the prefect candidate for a Message Queue
With the message queue, you can add IDs to the queue in one app, and pull them off in another.
This page gives a good example of how to implement queues: Use Microsoft Message Queuing in C# for inter-process communication
The MSDN gives an example service here: C#: A Message Queuing Service Application
Message Queue is the best way of communicating.
However cheque that you need to enable the "Microsoft Message Queue" component before you can use the service.
Further, we can get real time data exchange as it also creates event, if configured to do so. and FIFO way of accessing the message will enable to process each and every message without missing any single message.
In my case, I had 2 application
WCF Service based application
Windows application
I had used Message Queue to overcome this data sharing issue
Add how much ever queue you want.
Its a blocking read, hence your application doesn't overrun and hog the CPU.
Pretty reliable, no Data loss.
Add Header along with Each data, to recognize it what type of data is this.
How to use :
Create private queues.
push data into it from client side.
another side read and parse it.
How about using the SQL Server Compact Edition?