New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.NET Core 2.0 MSI #848

Closed
onyxmaster opened this Issue Aug 16, 2017 · 35 comments

Comments

Projects
None yet
5 participants
@onyxmaster

onyxmaster commented Aug 16, 2017

Hi,

Is there an MSI version of .NET Core 2.0 (SDK or, preferably, WindowsHosting) available?
If not -- why not? Many (legacy) distribution systems still use MSI as the primary (and sometimes only) method of distribution. I understand that we can build MSI ourselves from the provided ZIP archives, but maybe you should consider adding MSI builds to the official distribution.

Thank you.

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Aug 17, 2017

The exe installations that are offered for .NET Core and the Windows Hosting Bundle are based on MSI's but they are chained together using a boostrapper exe. Are you looking for something with a .msi extension and you can't use the .exe's that have msi's in them? Like this one? https://aka.ms/dotnet-sdk-2.0.0-win-gs-x64

@onyxmaster

This comment has been minimized.

onyxmaster commented Aug 17, 2017

To be most specific, I need the WindowsHosting package in MSI form. Certain CM tools (like Puppet or cfn-bootstrap [Amazon Elastic Beanstalk]) that bring systems to a desired state are picky about what is considered a "package" and often use the MSI product ID to check if it should be installed in the next state update phase. There of course are ways to fix this, but providing MSIs along with other methods seems like the most "right" way to do this.

@onyxmaster

This comment has been minimized.

onyxmaster commented Aug 17, 2017

@nil4 I do not understand what do you mean. You copied the same link I provided. It does not contain the WindowsHosting package in MSI form.

@nil4

This comment has been minimized.

nil4 commented Aug 17, 2017

@onyxmaster apologies, I did not notice that the download link points to an exe file and not an MSI. I see now what you mean.

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Aug 17, 2017

You can use the exe and it will install a set of msi's. They have product codes that could be used to detect and maintain successful installation.

@onyxmaster

This comment has been minimized.

onyxmaster commented Aug 17, 2017

Unfortunately, they can't be installed with "msiexec /i " or via WindowsInstaller.Installer COM object. Well, I have a workaround mentioned above, so if you do not feel like this should be changed, go ahead and close the issue. Thank you for considering the options.

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Aug 30, 2017

I've thought about this a bit more. There is a hacky option and a good option. The hacky option is that there is a tool that can be run to extract the msi's out of the exe. Those could then be chained together in puppet or anything else.

The better option would be to make this first class and generate everything as part of the builds where we build the exe's to also give other types of definitions for how to install the msi's directly in the right order.

@onyxmaster

This comment has been minimized.

onyxmaster commented Aug 30, 2017

I'm still all up for first-class option, workarounds tend to break in the long run.

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Aug 30, 2017

What is your primary focus? Do you need the SDK or really just the runtime that includes .NET Core and the ASP.NET Runtime Store?

Would you be interested in helping on the first-class solution?

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Aug 30, 2017

The cheapest first step I think would be to add links somewhere to just the msi's with instructions on how to chain them together. All those msi's I believe are available on public url's.

@onyxmaster

This comment has been minimized.

onyxmaster commented Aug 30, 2017

I've got a bunch of Windows 2012/2012R2/2016 Servers that I would like to continue to be managed by our puppet installation when we move to .NET Core. Currently they are provisioned semi-automatically and then are never logged into unless a production-level PerfView recording is needed. With MSIs we (and probably other shops with similar setups) can do this easily and without fear of breaking something.
We only need hosting package (runtime + store).

@onyxmaster

This comment has been minimized.

onyxmaster commented Aug 30, 2017

If I can be of any help -- sure, by my MSI knowledge is mostly limited to building service deployments with WIX.

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Aug 30, 2017

@joeloff do you know of a link to the runtime store msi's that a doc could point to? I can try to get the links for the runtime msi's.

@onyxmaster I don't think msi knowledge would be needed. I was more thinking someone like you could contribute anything that would take the msi's and wrap them in puppet so other folks could also use puppet to install the msi's.

@Petermarcu Petermarcu self-assigned this Aug 30, 2017

@onyxmaster

This comment has been minimized.

onyxmaster commented Aug 30, 2017

The best part with puppet on Windows is its native MSI support. It's basically one line, where you specify the package source and, optionally the product id (to verify if the specific version is installed).

@joeloff

This comment has been minimized.

joeloff commented Aug 30, 2017

We have a separate bundle for just the runtime stores or for the hosting bundle (which contains the runtime, runtime package store and ANCM). We don't ship the MSI individually because of reference counting.

There are links on https://www.microsoft.com/net/download/core#/runtime for the hosting bundle and on https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.0.0-download.md#aspnet-core-package-store for the individual package store bundles.

Direct links for 2.0:

https://aka.ms/aspnetcore.2.0.0.runtimepackagestore_x64
https://aka.ms/aspnetcore.2.0.0.runtimepackagestore_x86
https://aka.ms/dotnetcore.2.0.0-windowshosting

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Aug 30, 2017

@joeloff doesn't reference counting happen with CA's in the installers or is it all at the bundle level? For people managing their own deployments using puppet, I'm not sure they care if we enforce reference counting.

@onyxmaster can you confirm that in your use case, you just rebuild the images rather than uninstall a bunch of stuff to clean things up?

@onyxmaster

This comment has been minimized.

onyxmaster commented Aug 30, 2017

Also, Ansible (we're considering moving to, also considered more modern among the configuration management systems) has the same level of MSI support, along with Chef. Excluding containers, these three are, as far as I know, the most widely used CM systems.

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Aug 30, 2017

@richlander as well as FYI

@joeloff

This comment has been minimized.

joeloff commented Aug 30, 2017

@Petermarcu the reference count is done through a CA in the MSI, but it's done at the bundle level. We currently ship the MSIs for the stores in three bundles: SDK, Server Hosting and a standalone store only bundle. When you install the MSIs directly in environment where these bundles are present.

@onyxmaster

This comment has been minimized.

onyxmaster commented Aug 30, 2017

We rebuild machines when we repurpose them, with Windows machines it happens rarely, because the only software we install after provisioning is updates to the Windows itself and updates to our monitoring agents.

@onyxmaster

This comment has been minimized.

onyxmaster commented Aug 30, 2017

We're not looking to integrate .NET core into installer WIMs though, we prefer base installer to be as unchanged as possible.

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Aug 30, 2017

@onyxmaster Would another option here be for us to provide puppet classes/modules that do the right things for the exe's we already provide?

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Aug 30, 2017

It looks like if there was a chocolatey module, then it would be easy to include our exe's in puppet. https://forge.puppet.com/puppetlabs/chocolatey

Do you use chocolatey for anything else?

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Aug 30, 2017

Looks like there are community packages for .NET Core 2.0 runtime and ASP.NET Core 2.0 Runtime store available in chocolatey.

https://chocolatey.org/packages/dotnetcore-runtime.install
https://chocolatey.org/packages/aspnetcore-runtimepackagestore/2.0.0

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Aug 30, 2017

Seems like we should just help make those packages work well :) https://github.com/jberezanski/dotnetcore-chocolateypackages

@jberezanski :)

@joeloff

This comment has been minimized.

joeloff commented Aug 30, 2017

I took a quick peek. The current package checks for IISExpress, which is not supported by the hosting bundle. We only redist ANCM for IIS in the hosting bundle. IISExpress ANCM is supported in VS for development.

Having IIS is also not a requirement, only if you want to use ANCM. If IIS is absent, the bundle will just skip the ANCM package and install the rest: the runtime and package store

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Aug 31, 2017

@joeloff do you want to try to make a PR to their repo to fix that?

@jberezanski

This comment has been minimized.

jberezanski commented Sep 4, 2017

Hi all,

The dotnetcore-windowshosting Chocolatey package is designed to install the ANCM (and only the ANCM).

  1. If the user requests Chocolatey to install the dotnetcore-windowshosting package, the expected result after the installation is that the ANCM gets installed on the machine. That is the reason for the IIS/IIS Express precondition check in the package installation script: because the installation bundle skips installing the ANCM if neither of them is installed, it would not make sense for the dotnetcore-windowshosting package to report successful installation if nothing is actually installed on the system.

  2. The runtime and the package store have their own packages (dotnetcore-runtime.install and aspnetcore-runtimepackagestore). Required dependencies are modelled using package dependency (the dotnetcore-windowshosting package depends upon aspnetcore-runtimepackagestore) and they are resolved by the package manager. Installation of optional dependencies (the runtime) is left to the discretion of the user*.

*At least, this is how things worked in 1.0 and 1.1. I can see that the 2.0 hosting bundle does not respect the OPT_INSTALL_LTS_REDIST and OPT_INSTALL_FTS_REDIST flags anymore and installs the 2.0 runtime anyway. Is this a bug or intentional? (If the latter, then https://github.com/aspnet/AspNetCoreModule/blob/dev/README.md should probably be updated.)

From packaging standpoint, it would be most convenient if you distributed an installer containing the ANCM only.

@joeloff

This comment has been minimized.

joeloff commented Sep 5, 2017

The check for IIS is definitely good to have since ANCM will fail if IIS isn't present. However, the bundle doesn't carry ANCM for IISExpress so that check is not necessary. We only carry ANCM for IISExpress as part of Visual Studio.

As for the commandline flags, there is a bug tracking to update them for 2.1.0. In 2.0, we don't currently have an LTS/FTS stream, there's only a single runtime.

@jberezanski

This comment has been minimized.

jberezanski commented Sep 6, 2017

Indeed, the bundle does not install the ANCM for IISExpress. Honestly, I have no idea what made me believe otherwise back when I made the package for 1.0.0. I will remove all IISExpress related code.

Would it be possible for you to publish ANCM MSIs for packaging purposes? This would save people some bandwith - they would not have to download the entire hosting bundle (containing components which would not be used anyway, because they would already have been installed by other packages).

@joeloff

This comment has been minimized.

joeloff commented Sep 6, 2017

I'll raise this with the ANCM owners. In the past we refrained from doing that because it breaks the reference counting for ANCM when installing the hosting bundle. But if ANCM were to create a separate bundle we could use that. FYI @shirhatti

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Oct 6, 2017

@joeloff is there a repo where the issue of tracking a standalone ANCM installer should be. I don't think anyone is tracking issues here.

@joeloff

This comment has been minimized.

joeloff commented Oct 6, 2017

We had an internal email thread. @shirhatti might know if we have any other issues tracking it

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Oct 9, 2017

I opened this issue to make sure there is one to track the ANCM standalone installer. I'm going to close this one now and that work can be tracked here: aspnet/AspNetCore#2236

@Petermarcu Petermarcu closed this Oct 9, 2017

jberezanski added a commit to dotnetcore-chocolatey/dotnetcore-chocolateypackages that referenced this issue Mar 20, 2018

dotnetcore-windowshosting: remove references to IIS Express
Related to #12.

As discussed in dotnet/core#848, the hosting
bundle installer does not actually contain the module for IIS Express.
No idea what gave the impression that it did back when this package was
created.

riezebosch added a commit to dotnetcore-chocolatey/dotnetcore-chocolateypackages that referenced this issue Mar 20, 2018

dotnetcore-windowshosting: remove references to IIS Express
Related to #12.

As discussed in dotnet/core#848, the hosting
bundle installer does not actually contain the module for IIS Express.
No idea what gave the impression that it did back when this package was
created.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment