Standalone Windows Services

[devdelimited]

Now that Windows Services are supported, can someone provide some information on exactly how to set up an MSIX package for a standalone traditional Windows Service?

I know Microsoft wants us to rewrite everything using .NET Core Background Workers. However, for our existing code base, that is going to take more time & resources than we have at the moment.

As a first step, I have added a Windows Application Packaging Project to my solution (which has only class libraries and a console application / windows service project but no front end WPF, etc.).

As a last step, I've added a "MSIX build and package" step to DevOps.

Unfortunately, I can find no guidance on how to get from the first to the last step for Windows Services. I need to know if...

1. the Windows Application Packaging Project is the correct first step
2. if so, how to add the Windows Service to it
3. where & how do I set specific Windows Service-related settings, e.g. Start Automatically, Run-as account, etc.

Bonus question: When will Windows Services support be added to Windows Server?

[#2]

Most likely the Windows Application Packaging Project doesn't include dedicated GUI for adding Win32 services into an MSIX package, this is a relatively new feature for MSIX packages.

You can probably manually tweak the AppXManifest to add the service declarations in the package.

This article has more details about how services work inside an MSIX packages, what declarations you need to add in the package manifest and additional details.

https://www.advancedinstaller.com/msix-windows-services.html

[#3]

I appreciate your reply, Bogdan. However, I'm really looking for Microsoft to improve the documentation and support for services. Years ago, they had taken Setup projects away from us, sprouting a third party takeover. Now, they are clawing it back, in a way, with MSIX. However, it would appear they still have some work to do to fully support server applications - e.g. Microsoft Server and Windows Services support. What they need to realize is that so many development teams refuse to pay thousands of dollars on packaging. As a result, the server-based products they push out to clients bring an amateur look & feel when they're ugly ZIPs with SC.exe steps, etc.

For others finding this thread, after much searching, I found the official documentation for the manifest.

https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop6-service

HOWEVER, this still appears to apply to a service that is tied to and required by a UWP GUI application.

[#4]

1-You can create a package with a service and no actual application, although the WAP isn't going to make that easy.
2-As the service would be pushed out just like a traditional setup, perhaps you shouldn't be "pushing on the rope" to use this as a way to push out and stick with what works. At least for now.

[#5]

While I do enjoy your use of the phrase "pushing on the rope" - development does feel like that quite often - this doesn't really provide much in the way of how to actually get it done.

With regards to the old Setup way, sadly the Visual Studio no longer supports that and the "hacky" reverse integration of the old Setup project types doesn't work with the latest frameworks. I think Microsoft recognizes this; however, they have quite a bit of work ahead of them.

If I'm reading the tea leaves correctly, Windows Server 2022 is likely the going to be first version to fully support MSIX, and it looks like Windows Services in general will have more complete support by then (along with a bunch of other missing features).

Again, I appreciate your help though.