ANCM should be available as a standalone installer

[Tratcher]

From @Petermarcu on October 9, 2017 1:9

@jberezanski asked for this.

Filing this to track the only open issue here: dotnet/core#848

Copied from original issue: dotnet/aspnetcore#2236

[jkotalik]

@shirhatti @pan-wang I think we can pull this off with adding ANCM to Universe. Would we package it as aspnetcore.dll and the schema file?

[guardrex]

Note that the ask for this just came up again on Slack from @tebeco. Several have asked over the last year or so. I think the set of switches for the hosting bundle installer that permitted only the module and schema to be installed were disabled around the time that the runtime store bits were added.

I hope this will feature will come back ... it's really nice for self-contained app lovers ❤️.

[EDIT] imo, the old approach of a switch for the hosting bundle installer would be ok, too.

[tebeco]

a small summary of the question i asked on slack looked like this :
how do you go to production with a hight velocity and really small friction ?
Easy if there near to 0 manual or semi manual operation on server.
By that i mean,

• no runtime installed globally
• no patch campaign
• no installer as much as possible

Choice obviously goes for self contained app.
But then a problem appear when you are trying to host behind/within IIS
best choice with 2.1.x seems ANCM configured to w3wp bootstrap the app

So the big question is easy, how do i get ANCM + thé website, up and running on an iis server where all i have to do is :

• drop appoffline.html
• swap content
• remove appoffline.html

the new “content” contains self contained ed app so it can update the runtime to 2.2.x for example

but how will we get to update the ANCM ?

windows update on corporate network is a joke, for tons of bad excuses ... still not a possibility

msi could be a choice but probably the last one ;)

[tebeco]

And here is the harder question

let’s pretend there is a stand-alone installer

let’s predict a new version of ANCM with breaking changes
we kinda share IIS in DMZ so ...
in order to install patched ANCM, we are driven by the slowest app aligning to this new version of ANCM ? (because of that potential breaking change in the patch)

so unless ANCM is fully self contained within the dropped artifact how should we deal with this scenario ?

[tebeco]

also about that previous question ... if we ship to any cloud are we driven by the fact that ANCM need to be shipped on IIS on that cloud (meening not the app owner but the company responsible for the cloud MSFT, amazon etc ....)

having a fully self contained app that include the Module would help not rely on all this kind of friction

[shirhatti]

I think we can pull this off with adding ANCM to Universe. Would we package it as aspnetcore.dll and the schema file?

@jkotalik Maybe bring back https://www.nuget.org/packages/Microsoft.AspNetCore.AspNetCoreModule ?

[shirhatti]

@tebeco Completely hear you. I'm going to paste in a blurb from a blog post I wrote on this.

It has been hard to iterate on ANCM since we’ve had to ensure forward and backward compatibility between every version of ASP.NET Core and ANCM that has shipped thus far. To mitigate this problem going forward, we’ve refactored our code into two separate components: the ASP.NET Core Shim (shim), and the ASP.NET Core Request Handler (request handler). The shim (aspnetcore.dll), as the name suggests, is a lightweight shim, where as the request handler (aspnetcorerh.dll) does all the request processing.Going forward, the shim will ship globally and will continue to be installed via the Windows Server Hosting installer. The request handler will now ship via a NuGet package- Microsoft.AspNetCore.Server.IIS, which you can directly reference in your application or consume via the ASP.NET Core metapackage or shared runtime. As a consequence, two different ASP.NET Core applications running on the same server can use a different version of the request handler.

[jkotalik]

Possibly. I'd rather not give a nuget package where people need to drop nuget packages globally...

[tebeco]

@shirhatti thx for the clarification

@jkotalik

people need to drop nuget packages globally

what does this mean ?
what do you propose ?

[DerAlbertCom]

ANCM as a Standalone Installer would be really nice for ASP.NET Core Deployment on Fullframework without the need to install the .NET Core Runtime.

[sdecker]

This is a MUST to be able to service .Net Core properly with embedding the runtime.

[guardrex]

@sdecker See if the switches on the hosting bundle installer meet your needs 👉 https://docs.microsoft.com/aspnet/core/host-and-deploy/iis#install-the-hosting-bundle

[sdecker]

Interesting. Is that a recent documentation update? We had not found that on our previous research. One concern is that the bundle still increments with each .Net Core release even though the IIS hosting code rarely changes.

[guardrex]

It was October 9 on dotnet/AspNetCore.Docs#8945.

the bundle still increments with each .Net Core release even though the IIS hosting code rarely changes.

Don't follow you there ... explain your concern in more detail.

[sdecker]

When a new HostingBundle is released, how do we know if the hosting module has actually updated without looking at the GitHub repo?

[sdecker]

Here's our real problem in a nutshell. All new versions including revision level (not just minor and major) install side-by-side. This means everytime we upgrade the runtime it leaves old versions. Vulnerability scanners find the old versions and flag them when they contained vulnerabilities. So even though we pushed the latest version of the runtime, we now need a convoluted uninstall all old versions first process. We'd rather embed the .Net Core runtime w/ the App and install only the hosting module. With the switches, we can only install the hosting module, but we will be installing new versions for no value adding unnecessary maintenance cycles.

[Tratcher]

@shirhatti can you follow up here?

Note https://github.com/aspnet/AspNetCoreModule/releases is obsolete.

[guardrex]

Sorry ... didn't see the "this repo is archived" message so I assumed it was still a thing.

Although ... 👀 ...

shirhatti released this on Oct 25, 2017

I should've looked at the date.

I see it now ... https://github.com/aspnet/AspNetCore/tree/master/src/Servers/IIS

[shirhatti]

@sdecker

When a new HostingBundle is released, how do we know if the hosting module has actually updated without looking at the GitHub repo?

The .NET Core download page has ASP.NET Core Module versions for every release. See this as an example- https://dotnet.microsoft.com/download/dotnet-core/2.2

Here's our real problem in a nutshell. All new versions including revision level (not just minor and major) install side-by-side. This means everytime we upgrade the runtime it leaves old versions. Vulnerability scanners find the old versions and flag them when they contained vulnerabilities. So even though we pushed the latest version of the runtime, we now need a convoluted uninstall all old versions first process. We'd rather embed the .Net Core runtime w/ the App and install only the hosting module. With the switches, we can only install the hosting module, but we will be installing new versions for no value adding unnecessary maintenance cycles

You can install just ANCM by specifying appropriate command line switches to the hosting bundle to skip installing the shared runtimes. See https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/?view=aspnetcore-2.2#install-the-hosting-bundle

[guardrex]

versions for every release

@shirhatti ... but there's no explicit list of enhancements and bug fixes for ANCM each release? The recommendation is to always to install the latest released ANCM, correct? I think we might want to say that because we don't remark on this currently.

[shirhatti]

Install the ANCM carried the by hosting bundle of the highest runtime you are targeting.

For example, if you are targeting both 2.2.x and 3.x, installing the ANCM in 3.x hosting bundle should suffice.
That being said, you're free to install both. The newest one will win.

[guardrex]

highest runtime you are targeting

... yes, but is that explicit enough for doc text given devs don't "target" patch releases? ... Patches (e.g., 2.2.1) might include ANCM perf+bug fixes. For example, netcoreapp2.2 in the app rolls forward to 2.2.1 locally. If they adopt SCD without running the 2.2.1 hosting bundle installer on the host, they'll have the 2.2.0 ANCM on the host with a 2.2.1 SCD deployed app. Safe guidance that applies broadly seems like: Always install the latest hosting bundle.

[mockjv]

Just to throw in my 2-cents, based on experiences we've had with trying to handle bundling for our installers, is that a standalone installer would be appreciated

Initially, we'd started with simply including the hosting bundle with our WIX bundle paired up with the overall .NET Core/ASP.NET Core Framework we were targeting (latest version of course).

That said, we're now facing the same issue described above. A customer flagged an older runtime installation for security flaws, and we're preparing a release with the most current version. However, this leaves installations for all prior runtimes behind. Ideally, we could just remove them, however, we cannot guarantee those runtimes aren't used by other programs (note: they most definitely will, because we have multiple products targeting .NET Core now).

Until .NET Core is more of a first-class citizen of Windows (i.e, windows update, fingers crossed with .NET 5), our best option at this point would actually be to use the self-contained distributable so we can control the .NET Core runtime as part of our products' installation, however, we're still stuck with having to use the entire hosting bundle just to get the hosting module in place.

This results in 98mb added to our installer, for 2 very small files and an entry in our shared hosting configuration for IIS. Not to mention the lovely joy that the moment a user chooses to "repair" that installation, they end up with the everything installed - I'm doubting that's an intended result.

From what I've read out of this thread, I've yet to see a convincing argument for why this isn't offered as a standalone installer. I completely get offering a bundle, because in the beginning having only a separate installer was confusing for others, but I think this use-case needs some serious consideration/attention.

Regardless, from a distribution standpoint, it just doesn't make sense when to force developers to include runtime bundles when .NET Core offers self-contained distributables.

That all said, we're >1year since this was opened, and 1/2 a year since it was last discussed...