Initial draft of AppLocal Deployment spec. #1202
Conversation
ghost
added
the
|
Hey @mikebattista is there an existing issue thread where we can provide feedback? |
Please provide comments in the spec in the PR or here in the PR discussion. I'd prefer comments in the spec. |
|
Will do. @jonwis I'm concerned the community is expecting the documented process to be followed and will miss reviewing this specification. |
|
The linked process is for API design reviews which this is not. Though if filing an issue to "Support AppLocal Deployment of the Windows App SDK" will make it easier to get feedback, then I'm happy to do that. |
|
Some initial feedback: Q: What is the preferred terminology: AppLocal, Self-Contained, In-App? How does Windows App SDK AppLocal relate to .NET Self-Contained deployments? Q: Should we keep the msbuild property separate or piggyback on the existing .NET Self-Contained property? If developers want to take a framework package dependency on .NET but an AppLocal dependency on the Windows App SDK or vice versa, we should keep these separate. Q: Are the requirements to redist and install the Windows App SDK Main and Singleton MSIX packages a problem for AppLocal scenarios? |
The Main+Singleton packages depend on the Framework package. For Main+Singleton to work Framework must also be installed i.e. you need it all. Applications using WinAppSDK via AppLocal don't (directly) need the MSIX packages If AppLocal requires redist+install the Main+Singleton MSIX packages then ditto the Framework package. Does that change the AppLocal equation? |
Agreed on only using Self-Contained if it meets the same definition as .NET. I don't think it does currently given the state of the MSIX packages that need to be redist. AppLocal has precedent, too, I know from CRT at least, but I'm not attached to any option.
My feeling too is that these should be kept separate.
I share the concerns here. One of the fundamental questions of this review is if the current design of those packages and the dependencies that Windows App SDK components are taking on them means that we can't truly support AppLocal/Self-Contained/In-App deployment unless we revisit those designs. |
In no order, I'd go with perhaps self-contained, xcopy, or portable.
It shouldn't, in any way. Not all consumers of the WAS are participants of the .NET ecosystem (e.g. C++, Rust). And I don't see any connections.
Separate, again for folks not using .NET. And all of this should work without msbuild (e.g. Rust).
Problem? No. Undermines the point of an xcopy deployment? Probably. 😆 But hey it's better than nothing so please don't scrap anything. |
|
Q: What is the preferred terminology: AppLocal, Self-Contained, In-App? Q: Should we keep the msbuild property separate or piggyback on the existing .NET Self-Contained property? Q: Are the requirements to redist and install the Windows App SDK Main and Singleton MSIX packages a problem for AppLocal scenarios? |
|
I would avoid SelfContained, precisely because it also applies to the .NET deployment option. What happens if/when we introduce a .NET runtime framework package, and .NET SelfContained becomes an option (vs framework-dependent)? How will we disambiguate SelfContained-WindowsAppSDK from SelfContained-DotNet apps? I would assume devs would want to mix and match these options. So this seems like a recipe for confusion - I'd stick with AppLocal. I assume "multiple instances" means "multiple versions". Doesn't FrameworkPackage deployment also imply that multiple versions of binaries can be running simultaneously? There are parallel discussions on how to address other shared dependencies, like the .NET 5 runtime, the C Runtime, and C#/WinRT projection assemblies. As with "self-contained", these may overlap with the term "component binaries", so I'd just call these out as Windows App SDK binaries. Can we define some of the new terminology, like WARMain? We should also not use the abbreviation WAR, as we no longer use the term WindowsAppRuntime/WinAppRuntime. The MSIXPackages spec needs to be updated. |
|
Thanks for the feedback so far. There's general agreement that this should be a separate property.
With the MSIX redists, I don't think we can say it's the same. More discussion to be had there though.
Understood. We know traditionally AppLocal/Self-Contained/xcopy deployment is flat files in a directory that don't require any installation. The App SDK depends on these Main + Singleton + Framework Packages, though, which we need to rationalize.
So you still see value even with the need to redist these packages? Does everyone feel the same way?
The intent of the section is to provide design guidelines for App SDK features to make sure their designs work in all environments. This specific point was about apps carrying/loading copies of the same version potentially vs. a shared instance in a Framework Package. If there's no real difference there for someone implementing a feature, then we can probably remove this.
|
That is the correct term. The project is WindowsAppSDK but the runtime artifacts are WindowsAppRuntime. That includes the MSIX package identities and the DLLs (e.g. Microsoft.WindowsAppRuntime.dll). We haven't (fully) renamed these yet; currently WindowsAppSDK (I'm working on it).
Like this? ;-) We generally don't use the WAR... terms, except when we're repeatedly referencing multiple MSIX packages (where using the full names would degrade comprehension). specs/Deployment/MSIXPackageVersioning.md is the only place I'm aware of that we do. And occasionally in informal conversation, for same reason. WinAppSDK Framework is a mouthful, plus "WinAppSDK Main" can get confusing as WinAppSDK Main, WinAppSDK Singleton and WinAppSDK DDLM are all MSIX main packages (as in, PackageType=Main). WARmain is just the modern lingo for what used to be informally referred to as PRmain (ditto PRfwk->WARfwk and PRddlm->WARddlm). P.S. I did find a few references to the PR... terms across the codebase when I did the mass ProjectReunion->WindowsAppSDK rename. Tried to not just rename but also use the formal terms e.g. PRfwk -> Windows App SDK Framework, or WinAppSDK Framework. |
Yes. Let's say (hypothetical example) Outlook uses the Foo framework package. I have Outlook running 24x7x365 on my machine, so it's running with foo v1.0.0.0. While it's running I install Foo framework v1.0.0.1. We install, say, Calculator and Foo v1.0.0.1. We add v1.0.0.1 to the machine but don't disturb Outlook, who continues running using v1.0.0.0. I now launch Calculator and it's merrily running using Foo v1.0.0.1...while the Outlook process is running using v1.0.0.1. Someday when Outlook quits we'll update the resolved dependency to the newer Foo framework so next time Outlook runs it'll use v1.0.0.1. So yes, framework packages support concurrent usage. Newer versions aren't immediately applied to everything, just everything non-disruptive and we coalesce to the newer version over time. Framework packages are very handy, hence the reason we aspire to do as much as possible via framework packages. Alas, Framework packages can't do everything. Framework package's Inproc code / DLLs, data files and more work quite well via framework packages. It's usually the exe / process / out-of-process stuff that you start bumping into framework package restrictions. That's why specs/Deployment/MSIXPackages.md has comments like
MSIXPackages.md goes into this subject in more detail. |
|
To complement @DrusTheAxe explanation, a main package is required to lift system services out of the OS and into store updatable packages so the WinAppSDK can rev more quickly than the OS. The spec mentions PushNotifications as an example of such a singleton. In v1.0 we have a chicken and egg challenge of getting these new main packages onto devices, and are working to solve that problem - easier done in newer versions of Windows, more challenging to get it downlevel. Until then, that means the only way to guarantee an app has all its dependencies, is for the app to register the main packages. In this scenario the application is running against an applocal copy of the framework, and thus the framework version it uses is not impacted by store updates to the shared framework. The main packages themselves will require the shared framework to be installed. Do you feel this puts too much of a burden on xcopy/applocal deployments? Or do you think apps will avoid using such features so they can avoid registering the main packages (which would be an unsupported scenario)? |
Hm? I'm not aware of a difference between installs originating from the app vs. the user executing the runtimes installer. Why would these packages, once installed, be unservicable? Or are you referring to some sort of unsupported xcopy-everything deployment? |
In addition to this, would there be a difference between per-user vs. per-machine installations as far as package registration is concerned? Multiple users per machine is not uncommon for my customers, but they only want to install once. |
In context of an app choosing to use applocal - the main and the shared framework packages would be serviceable by the store. regardless of installation mechanism (app registers the msix packages directly or the app/user runs the runtimes installer). The applocal copy of the framework would not be serviced by the store, that would require the app to ship an update. |
I wasn't aware this even worked. You're saying I can stuff all the files from those WAS packages into my app and xcopy deploy the resultant folder to another machine? And the app will actually launch? |
That's what this spec is proposing. I may be getting into implementation details here, but imagine:
|
This unpackaged applocal scenario would be what my larger enterprise users would want. They are already familiar with installing our apps published as .NET self-contained and really do xcopy them to multiple PCs after testing them instead of using our installer as I understand it. |
|
@AdamBraden what's the latest on this? |
@nickrandolph - we are aligning with the .NET term 'self-contained' , and we’ll behave the same way with all dependencies carried with the app to support xcopy deployments. However there will be a small set of features that depend on a singleton. If managing these additional dependencies will compromise your xcopy deployments, then we recommend leveraging inbox features or lighting up the functionality at runtime when the dependencies are already available. For example, push notifications will be one of the features that requires a singleton, since push notifications depends on having a single socket connection shared across all apps in order to improve battery and perf… otherwise, there would be no point in us shipping push notifications if each app carried WNS themselves and had their own socket connection always running to WNS server. They might as well have their own socket connection to their own server at that point (what apps do today). This is a point in time as we are on the journey for the Windows App SDK, and we are working to minimize scenarios when these dependencies are not available, but it may take a little while for us to get there especially on downlevel machines. |
Isn't it more accurate to say that there is no xcopy deployment? That both packaged and unpackaged apps require the runtimes installed? You can't pick and choose with WAS at a granularity that suddenly makes xcopy work, so it doesn't really make sense to communicate that way. |
|
WAS is just a decoupled component framework from windows which needs to be installed separately (because it's decoupled.) the point of WAS is that (i)it can be developed independently without changing windows and (ii)support for some downlevel versions going 1809. that's all I understand. IIUC, there were no such promise of XCOPY deployment to begin with. #660 (comment). Unpackaged means that one uses anything other than MSIX |
Correct - "unpackaged app" isn't synonymous with XCOPY-install, it just means "app not installed via MSIX". XCOPY-install, 'self-contained', etc are a subset of 'unpackaged app' solutions. This spec outlined thinking regarding 'app local' and the discussion is helping vet and refine that thinking. As 'oft said, community feedback is valued to help us better understand needs and desires, how we are/not best meeting those and helps us chart a path forward that balances the various requirements and constraints. Where the conversation started is less important than where it goes, so thank you (and everyone else, on this thread and elsewhere) for participating in the discussion. It's a really huge and varied ecosystem so the more voices and viewpoints shared the stronger our solutions can be :-) |
|
Supporting xcopy deployment is a primary goal here. Self-contained and xcopy deployment go hand in hand. Notifications is one feature that requires some additional dependencies, and we'd recommend either avoiding features like that if they would compromise your self-contained/xcopy deployments, or light up the functionality only if the runtime is already available. We don't expect features requiring these additional dependencies to be the common case, and we actively discourage the approach unless the features wouldn't be meaningful without it.
Are you referring to the fact that the App SDK is basically one umbrella reference vs. a la carte references to specific features? Our goal is that if you don't use a feature that requires the additional runtime dependencies, then you don't need to worry about those dependencies, regardless of your references, and we would document which features require those additional dependencies. That list should be small. |
|
the roadmap lists LITERALLY every single WAS features to be made available for non-MSIX apps ! make the only |
bpulliam
added
documentation
|
Closing out as this feature has shipped and is publicly documented at https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/deploy-overview. |
A few topics in need of feedback:
We plan to deliver a preview of this in an upcoming 1.0 Preview release.