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.
Related
In my solution I have 3 projects
MyProject.Core
MyProject.Services.DataImporter
Myproject.Services.Cars
Both DataImporter and Cars projects are referencing MyProject.Core project.
I have an event (DataImportFinishedEvent) which is emmited by DataImporter service.
Services.Cars is subscribed to this event and potentially more services later.
With my current approach, I have this event (DataImportFinishedEvent) as a file created
on both services.
Since both services are referencing Core project should I move this event to the Core project? Doing so will have file on one location only.
Is this a good microservice practice?
In general have common projects or libraries is not a good practice in microservices because this way you are coupling the develop and deploy of both services, so when you make a change in the common project, you have to change and deploy the two other microservices.
In the case of the event, the best way is to have different events in both of the services. This not necessarily means that they have to be duplicated. In the producer side you must have an event with all the information needed by any of the potential consumers and in the consumer side you must have an event with the information needed by that service, that can be less.
This way, you decouple the two services and if tomorrow the consumer service need other information provided by the producer you only have to change the consumer side and vice-versa
One way to think about it is when you are consuming a third party api that you are not controlling, you build your own response object with the data provided by the api that you need and this object is different that the one used by the api.
Is it possible to run parallel ASP.NET Core pipelines from within the same main application. I want to expose an endpoint for external consumers and would like to register only few services for that endpoint when compared to main application. Is there any way to properly do it in asp.net core?
I could see a similar implementation here and it is almost 2 yrs old. Is there a better way to do it? Or is it the only way right now?
https://www.strathweb.com/2017/04/running-multiple-independent-asp-net-core-pipelines-side-by-side-in-the-same-application/
So, what problem in this solution? You can use Map, MapWhen, UseBranchWithServices. It's good solution.
One more point is to try create two hosts in main. But I not realy enshure that it can be implemented.
One another solution, you can create independent app and setup nginx (iis) in the front of 2 instances. Then you get the independent pipeline, independent configuration, you can deploy it to different machines and so on.
But when you change the code you should redeploy 2 applications in the same time.
So, you should answer on question: is it should be independent part of system, you you want to some small specific configuration for this API.
If you need first variant please use another instance, if second - use MapWhen, UseBranchWithServices and so one.
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'm about to design my Web service API, most of the functions of my API is basically very simular to my web application.
Now the question is, should I create 1 single method and reuse them for both the web application and the web service api? (This seems to be the logical solution, however its very complicated; it's much easier to duplicate the method used by the web application, and keep both separate, ie one method for the web application and one method for the web service.)
How do you guys do it?
1) REUSE: one main method and reuse them for both web application and web service application (I like this but it's complicated)
WebAppMethodX --uses-->
COMMONFUNCTIONMETHOD_X
APIMethodX ---uses---->
COMMONFUNCTIONMETHOD_X
ie Commonfunctionmethod_x contains reusable set of common features
PRO: less code, less maintenance, less bugs.
CON: very complicated
2) DUPLICATE: two methods, one method for the web application and one method for the web service.
WebAppMethodX
APIMethodX
PRO: simple
CON: duplication = more code, more maintenance, more bugs!
Your use case will very likely be different for your public webservice API than for your internal application API. Create a common service project / tier and use that same tier from both your web app and your public-facing webservice API. Create a separate http-invokable method for each of your web app and your webservice.
It comes down to there being
1) different security concerns. For instance, it is nice (often required) to provide a sample client application making use of your public API so that others can easily get up to speed with what you've provided. That client API may need to pass object constructs that you provide them that have been stripped of internal, secure logic/content. (Remember that compiled C# might as well be clear text with Reflector!)
2) different needs and constraints. For instance, for an internal application call you're going to sometimes enforce different business rules vs. your public facing webservice API (often with the latter being much more constrained to scope).
If you design your business logic into your service layer and invoke those classes/methods well from your web project and your webservice project respectively you're going to have a lot of code reuse anyway without trying to overcomplicate things by mixing use cases.
One method. Otherwise when you find a bug and fix it in one, then forget to in the other... you will cry.
One method, in the web service, and have your web application call it.
I don't understand what "one main method" for both means. Web applications don't have a main method; they're deployed to an app server.
One other point to note: you should write your service in terms of a POCO interface. Once you do that, deployment becomes a choice you make.
It depends..
Normally, I would separate them. This way you remove interdependency between two high level processes. code reuse is good within a process but sometimes you want to be able to use a different app on the same service.
If the two are highly dependant on each other, however, you will want to reuse the same functions so that changing it in one place will change it in another. Thus avoiding more potential issues with the development process.