Consider a standalone installer for ANCM

[analogrelay]

"Moved" from aspnet/AspNetCoreModule#183 (but I'm too lazy to actually move the issue).

[mockjv]

Sorry, forgot to watch out for the archived projects. Thanks for moving there reference over!

[analogrelay]

No problem! It was actually your comment that reminded us that the project needed to be properly archived so it was clear where to file issues. We wanted to preserve this thread though. Thanks!

[mockjv]

Just as a random curiosity. I was re-evaluating this to ensure I've considered all options and ran across something that raised an interesting question.

What would stop anyone for using dark.exe (Wix Toolset), to extract the ANCM MSI from the hosting bundle (probably more so from a legal standpoint than a technical standpoint) and then bundling that MSI. At the end of the day, it's the same thing that'd get installed if I ran the hosting bundle with the appropriate OPT_NO_RUNTIME OPT_NO_SHAREDFX), minus the entry in "Add and Remove Programs".

I guess that's the part about this issue that is the most frustrating. An MSI for just the ANCM exists... it's just not offered for download from the official dotnet.microsoft.com site, even though it used to be.

[analogrelay]

I'd say the only problem is that we can't guarantee official support for that scenario. I don't believe there's any problem with doing that, but it's getting pretty far off the expected path.

One thing we are looking at doing moving forward is reducing the chaos that is the downloads page (https://dotnet.microsoft.com/download/dotnet-core/3.0) and replacing it with a single simple installer that can be used to install various components at various granularity layers (there would also be an option to prepare assets for offline install). That installer certainly could allow an ANCM-only install if there was demand for it.

I'd love to hear more about the scenario you're in that requires an ANCM-only installer. From the other thread it sounds like a lot of the concern is about installer size and carrying an unnecessary runtime when your apps are deployed self-contained. Is that accurate or are there other concerns you'd like us to consider? I think those seem like reasonable problems to solve, but I just want to make sure I've got the full picture.

[mockjv]

Ok, so I apologize now but this might be a little long to give the detail I assume you'd like to see.

We have developed some small scale, usually single instance, ASP.NET Core applications where we need to keep the installation process as simple as possible (i.e., all necessary dependencies are installed, and IIS is properly configured). For several reasons, primarily security related, we've gone the direction of running these apps behind the ANCM for the IIS integration. Other additional considerations we have to make is bundling off-line installers, due to air-gapped environments, and keeping installed dependencies up-to-date due to security audits.

Long story short, we're up to whatever approach that will accomplish the above.

That said, as we've tried to devise an installer for these applications, we've run into several issues:

The very first issue that we ran into, as of .NET Core 2.0, was that the hosting bundle was the only way to get the ANCM installed. At this point, we went the direction of a non-SCD publish + bundling the full .NET Core Hosting Bundle.

This wasn't too much of a problem if it wasn't for how updated versions of .NET Core are installed. Currently, the .NET Core Runtime installers leave all previous versions behind including minor versions. This becomes a little problematic for our installer to manage when faced with the security audits mentioned above. We could simply leave those runtimes behind, but they'll continue to be flagged by the security audit. We could remove the previous versions, but we cannot guarantee that other software depends on those previous versions, plus we don't want to be responsible for breakage if an older app doesn't function correctly with the newer runtime. We could also easily indicate to the user that these runtimes are left behind and that they could be removed, but that simply passes the responsibility of knowing whether it will break things off to the user who probably won't know if it will break anything.

All that brings me back to re-evaluating self-contained distributables because it removes the separate runtime dependency, but we're back to the issue of getting the ANCM on the system. I can very easily bundle the entire hosting bundle as part of my installer by way of the suggested installation options (OPT_NO_RUNTIME), but that just doesn't seem very efficient to effectively have two copies of the runtime in my installer (my SCD + the actual runtime). That's 93mb worth of bundled software, left on the system for uninstall regardless of the OPT_NO_* options, just to get 2x small DLLs, an IIS configuration schema, and IIS configuration on the target system. This is also problematic because if a user tries to "repair" the entry in "Add and Remove Programs" for the hosting bundle, where it was installed with the OPT_NO_* options, the runtimes will end up being installed.

At the end of the day, the self-contained distributable makes the most sense for our needs, especially as features like the trimmed executable comes along with .NET Core 3.0, since it minimizes installation complexity/footprint. However, the benefits of an SCD or trimmed executable for ASP.NET Core applications are greatly diminished by the need to also include the entirety of the hosting bundle at installation time.

[btrepp]

I'll also chime in that the current situation of bundling the net core runtime makes it all very confusing.
I have a self hosted kestrel application that works fine, thinking about making it run behind IIS.

Obviously that's a module in IIS, but I need to install netcore's runtime? to host a self-hosted application?. It makes me think that perhaps self-hosted net core apps can't run behind IIS.
Now if I'm sharing an IIS server for a few apps, I have to ensure they work on the same version of netcore, and updating the framework brings back nightmares of old IIS updates.
Reading the thread it seems I might be able to use IIS to host multiple aspnetcore applications (with potential different runtime versions).

A simple standalone ANCM makes it clear that we can use IIS with self-contained aspnetcore apps, or that if we have the situation where we would like to share the runtime, the bundle supports that too. :)

[RomBrz]

Sorry to bring it up again, but i'm facing some problems related to that, and maybe this thread is in the way.

I manage multiple IIS servers with different applications (DotNet Framework 2, Framework 4, DotNet Core 2.0, 2,1, 3.0, 3.1) and to make things more simple i made scripts to remotely install and update the servers that have DotNet Core installed.

I come to split servers to that some servers hosts applications that relay on the DotNet Core installed at server level, so each month i update it all. But i made too some servers that hosts applications with self-hosted DotNet Core, so i only need to install the "Hosting Bundle" (without runtime).

I made a script to remotely install / update DotNet Core, and have to make this kind of thing:

$ParametersDotNetCore = '/install /quiet /norestart'
$ParametersDotNetCoreModule = 'OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1 /install /quiet /norestart'
If ($ServerSelfHosted -eq $true){
$DotNetCoreParameters = $ParametersDotNetCoreModule }
Else{
$DotNetCoreParameters = $ParametersDotNetCore }

$DotNetCorePath = GetLatestDotNetCoreInstallerFullPath (a function i made that returns the latest dotnetcore installer on a path with multiple installers, so each month i just need to download the latest, put on the folder and the script should get it)

Start-Process $DotNetCorePath -Wait -ArgumentList $DotNetCoreParameters

So with many other things and running Powershell remotely, i can choose to install what i just need to the respective servers.

At the end, i run this to remove every hosting bundle that was outdated:
dotnet-core-uninstall remove --hosting-bundle --all-lower-patches --force --yes

And this to uninstall the outdated runtimes:
If ($ServerSelfHosted -eq $false){
dotnet-core-uninstall remove --runtime --all-lower-patches --force --yes}
Else{
dotnet-core-uninstall remove --runtime --all --force --yes} (this is because it used to work at 3.1.6 but seems like don't work with 3.1.7, so no matter if the "OPT_NO_RUNTIME=1" works or not, this wil ensure that no runtimes would be on the server)
(I'm using "dotnet-core-uninstaller" (https://github.com/dotnet/cli-lab/releases)

maybe this could help to make things simple. Maybe a simple parameter like we have "/install", could have "/install-no-runtime"

[mockjv]

@RomBrz Interesting, I'll definitely have to look into the dotnet-core-uninstaller as that could be useful for us as well but has limited benefits to our product installers.

We ended up being relegated to bundling to whole runtime+hosting bundle into our installer, which obviously adds a pretty decent amount of bloat (~100MB added to our installer just to get a very small MSI onto the system). We moved towards using the self-contained distributables, so the need to uninstall runtimes is unnecessary and the hosting bundle always bumps to the latest ANCM.

That said, our use case for a separate ANCM installer/MSI only continues to increase as we expand our product lines: Self-Contained Trimmed .NET Core Web Apps deployed via WIX to IIS where the extra installer bloat for things we won't use is frustrating.

The other frustrating part is that the .NET Core installer projects produce an MSI, they just stopped officially publishing ANCM MSI sometime around 2.0 if I remember right. So I'd still like to eventually see this option being considered.

[jberezanski]

As one of the maintainers of .NET Core Chocolatey packages (https://github.com/dotnetcore-chocolatey/dotnetcore-chocolateypackages), I'd love to be able to publish a package which would install the ANCM only, to be used by those who do not need the systemwide runtime, saving tens of MBs on each download (this actually matters for some users).

[wk-bd]

@anurse @jkotalik I'm running into this question from a slightly different angle. Basically, I have:

• My installer, which has ASP.NET Hosting bundle 6.0.0 bootstrapped in
• The end-user, which has already installed a newer version of .NET Core runtime (say for example 6.0.1) with something else

In this scenario, when my installer runs, it sees that a newer version of .NET Core Runtime (which is part of the hosting bundle) is installed, and just stops dead. No ASP.NET or ANCM gets installed.

I can't keep updating my installer every time a new patch of ASP.NET comes out, so what do I do? The way I see it, each of these components (.NET Core Runtime, ASP.NET, and ANCM) should really have their own installers that install completely separately of each other.

As a temporary workaround, I've included all three installers (.NET Runtime, ASP.NET, and Hosting bundle) as part of my install, and then installed them all separately (ignoring return codes). It works, but adds a ton of bloat since .NET and ASP.NET get duplicated.

[joeloff]

Just as a random curiosity. I was re-evaluating this to ensure I've considered all options and ran across something that raised an interesting question.

What would stop anyone for using dark.exe (Wix Toolset), to extract the ANCM MSI from the hosting bundle (probably more so from a legal standpoint than a technical standpoint) and then bundling that MSI. At the end of the day, it's the same thing that'd get installed if I ran the hosting bundle with the appropriate OPT_NO_RUNTIME OPT_NO_SHAREDFX), minus the entry in "Add and Remove Programs".

I guess that's the part about this issue that is the most frustrating. An MSI for just the ANCM exists... it's just not offered for download from the official dotnet.microsoft.com site, even though it used to be.

Extracting the MSI with dark has a number of implications

1. You won't have the ability to properly reference count the install. ANCM ships in VS as well though that's more of a specialized case for developers working on Windows Server to test/debug against full IIS vs. IIS Express
2. You won't get any updates through Microsoft Update (Automatic Update, WSUS, Catalog or 3rd party deployments like SCCM)

If you pulled ANCM and then patched it in your install, assuming it's a WiX bundle that will honor reference counts for the MSI you should be okay, but you're still at risk of missing security updates because MU checks against the bundles .NET ship, not individual MSIs.

Chaining ANCM requires you to do a number of prerequisite checks because otherwise it will fail to run. Mostly these are around confirming that the necessary IIS features are enabled. For example, on a clean Windows machine, you would typically need to run DISM /Online /Enable-Feature /FeatureName:IIS-WebServerRole /FeatureName:IIS-WebServer /FeatureName:IIS-WebSockets /FeatureName:IIS-WindowsAuthentication /FeatureName:NetFx4Extended-ASPNET45 /FeatureName:IIS-NetFxExtensibility45 /FeatureName:IIS-ISAPIFilter /FeatureName:IIS-ISAPIExtensions /FeatureName:IIS-ASPNET45 to ensure the ANCM MSI doesn't fall over. The Hosting bundle currently duplicates those as an applicability check so you'd have to pull them out and any changes .NET makes in the future means you may need to continue making changes to stay in sync.