Forum Discussion
MSIX .wapproj service
Thank you very much for taking the time.
Unfortunately I won't be able to follow-up with the file until monday, but I'll describe it for you in the meantime:
In a VisualStudio solution containing two projects: One being the .wapproj, the other being the service, and with the wapproj having a project reference to the service, this is what works as expected:
The appxmanifest can contain placeholders inside a declared Application element.
This then directly uses the output of the referenced project's build, without a need to explicitly copy the bin files over to a folder inside the wapproj. Put simply: The tooling manages the linking, without a need for custom build steps. There is no danger of using outdated files, or breaking the build by refactoring something.
Here is where my naive assumptions deviate for reality:
Inside an appxmanifest, an Application element can contain a windows service as an extension. (Application element>Extensions element>Extension element with Category="windows.service").
That extension expects, just like the application element containing it, an Executable and an Entrypoint property linking to an executable file.
If that executable file mentioned in those properties is found within the wapproj's files then the msix package builds and the application and service install as expected.
However, using the same placeholders (eg. $targetnametoken$) inside the Extension elements properties will *not* link the build output to the bundled service, and instead error with a message along the lines of 'file with name $targetnametoken$ not found in project'.
Is there an intended way to link build outputs to bundled services?
If not, is there possibly a .targets file I could take inspiration from?
Again, I'll follow-up with the appxmanifest file on monday. I wish you a great weekend.
Cheers, Ben.
In all likelihood your service wants to start under the SystemServices logon account. In that case, there are two capabilities that must be added to the manifest:
<rescap:Capability Name="localSystemServices"/>
<rescap:Capability Name="packagedServices"/>
Depending on the scenario, you could also consider rewriting the service as "out of process COM" instead of a service.
- Services are available for interaction to software outside of the MSIX container, and have system privileges to perform actions on behalf of the user without UAC prompts.
- Out-of-Process COM supports calls from inside the package that can perform system privileges to perform actions on behalf of the user without UAC prompts.
While I wouldn't re-write without a reason, there are some situations in an MSIX package where when the service doesn't cut it, the out of process COM can. Most likely, you just need the second capability for localSystemServices.
I answered in "weekend mode". Had a chance to review what you wrote this morning and that sounds like a Microsoft issue. Perhaps I'll make a test package to verify and see if there is something simple to solve, but might take a while. Perhaps look for a more developer place to ask if in a hurry.
Thank you very much, but the process doesn't need the localSystem role at this time. If it needs it, I will add it.
The issue I was observing is that the project fails to pack altogether, if the placeholder is used as the value for the Executable property for the service.