I have created 2 WCF service libraries in a solution. I have also created two windows services which will host the two wcf services.
these wcf services communicate with eachother. one gets requests and is reusable service for other systems, the other service sends requests to this service and takes requests from the UI.
I have created installers for the window services too.
I want to understand the build script tasks which I need to include which I will call during each time I want to deploy this solution to the server?
Should I delete all of the windows services and install again with new DLLs?
What is the best way
There is no need to delete the windows services. You can stop the service, replace the service executable and all the assemblies used by your service and restart the service. This is what I've always done, and I've never run into problems.
Related
We are working on a MVC Core project which requires to be hostable either on Azure, either on IIS (on premise), depending of the final customer wills.
Our minimal support level is Windows Server 2012.
Along this project, we need to have a background process that will schedule some specific treatments.
In on premise context, a regular windows service would perfectly fit. But it can't be deployed easily in Azure, apart in a VM as described https://stackoverflow.com/a/36026658/461444
So we would like instead to know if there is a simple solution that can be exploited both as a Windows Service (or something very close), and as an Azure component in a single implementation.
I would create three projects:
A class library that does all of the logic you need. Because it's just a class library, it can then be included in any other project
A Windows Service that does nothing but call the class library from #1
An Azure Function that does nothing but call the class library from #1
The Windows Service can easily be deployed on an on-prem IIS server.
The Azure Function can easily be deployed into Azure without the need for an Azure VM.
(Side note: the thread you pointed to is three years old. I don't know if Azure Functions existed at the time.)
How about using the background service feature of ASP.NET Core?
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/host/hosted-services?view=aspnetcore-2.2&tabs=visual-studio
https://learn.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/background-tasks-with-ihostedservice
If you configure your website to keep running (Azure App Service: "Always On") your workload should work just fine. Just be aware of how many instances the AppService runs on and if you need to coordinate the instances. When in doubt, you can always just create two ASP.NET Applications, where one is just responsible for handling the background work. This way you can control the scaling and lifetime of each service independently.
Asp.NET Core 2.1 HostedService - keep running on Azure
Our project need a new component. 1. It need to communicate with non-WCF components. I would like to host WCF service in IIS + WAS, which is more stable than self-hosted WCF service. 2. Meanwhile, there are many work loads as well as queuing/cache needed for the new component, I want it works as a long-running window service. To be a summary, can we have an IIS hosted WCF service as a part of a window service? Would you please note that I don't want to compare hosting via IIS vs windows service. Thanks.
I'm currently in the middle of a large ASP.NET application with many WCF services. Currently in IIS, all these services are listed under one application called Services.
I'm concerned that with more being added to our servers all the time and the uptake of our application increases, this is probably not the best way to manage things. Currently the VS project has a "web service host web application", which contains all the .svc files to be hosted. The advantage of having it all in one is the obvious use of the web.config for all services. The disadvantage is that if we need to do an update or deal with a critical issue, all our services are brought down at once, rather than those few that we know the problem is located.
I'm wondering if it is possible to keep this "host web application", but split the application into different "sub-applications" using separate Application Pools and allow VS to publish to individual services. I don't know if splitting it into folders under the "host web application" and hosting these as individual applications will work.
Or is the only way to have lots of host applications to run in separate application pools?
TL;DR; Should I split our application with all services into 5-6 applications with a few services?
I have a C# application that needs to always be running. I originally planned on making this a windows service but I now have a requirement to make the application host a web admin console.
I haven't played with IIS in quite a few years so my question is this:
What would you recommend I use?
I've thought about making a windows service and embedding a web server such as Cassini but so far I'm not very happy with the open source web servers I've looked at.
Can IIS handle this? Do people use it for this type of scenario, and if so how?
This sounds like a job for two separate projects.
One is the original Windows Service. Windows Services are well suited for what you're doing.
The second is the Web Project that will be used to administer the Windows Service. This is the part that runs in IIS.
It depends on what you mean by always running. An ASP.NET web application deployed in IIS could very well be unloaded by the web server if there aren't any requests for certain amount of time killing all background threads. So if you want an ever running background thread it would be better suited to use a Windows Service. As far as the web admin is concerned, well, here you don't have much choice: ASP.NET in IIS. In order to do something useful those two applications should be able to find a common language to talk. So you could use a database to store the results into which could be used by both applications.
IIS will run your app on first request, not on server boot. So you will still need to run a service to ensure your app is always running.
You can use IIS as a webserver for your web admin part, and link your ASP.net app with your service by means of a configuration database (easy) or webservices (a little more tricky).
Windows and Web services are two very different creatures. A web service will expose external methods that you can implement against an application, while a windows service is an entity within itself. If you're planning on using this service on a timed interval to perform an operation, a Windows service would be the right way to go. If you use a web service, you will need to invoke the method you wish to run from a secondary application.
If you need to queue commands against your windows service, you could always create a database that was accessible by both your website and your windows service. This way you could send commands and query data between the two. Placing a web service in to serve as an intermidary between the two may be overkill.
I now have a scenario where I have 6 console apps on my server which each host a WCF service.
It's getting messy and I am now thinking about having a windows app (probably WPF) which hosts each service in a separate thread. This would mean there's a central place to manage the services as well.
I'm just wondering if anyone has implemented such an app or any advice before going forward?
I work on a system that has ~8 windows services, all hosting 1 WCF service each. To easily coordinate the execution of the services, we created a service coordinator application that when started, will start the other 8 services. This makes starting, stopping, and restarting the services really easily... and because they're windows services and not console applications, there's no desktop space lost.
The projects themselves are actually compiled as console applications, so that we can work on them easily during development (and also run them with a /debug argument to test them after they've been deployed). Maybe something like that will work for you.
...which hosts each service in a separate thread...
why? By default the WCF runtime is doing the threading for you. MSDN has a god starting point on this or have a look at Programming WCF Services by Juval.
To host multiple services in one thread you could check out this multi-service-host (using AppDomains for separation). I've done a very similar host before reading this and it is now hosting >100 services (started with 30 something) for thousands of users in a single operating system service.