.net Framework For Windows 7 64 Bit Service Pack 1

[Totaly Pavlina]

UsingVisual Studio or the .NET Framework SDK, you can easily create services by creating an application that is installed as a service. This type of application is called a Windows service. With framework features, you can create services, install them, and start, stop, and otherwise control their behavior.

Having being unsuccessful to find a decent resource I am finally asking it over here. I have a legacy .Net Frmework Windows Service (which is now migrated to .Net Framework 4.7.2) which I want to eventually migrate to Azure PaaS. After looking around I found 3 ways I could do that and not counting the options like hiding it behind a web app hosted in IIS because I do not think that is the correct solution. I think the correct ways are:

3) Use Containers: This seems to be the solution most suitable but I want some expert to guide me through it as I am completely new to docker and azure. Since the service is in .Net Framework, the target OS could only be Windows Server Core( -us/dotnet/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/deploy-existing-net-apps-as-windows-containers) but when I pull the image I get the message that it "cannot be used on this platform". I am using Windows 10. Does this mean that I need to be working on Windows server family OS to be able to pull image which effectively means that to be able to deploy .Net Framework application in an Azure container, I need to be working on Windows Server OS.

Links to a few good reads or videos are welcome as I am unable to find may be because I am not searching it correctly. I would imagine that windows service migration to Azure is a common scenario but I may be wrong.

I have a windows service I build with .net core and I can publish it with a publish profile and since Im using appsettings I can target the environment as well. Trying to figure out a solution for another project but its using .net framework and do not want to use installutil. So far I can just

- stop the service

- copy over the files

- restart the service

So now I am looking at doing this with powershell, and hopefully add this to a build pipeline to have it automated. The steps would be the same that the powershell script would do

- stop the service on the target server

- copy over the files from the /bin folder

- restart the service on the target server

except after copying over the files, I would need to modify the app.config, and all of the above Im sure I can accomplish with powershell.

You can use this task to execute PowerShell scripts on remote machines. This task uses Windows Remote Management (WinRM) to access on-premises physical computers or virtual computers that are domain-joined or workgroup-joined. For PowerShell scripts, the computers must have PowerShell 2.0 or higher installed.

Creating Windows Services using the standard Windows Service Template in Visual Studio is simple enough, you don't really need any special framework. However, in VS Express you may not have the winservice template and then Topshelf makes it quite easy using the Windows -> Console Application project template.

You're probably pretty much on your own here, but it's easy enough to accomplish with timer(s) and simple configuration in your App.config. Or, if you want to be fancy, using dependency injection or a plugin mechanism, maybe using MEF.

(Having used Windows Workflow Foundation (WF), I'm not convinced at all by the WF-related answers to this question. I would appreciate if anyone is able to provide references to reputable sample apps that show how WF could possibly address any of these requirements in the original question.)

If it is a scheduler kind of thing that you are looking for, then you may want to look at Quartz.net. This is an open source job scheduling system. It would be easier to use an existing tool rather than rewriting one from scratch (unless it is for academic purposes).

I'm trying to build a Windows Service in .Net Core 2.0 but I've been banging my head on the wall for a full day and no progress at all.Everything seems to be using Core 1.0/1.1 even the Microsoft documentation:

I've seen some weird solutions that put all the code in a .Net Standard Class Library and then use a .Net Framework application to host the Windows Service, but this doesn't look elegant in my eyes and I'm trying to get rid of.Net Framework altogether.

It is now possible to write a Windows Service in .NET Core 2.0 without third-party libraries, thanks to the release of the Windows Compatibility Pack (at the time of writing, still in prerelease). As the page itself warns:

But before you start porting, you should understand what you want to accomplish with the migration. Just porting to .NET Core because it's a new .NET implementation isn't a good enough reason (unless you're a True Fan).

In particular, writing a Windows Service in .NET Core may now be possible, but you will not get cross-platform compatibility out of the box, because the assemblies for platforms other than Windows will just throw a PlatformNotSupportedException if you attempt to use service code. Working around this is possible (using RuntimeInformation.IsOSPlatform, for example), but that's another question altogether.

Also, third-party libraries may still offer a nicer interface with regards to installing the service: as of writing, the current version of the compatibility pack (2.0.0-preview1-26216-02) does not support the System.Configuration.Install namespace, so the default approach with a ServiceProcessInstaller class and installutil will not work. More on that later.

With all that said, let's suppose you have created a brand new Windows service (Service1) from the project template (not strictly required since it contains nothing interesting, other than a class inheriting from ServiceBase). All you need to do to make it build on .NET Core 2.0 is to edit and replace the .csproj with the new format:

This is not ideal in several ways: this hard-codes the path of the message resource file (we should really be determining where it is from the executable and the runtime paths in the registry), and it hard-codes the service name and executable name. You may want to give your project its own installation capabilities by doing some command-line parsing in Program.cs, or use one of the libraries mentioned in Cocowalla's answer.

To host .NET Core 2.0 Web API as Windows Service. I followed this guide Host ASP.NET Core in a Windows Service. The Prerequisites part is unclear to me. After some mistakes, here is what I did: Source Code

I think @JeroenMostert's comment is a bit harsh - I can see the appeal of not being dependant on a particular .NET Framework version being available on the target machines. Plenty others obviously feel the same, as the 2 repos I linked to are rather popular.

In .NET Core 2.1 you are able to use the Host and HostBuilder to get a console applicaiton that runs as a service. If you containerize your console application you can deploy the container anywhere and it is just the same as running as a service. You are able to use the Host and HostBuilder to manage DI, Logging, Graceful shut down, etc in you console app. Have a look at:

Framework-dependent deployment (FDD) relies on the presence of a shared system-wide version of .NET Core on the target system. When the FDD scenario is used with an ASP.NET Core Windows Service app, the SDK produces an executable (*.exe), called a framework-dependent executable.

Add a Windows Runtime Identifier (RID) to the that contains the target framework. In the following example, the RID is set to win7-x64. Add the property set to false. These properties instruct the SDK to generate an executable (.exe) file for Windows.

A web.config file, which is normally produced when publishing an ASP.NET Core app, is unnecessary for a Windows Services app. To disable the creation of the web.config file, add the property set to true.

Maybe this is a complete cop-out, but remember that with greater docker support, you may be able to build out a service that runs within a container. At that point, it would still be .net core (2.0) but running on your windows box. What's more, you could deploy just about anywhere in the future.

I've studied Windows Services and .Net framework.From my research, a windows service is a type of application that is primarily used to run in background and can be done automatically or periodically. And .Net is a software framework developed by Microsoft that runs primarily on Microsoft Windows.

What I would like to know where in the stack of the .Net framework are basically the windows services, supposing windows services use .Net framework.Any further exaplanation on the relation between these two will be a great help.

They are two completely separate notions. They're related in the way that, for example, a hotel janitorial staff might be related to a guest of the hotel. Just because they reside in the same "building" at some point, doesn't mean there is any "useful" (i.e. substantive for the purposes of comparison given the context) relationship between them, though their paths may cross for whatever reason. The same goes for the notion of windows services and the .NET framework.

A service does not have to be written in .NET, anything will do. Two basic things need to happen. First of all, the Service Manager built into Windows needs to know that the service exists. That requires writing a handful of registry keys. Bare essentials are the service name, where the EXE is located and how it should be started. The ServiceInstaller class you write takes care of that, you run InstallUtil.exe to let that installer do its job. Have a look-see with Regedit.exe, navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services key.

And then the program needs to use a winapi function to talk to the service manager. So that the manager can deliver notifications that tell service to start, stop, pause, etc. That's wrapped by the ServiceBase class, you get friendly methods you can override. Like OnStart(), etc.

3a8082e126