-
Notifications
You must be signed in to change notification settings - Fork 10k
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
Website publish assumes profile by default #2033
Comments
@Petermarcu I believe this is by design when you use BTW, you can prevent trimming via a csproj property (I forgot what it was called.) |
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. |
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? |
This is by design.
It comes with the meta package. You can either change the property or stop using the meta package.
@JunTaoLuo @DamianEdwards didn't we make something for OSX and linux?
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. |
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. |
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 @livarcocc @JunTaoLuo are there better links for the installers/zips? |
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. |
@muratg , does that mean I need to install the whole SDK on my target production machine to run ASP.NET apps? |
I wonder if we should put the runtime store bundled with the shared runtime, instead of having it bundled only with the SDK. |
👍 |
@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. |
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. |
Nothing in the shared runtime can be packages and everything in there needs to be able to build from source. |
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 |
@Petermarcu let's talk about this in the runtime store sync-up in this week. I think this warrants an in-person discussion. |
/cc @omajid |
The implicit manifest on publishing ASP.NET apps is a UX question. I think the store should be separate from the sdk and separate from the runtime. They should meet as part of the installation. As part of building an installer, the manifests can also be used to build & include a pre-zipped store. This is not only useful for 3rd party linux distro maintainers:
|
It might be worth looking at how maven does it. Maven has a pretty small |
I like that idea. I've often had to dig deep to find where defaults were defined. |
For what it's worth (and I used MSBuild for a long while before I knew this was possible), you can pass This is super helpful when you want to understand exactly what is setting a property or where a target is coming from. |
oooh, now I need to make sure this is easy to find in our docs. |
@Petermarcu @DamianEdwards do you have an update (especially regarding the build-from-source)? |
Yes, the current plan we came up with is the following. Please let us know if you have feedback.
|
Please correct me if I am mistaken. Any .NET Core built by anyone not-Microsoft will result in a missing runtime store. Will the script to download the runtime store be part of .NET Core? When will it be available? Does this also mean that if I build .NET Core from source, use that to build my ASP.NET Core application, the resulting application will fail to run unless I built it with /p:TargetManifestFiles=?
TBH, I think everyone distributing binaries will be blocked. IANAL, but the .NET Library License (https://www.microsoft.com/net/dotnet_library_license.html) seems to suggest that distributing just the library (distributable code) by itself is not permitted. And that means no one can distribute it under this license?
👍 That said, I agree with @tmds about how .NET Core should not be tied to ASP.NET Core. |
I don't know why the store is bundled with the sdk. The store is a runtime feature. When you build an app, the store is not used (the nuget cache is). When you publish an app, the store is not used either (only the manifest is used to trim). This is not a concern, I simply don't understand the rationale. From your list, I deduce it will be possible to build the repositories so the final result does not include a store. Good! Point 4 and 5 gives the users the ability to install a store without the package maintainers having to violate the build-from-source guideline. Good! |
Q: Where does the ASP.NET Store manifest reside currently? Is it part of the dotnet installation? Is it in a NuGet package? |
Ouch. This will be a painful ongoing issue for us :( |
Perhaps it makes sense to add the property to the ASP.NET Core project templates? <PublishWithAspNetCoreTargetManifest>true</PublishWithAspNetCoreTargetManifest> This makes it explicit this is happening and the property can be easily found and modified by the user. Your thoughts? |
I'm not a fan of adding default like this to improve discoverability of properties, it's the reason csproj got as big as it has been in the past. I'd much rather prefer an "effective POM" approach. |
Any updates? We believe this issue - and its consequence in terms of users not being able to run ASP.NET Core applications out of the box - is a blocker for us. |
@DamianEdwards is the owner for this. |
Can't we just change the instructions for redhat until we get a more complete solution? |
FYI, I am from Red Hat. We, in partnership with Microsoft, distribute versions of .NET Core that are supported jointly by Microsoft and Red Hat. These .NET Core packages are installable via We (Red Hat):
|
I understand that, I'm just saying that until we are building from source, the deployment instructions for redhat would include an extra command line flag to disable the manifest. That IMO doesn't seem like a stretch. |
@tmds @omajid On the licensing issue, the ASP.NET Core bits should not be under a different license than the source code. @DamianEdwards can confirm that. |
That will resolve the issue, yeah. But it wont be good enough. This will be a user experience that's specific to RHEL. To anyone who skips that part of the doc, or only uses information found elsewhere, .NET Core on RHEL will be broken out of the box, especially compared to .NET Core elsewhere. Worse, if a user downloads .NET Core from Microsoft, it will suddenly appear to work on RHEL. I would certainly see this as the .NET Core version we ship being broken. Which is why we prefer to avoid this solution completely, if possible. |
@bleroy https://dotnet.myget.org/feed/aspnetcore-dev/package/nuget/Microsoft.AspNetCore.All says it's under "MS-EULA". |
@omajid I know :) Since the issue was raised, we talked about it and reached a consensus that 2.0 should change that to the |
@bleroy Oops. Please carry on, then :) |
This can't not be the default though. Everything is pretty much designed around this feature. It's the only reason we're able to use the .All package by default.
Help me understand why that's not acceptable. How do people deploy to rhel today? |
@davidfowl I think the bullet list @omajid made earlier sums it up nicely.
Is this in progress? Can we try it out? |
Based on what I have heard, there are two common scenarios. When I say RHEL, it can be a bare metal OS, a virtual machine or a container.
We generally suggest framework-dependent deployments since the RHEL package for .NET Core can work around various deficiencies in system-wide version of native libraries. For example, you get better http client support in your .NET Core application via a newer libcurl linked against OpenSSL. There are other benefits too, such as not having to rebuild your application if coreclr or another runtime component get a security update. With the assumption that ASP.NET Core is available in the runtime store, this application fails to deploy. A user can use a Microsoft provided build of .NET Core on RHEL and this application will work. Or they can take their application to another operating system (and implicitly use the Microsoft provided build) and it will also work. The result: user thinks our builds of .NET Core is broken. |
On the licensing front, here's confirmation: https://github.com/aspnet/Coherence-Signed/issues/564 This is in the 2.0 milestone. Thanks @Eilon for this. |
I can't access https://github.com/aspnet/Coherence-Signed/issues/564; I wont be able to provide any comments/feedback on that. |
I swear I was going to check that this was a public repo before I posted, and then I derped and didn't. Sorry about that. OK, let me copy the gist of it here, and let's comment here for the moment. Change ASP.NET/EF Core NuGet package licenses to Apache In other words, have the NuGet packages have the same license as the source code. |
@bleroy dotnet is installed to a non-default location on rhel (i.e. not /opt/dotnet), it would be good to verify that the rpm&script for the asp.net core store actually works. Who is working on this? |
@tmds The RPM work is here: dotnet/cli#6830 |
@tmds @JunTaoLuo is working on the runtime package store linux installers/scripts. Would you be interested in giving it a spin once we have the installer ready-ish? |
@muratg yes, definitely. We'll want to ensure this works on rhel. |
This issue is being closed because it has not been updated in 3 months. We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate. |
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.
The text was updated successfully, but these errors were encountered: