Provide MSIX package (for side-loading)

[Styxxy]

Is it possible to create a MSIX package so we could side-load the app?

Maybe additional publishing channels?

• Windows Store
• Chocolatey
• AppGet (https://appget.net/)
• ...

[christophwille]

Can you elaborate why you would need that? (it doesn't get more side-loadable than the current zip file)

[Styxxy]

@christophwille
This would make centralized distribution a lot easier (with SCCM). MSIX can also be published to the MS Store (though in my case this is blocked, so side-loading the MSIX would be for me the "needed" case).

For some users it might also be handy that it is published to for example chocolatery. Multiple distribution options (which are also free) could be great.

[christophwille]

ok, centralized distribution of ILSpy is somewhat a first when it comes to feature requests.

I am not sure that MSIX would work nicely with ILSpy in one specific regard: addins are supposed to be copied into the directory where ilspy.exe lives.

[Styxxy]

ok, centralized distribution of ILSpy is somewhat a first when it comes to feature requests.

Yeah, mainly centralized distribution is the main "feature request". MSIX is a nice way of packaging, though specific for Win10.

I am not sure that MSIX would work nicely with ILSpy in one specific regard: addins are supposed to be copied into the directory where ilspy.exe lives.

The deployed package is "read-only". Anything user specific has to come from eg %appdata% (user profile). So probably this feature is "disabled" for msix packages or the loading of extensions needs to be enhanced :).

[christophwille]

https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-prepare

Technically, that might actually work now because in v5 we are targetting net462 (and have removed a few multi-targetting hacks). However, according to https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-packaging-dot-net that would mean adding a project that depends on the Windows 10 SDK (just verified because my machine's VS doesn't have UWP development tools installed, the packaging project template is missing). That, however, might not fly with the team.

[Styxxy]

You don't need the UWP development tools per se for developing the app. It is just for packaging (and in some cases you would like to debug it). You could also opt for manually packaging (https://docs.microsoft.com/en-gb/windows/uwp/packaging/manual-packaging-root?context=/windows/msix/render).

[clairernovotny]

I'm happy to do the work and submit a PR to add an MSIX and maintain a Store CI/CD pipeline. As I've done this for NuGet Package Explorer, I've noticed that it's become the de-facto installation mechanism (10:1 ratio) over all others. It's because it keeps people always up-to-date, which is great.

[Styxxy]

@onovotny Only the plugin architecture would be kinda broken (a plugin is required to be next the exe = installation folder). But maybe it should be a seperate issue/pr.

And also they would need the uwp workload if the msix project file is used (which is still under discussion I think).

[clairernovotny]

As far as workloads, it's true the UWP workload is required for the Packaging Project, but IMO, that shouldn't be a huge deal.

I'm also happy to create/setup/maintain an Azure Pipeline for this and the Microsoft Store account to publish it to.

As far as plugins go, I'd suggest that be a different issue. It could do what NPE does, which is to have an "Add Plugin" dialog that points to the dll/zip that has it. ILSpy could then copy it to a local folder location that's accessible to it).

[MatthewSteeples]

Another alternative (how Paint.NET does it) is to have a "well known" folder that users can put plugins in and the app checks there on startup

If there's anything you need a hand with setting up, I've got experience getting Azure Pipelines publishing to the store too

[christophwille]

An option might be to separate the MSIX build into a separate solution file (we had frontends.sln initially for xplat development with "everything" minus the WPF/VSIX bits) so it doesn't get into the way when you don't have the UWP workload installed (I'd wager that none of the devs including me has UWP installed, and nobody of us uses the Store)

[clairernovotny]

It's easy enough to have a separate solution that has the packaging project in it. As mentioned, I'm happy to be a permanent maintainer of a Store release and handle releases there.

Depending on what you want, I can do either "just" stable releases to the Store, or do something similar to what I do with NPE, which is to have a Store channel and a CI channel that's published to a blob and auto-updates. I've found that makes it really easy for people who always want the latest to keep up.

[christophwille]

re:channels - today we have releases (stable & pre-releases on GH) as well as CI builds. The latter are consumed, but only by a few people (as far as we can tell, might be more with an auto-update-mechanism). So if it is not too much of an hassle, a CI channel might be interesting.

Now a word on our versioning (during build; it might look odd): our system dates back to SharpDevelop where it originates from. That's why we have a \BuildTools folder. We pre-date SDK-style projects (which we use now), and for simplicity's sake stuck to the automation we already had in place. The appveyor.yaml file in the root should give you a good idea about the order of build scripts. (but basically it is .\BuildTools\appveyor-install.ps1, then restore+build+zip)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.