Website publish assumes profile by default

[Petermarcu]

Repro steps:

Install .NET Core 2.0 SDK Preview 1

dotnet new web
dotnet publish

Look in the publish folder and note that only MyApp.dll is in the published output. I expected that without specifying a publish profile, everything above netcoreapp2.0 would have been in the publish folder. The way it is today, an app will not run on a target machine that has just installed the .NET Core 2.0 runtime and I don't see how to configure it such that it will.

[Petermarcu]

/cc @DamianEdwards @bleroy @richlander

[muratg]

@Petermarcu I believe this is by design when you use Microsoft.AspNetCore.All metapackage. The idea is that when you run the right installers, your server machine will have the runtime package store side by side with the shared runtime, so for most cases, this will be a non-issue.

BTW, you can prevent trimming via a csproj property (I forgot what it was called.)

[bleroy]

The same is true of any application published against any target manifest: if the bits are not there on the other side, it'll fail. In the case of ASP.NET, it's a little more annoying because the manifest comes with the template, but fundamentally it's the same thing. That's what the feature is.

[Petermarcu]

I didn't see it in the template. It wasn't in the project file.

I also don't see installers being provided for this across all the different distros. Where are those? How does a distro build these in?

If I use the project I just made and try to publish and run on a RHEL machine, what do I do?

[davidfowl]

This is by design.

I didn't see it in the template. It wasn't in the project file.

It comes with the meta package. You can either change the property or stop using the meta package.

I also don't see installers being provided for this across all the different distros. Where are those? How does a distro build these in?

@JunTaoLuo @DamianEdwards didn't we make something for OSX and linux?

If I use the project I just made and try to publish and run on a RHEL machine, what do I do?

I'm not familiar with how RHEL packages ASP.NET (maybe they do nothing today for us so it just works) but ideally we would provide the package store for all OSes.

[Petermarcu]

Can you point me to the installer links for the ASP.NET Runtime that I need to install on all the supported OS's in order for this app to run?

What is the property I have to set to get back to the behavior that enables me to run on netcoreapp2.0?

The implicitness of it in the meta package is unintuitive, it needs to be driven from a discoverable property in the project. This package now has side effects unlike any other package that I wouldn't expect and I have no way of discovering the setting that caused this behavior.

[muratg]

You can use https://www.microsoft.com/net/core/preview#linuxubuntu (and there are links for other OSes) to download the installers with the package store.

The csproj property to turn off trimming is PublishWithAspNetCoreTargetManifest which you should set to false. But beware, you'll end up a ton of stuff in your publish output. You may instead prefer to add direct references to the packages you use instead.

@livarcocc @JunTaoLuo are there better links for the installers/zips?

[davidfowl]

The implicitness of it in the meta package is unintuitive, it needs to be driven from a discoverable property in the project. This package now has side effects unlike any other package that I wouldn't expect and I have no way of discovering the setting that caused this behavior.

I don't agree. This is the default experience we want to have for all ASP.NET applications. It also means that when you get ASP.NET, you get the runtime store by default (so we need to make that happen). Anything else should require configuration in the project file.

I spoke to Damian about the discoverability of certain properties in the project file and I don't think we should have anything in there (that's how the csproj ended up being so bloated in the first place). We can have a URL or something that points to docs of common properties you can configure in the project file. I'd prefer that rather than bloating it.

[Petermarcu]

@muratg , does that mean I need to install the whole SDK on my target production machine to run ASP.NET apps?

[livarcocc]

I wonder if we should put the runtime store bundled with the shared runtime, instead of having it bundled only with the SDK.

[davidfowl]

I wonder if we should put the runtime store bundled with the shared runtime, instead of having it bundled only with the SDK.

👍

[DamianEdwards]

@livarcocc product-packaging-wise, I think that's the logical thing to do. It's part of our (.NET Core's) default experience in 2.0. The only tricky issue I'm aware of is the build-from-source requirement for certain distros.

[bleroy]

The only tricky issue I'm aware of is the build-from-source requirement for certain distros.

Or more generally that we can only issue recommendations to third-party distro maintainers for which we don't ship our own installers. That means I think that the recommendation should state this clearly. Currently, it doesn't mention ASP.NET.

[Petermarcu]

Nothing in the shared runtime can be packages and everything in there needs to be able to build from source.

[Petermarcu]

Ignoring which installer these are in, the real challenge is that we have picked a default experience that falls apart in the end to ends because the platform needs to build from source so that distros can build it in. Redhat needs to be able to build the same SDK we build and the templates in dotnet new need to be correct for developers on Redhat.