Accelerate Xcopy deployment availability

[michaelongithub]

Proposal: Urgent for starting in house apps. Killer condition

Summary

Is still not available in Reunion 0.5. MSIX and the necessary cert handling is a no go for our need for apps in company desktop apps on PC's with monitor.

Rationale

We dont want our SW engineers or server / pc staff to burdend with unwanted and unnecessary cert installs on target machines. We will only start WINUI development if Xcopy deployment is availabel

-->	Capability	Priority
This proposal will allow developers to accomplish staritng much needed WINUI development unburdend on MSIX / cert knowhow and management. Not ready to train our staff (costs, availability) with this for us not needed knowledge	Must

Thanks for considering and changing Your priorities

[andrewleader]

Hey @DrusTheAxe, we think dynamic dependencies will resolve this concern - can you follow up with Michael on this thread to verify if that'll work?

[driver1998]

Technically you should be able to do that now (at least on 18362+), Windows Terminal can be run if you extract the msix package and double click WindowsTerminal.exe.

Also the built-in magnifier app has been using XAML islands for quite a while, also running unpackaged.

[DrusTheAxe]

MSIX and the necessary cert handling is a no go... Rationale: We dont want our SW engineers or server / pc staff to burdened with unwanted and unnecessary cert installs on target machines.

@michaelongithub Not a problem. Project Reunion's MSIX packages are Windows Store signed. They install without requiring any cert management on your part.

Windows knows about the Windows Store certificates. MSIX packages signed with the Store cert (or a certificate chained to it) installs just fine. It's only if your MSIX is signed with another cert that you'd need to add it to Windows.

You can verify this for yourself by snooping at the package...

[D:]powershell -c get-appxpackage *reunion*

Name              : Microsoft.ProjectReunion.0.5
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
...
PackageFullName   : Microsoft.ProjectReunion.0.5_0.52103.25000.0_x64__8wekyb3d8bbwe
...
SignatureKind     : Store
...

SignatureKind=Store means the package is Store signed.

Does this address your concern?

[riverar]

I suspect the concern here is more about the current packaged app requirements in Reunion 0.5. This will require signing the resulting msix for internal or external use. The current roadmap has unpackaged app support landing (as a preview) in Reunion 0.8 in Q2 2021.

[michaelongithub]

Thanks for the various comments and hints. Basically we want the same options for deployment available as for Winform and WPF. Namely an Xcopy out of the bin folder or something analogous. We have and will have functionallywise "classical" desktops apps, that will be used in the local network only or in the customers local network. And we want to move completely away from Winform to WINUI for the GUI. So all unnecessary packaging, signing whatever is just a burdensome redundant overhead for our needs. I wonder, if this is not a necessity for numerous app use cases ? Even widespread ? Thanks for keeping considering our request.

[orcmid]

So all unnecessary packaging, signing whatever is just a burdensome redundant overhead for our needs. I wonder, if this is not a necessity for numerous app use cases ? Even widespread ?

And non-admin installs?

My security, defense-in-depth hackles just went up. I am not in your customer case, but I worry about the threat model that allowing unsigned code represents. Is there a middle ground here that does not increase the threat surface?

[riverar]

@michaelongithub Yep, you'll want to wait for Project Reunion 0.8 in a few months (unless plans change). It should support this scenario.

[michaelongithub]

Thanks again for the feedback. Of course, even in a local network there are always security concerns. But they can be handled without MSIX for the needs of our use cases. And thanks riverar for info. I just was hoping we would get that right away. Would have made testing and functionality designing with clients easyer. I will also try the suggestion of driver 1998.

[DrusTheAxe]

@riverar Yes, Unpackaged desktop apps sound like the desired solution. Coming in 0.8.

@michaelongithub Project Reunion's runtime is distributed and installed via MSIX packages. We sign them with a Store cert so they can easily install on any PC. However your application can be packaged or not. Project Reunion 0.5 supports Packaged MSIX desktop apps. Project Reunion 0.8 will add support for Unpackaged desktop apps. Sounds like the latter is what interests you.

Unpackaged support is new. Historically, "packaged bits can only be used by packaged apps" due to hard technical reasons (mainly servicing). Unpackaged apps couldn't use packaged content. Project Reunion addresses this via Dynamic Dependencies.

Packaged apps tell Windows they're going to use things in an MSIX by statically declaring a dependency in their appxmanifest.xml. Unpackaged apps tell Windows they're going to use things in an MSIX by calling Dynamic Dependencies APIs. The details differ but the net result is the same -- your app can use packaged bits. The Dynamic Dependencies spec has details on how the magic happens :-)

The [Roadmap](Packaged MSIX desktop apps) has more details on the timeline.

You have multiple options available as you deem best, including...

• Make a Packaged MSIX app
• Make an Unpackaged app
• Make a Sparse Package 1, 2

Sparse packages are an interesting hybrid between Packaged and Unpackaged. This provides you access to functionality previously only available to Packaged apps, but you still have your own content and install.

You provide an appxmanifest.xml as a way to register for certain features with Windows and, at runtime, your unpackaged app runs in a process with package identity. But you still have your own install, with all that implies. In this case your manifest can be signed but your 'content' (your EXEs, data files, etc other than your 'footprint' files e.g. appxmanifest.xml) is...whatever you do without MSIX. Some folks sign their files (code signing, etc) and AAA games put a lot of energy to detect and block tampering (cheats, hacks, etc). MSIX just makes it easy ;-)

Or you can make a sparse package but not sign anything (quite handy for dynamically generated apps). It's sometimes referred to as 'hosted apps', 'hosted app model' or 'dynamically hosted apps, as it relies on a packaged host runtime via a signed MSIX. See 1 and 2 for more info.

Signing has merits but it's not always a great fit for all. While we too love to see secure solutions, it's a big world with a lot of roads traveled. While we encourage robust solutions and strive to help make it easier to accomplish, ultimately you're the one who has to decide what works best for your needs. There are many paths to success.

@orcmid Does this provide options for your desired middle ground?

I understand and sympathize with impatience ;-) We're working to make Project Reunion available as fast as we can. Please keep sharing your questions, concerns and ideas. It may not always be apparent but we very much value all the discussion and feedback.

[nickrandolph]

@DrusTheAxe is there a way for applications to include the reunion dependencies in their application, rather than having to rely on framework packages. I understand the increase in app size but tbh there are a number of scenarios where this makes sense:

• enterprise - installing and managing dependencies that aren't included in the application isn't going to fly
• upgrade risk - whilst I understand the intent of being able to silently service reunion packages without breaking any applications (the goal), the reality is that you're modifying code, so there's a risk that you could break applications without realising. I'd be willing to include the reunion dependencies in my application (packaged or unpackaged) to ensure I have a fixed, known, set of dependencies.

[michaelongithub]

@DrusTheAxe I am sharing the concerns of @nickrandolph . And where went the .net core "Promise" of 1 exe and no more dependencies (pre installed frameworks like with .net framwk. OS parts dependencies like with former UWP). While I am very thankful again for your explanations and hints, this amplifies my wish for an analog to the good old xcopy deployment (and nothing up your sleeve). Or is the MSIX Reunion package dependency only a temporary stopgap ?

[wjk]

@michaelongithub I believe what @DrusTheAxe is trying to say is that you would unpack the MSIX packages containing Reunion’s dependencies during your build and copy the contents into a subfolder of your app’s install directory. You would then use the DDLM APIs (which are just DLLs that can be copied like any other) to access the contents of the packages from their location in the filesystem, without registering them with the OS. Unfortunately, I cannot recommend any technique for accomplishing this. The DDLM API is still rather undocumented and lacks good samples. Hope this helps!

[nickrandolph]

@wjk thanks for providing some insight into how this could work - I don't think the scenario of an unpackaged app that includes all dependencies will be so uncommon that it warrants having to do all these manual steps. I understand that there's trade offs to be made but there should be a mechanism where devs can toggle a property and to simply have all the dependencies emitted to the output directory which can be xcopied (just like a winforms/wpf app today!!!)

[DrusTheAxe]

An area of fertile discussion. Catching up...

@nickrandolph include the reunion dependencies in their application, rather than having to rely on framework packages...upgrade risk

The concern can be summed up as a lack of control over when/if dependencies change?

'In-app deployment' (aka redistributables aka...) is one solution. Obviously your dependency only changes when you rebuild your app to include updated files.

'MaxVersion' is another idea that's been tossed around. MSIX lets you declare <PackageDependency...MinVersion=x> as a floor required to install but no ceiling. One could say MSIX supports MaxVersion="∞". What if you could specify something more bounded? For example...

MinVersion="1.2.3.4" MaxVersion="*"
MinVersion="1.2.3.4" MaxVersion="1.*"
MinVersion="1.2.3.4" MaxVersion="1.2.*"
MinVersion="1.2.3.4" MaxVersion="1.2.3.*"
MinVersion="1.2.3.4" MaxVersion="1.2.3.4"

The 1st line is technically today's behavior, but framework package authors typically put their Major (or even Major.Minor) version into their package family name, effectively doing the 2nd (or 3rd) line. For example, Microsoft.ProjectReuinion.0.5 is effectively a MaxVersion="0.5.*". What if you could specify this down to the 3rd field? The 4th? Would this address the concern?

@nickrandolph enterprise - installing and managing dependencies that aren't included in the application isn't going to fly

Could you elaborate? (It's not the 1st I've heard the concern, but I've rarely heard the reason(s) driving it. I'd prefer to know rather than guess :-)

@michaelongithub And where went the .net core "Promise" of 1 exe and no more dependencies

Can you point to where this "Promise" was made? I'm not as familiar with this statement (intention? expectation?)

Are you referring to a "self-contained executable" via .NET Core's dotnet publish command?

@michaelongithub is the MSIX Reunion package dependency only a temporary stopgap?

Not at all. MSIX packages are a key technology to accomplish Project Reunion. We're having an interesting discussion about the tradeoffs and value of an 'in-app deployment' option, but I'd expect if anything that would be in-addition-to MSIX packages (not instead of). Many feel MSIX packages can (and do) fit their needs so replacing that with a redistributable model would be unwelcome. On a similar note, .NET Core doesn't only support self-contained executables.

@wjkI believe what @DrusTheAxe is trying to say is that you would unpack the MSIX packages

There's a few misunderstandings here:

• the DDLM is an implementation detail, to make Dynamic Dependencies (DynDep) work; there is no DDLM API
• DynDep has an API but it's purpose in life is to make Framework packages accessible to unpackaged apps. If you tear open MSIX Framework packages and copy their files to collocate with your app then you have no Framework packages would you access, i.e. DynDep is moot for your app
• I'm not advocating in-app deployment. I'm inquiring about the need(s) that are driving the ask, and what are the options and tradeoffs to satisfy them.
• "The DDLM API is still rather undocumented and lacks good samples" - The DDLM has no API and is not meant to be used directly; see comment above. Do you mean the Dynamic Dependencies API?

@nickrandolph there should be a mechanism where devs can toggle a property and to simply have all the dependencies emitted to the output directory which can be xcopied

Some dependencies could possibly be satisfied that way, but only some. Designs under discussion and in progress require more expansive machinery, possibly via MSIX packages and not so easily via XCOPY/DoItYourself.

[wjk]

@DrusTheAxe My apologies. When I said DDLM I did indeed mean the Dynamic Dependencies API (I thought from some of your earlier comments that they were identical). And my statement that you would need to break open the MSIX package before deployment was a wild guess based on little data.

[orcmid]

Some dependencies could possibly be satisfied that way, but only some. Designs under discussion and in progress require more expansive machinery, possibly via MSIX packages and not so easily via XCOPY/DoItYourself.

My first thought was that redistributables, (anyones redistributables) might be a stumble here. I have not followed the fate of SxS so must keep my mouth shut about that.

I still have security heeby-jeebies about this request, and am not informed enough to provide anything more coherent than that. I'm cringing that executables are stashed in AppData (Keybase!) and locking against that kills Win10 feature-update installs.

[nickrandolph]

@DrusTheAxe for me the basic failing here is that there seems to be a disconnect in understanding the importance of unpackaged apps being exactly that "unpackaged" (aka xcopy, no external dependencies other than what's being copied). The reason for this is it gives the developer complete control as to how they package and distribute their app. It also means that they know exactly what's being deployed without any risk that the deployment will fail because pieces were missing (eg framework package that needs to be downloaded but they're offline). This is one of the reasons that .NET Core is so much better than .NET FX - the ability to deploy everything that makes up your application is just such a relief. For me, I don't get why all the effort is being put into unpackaged apps, if they're going to be stuck with a framework package dependency. Any fancy min/max versioning is all well and nice but that doesn't address the issue that I don't want, or trust, a third party (in this case Microsoft) to version any part of my application.

[DrusTheAxe]

@orcmid I still have security heeby-jeebies about this request

Fret not. You're in good company ;-) The tradeoffs of isolation vs sharing are well known by many (often painfully so...) and is a regular area of discussion. The trick is finding the right mix of solutions offering security, reliability and flexibility to satisfy such a broadly divergent ecosystem. Easier said than done (as this thread illustrates :P)

@nickrandolph "unpackaged"

Small clarification: In Project Reunion when the term "unpackaged" is used it means an application that is not MSIX deployed. It doesn't mean the app makes no use MSIX packaged components.

"In-app deployment" is the common phrase used when talking about an application using components collocated with the app (i.e. not via any MSIX framework package).

What you're advocating for is components are installed via the "in-app deployment" model (aka 'redistributables'). Whether or not your app is itself installed via an MSIX package or not isn't significant, what matters is your app is only dependent on components - code, data, files - that's collocated with your app, and the exact selection of that code/data is entirely and exactly controlled by the developer. About sum it up?

without any risk that the deployment will fail because pieces were missing (eg framework package that needs to be downloaded but they're offline).

That won't be a concern. If you're an unpackaged app it's generally expected your installer will include Project Reunion's runtime which you install if necessary, when your app installs. This is pretty mundane for apps with an installer, whether it's .msix you install via PackageManager.AddPackageAsync() or a ProjectReunionInstaller.exe you install via CreateProcess("ProjectReunionInstaller.exe"). That currently includes the .msix so no network connection is needed to install.¹

For XCOPY-install apps where there is no 'installer', just an executable that's self-contained and always ready-to-run, that's still an option (dotnet publish provides a similar experience). In-app deployment is another possible solution.

¹ A webinstaller variant could be made available, as a tiny exe that gets the *.msix to install via a network connection. This interests folks as the installer grows, and when a network connection isn't a concern. It wouldn't surprise me if we eventually have both, as they complement nicely to meet the collective needs.

@nickrandolph I don't want, or trust, a third party (in this case Microsoft) to version any part of my application

Your application already depends on components you don't control, called 'Windows'. A user can upgrade their system to a new release of Windows. Service packs can update versions of underlying components your app relies on. These are things your application has no direct control over; it's in users' and admins' hands. Unless your application is delivered via a wholly shrink wrapped environment (e.g. Docker) there are limits to what an app controls.

Your point is, you want to maximize your control over your app's composition. Right?

As mentioned, there's tradeoffs. It's helpful to understand not just the desires for black or white, but also the greys in between. Even dotnet publish has multiple options with varying pros and cons. These offer varying degrees of 'in-app deployment' and control. Do you have thoughts on these options?

[mikebattista]

Self-contained/xcopy deployment is targeting the 1.1 release.

You can see some experimental samples staged at https://github.com/microsoft/WindowsAppSDK-Samples/tree/mikebattista/selfcontained/Samples/SelfContainedDeployment.

Self-contained deployment will be configured by setting <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained> in your exe project file. For an unpackaged app, you should then be able to xcopy deploy the build output. Packaged apps would still need to be registered themselves but would carry the Windows App SDK dependencies inside the package.

[riverar]

@mikebattista Wow, that's sooner than I expected. Thanks for the heads up.

[mikebattista]

1.1-preview1 just shipped with the first preview of self-contained deployment. You can find the accompanying docs at https://docs.microsoft.com/windows/apps/package-and-deploy/deploy-overview?branch=main.

See https://docs.microsoft.com/windows/apps/windows-app-sdk/preview-channel?branch=main#self-contained-deployment for some known issues with Preview 1.

If you have a chance to try it out, we'd appreciate the feedback!

[mikebattista]

This support shipped with WinAppSDK 1.1.

See https://docs.microsoft.com/windows/apps/package-and-deploy/self-contained-deploy/deploy-self-contained-apps.