Support publishing self-contained applications.#151
Conversation
4e1fc9e to
39033cd
Compare
| using System.IO; | ||
| using System.Linq; | ||
| using NuGet.Packaging.Core; | ||
| using NuGet.ProjectModel; |
There was a problem hiding this comment.
nit: do you need this? don't see it in use
| <!-- TODO: https://github.com/dotnet/sdk/issues/143 - find a way to default $(PublishDir) before Microsoft.Common.CurrentVersion.targets defaults it --> | ||
| <_ShouldSetPublishDir Condition=" '$(PublishDir)' == '' or '$(PublishDir)' == '$(OutputPath)app.publish\'">true</_ShouldSetPublishDir> | ||
| <PublishDir Condition=" '$(_ShouldSetPublishDir)' == 'true' ">$(OutDir)$(_PublishDirName)\</PublishDir> | ||
| <PublishDir Condition=" '$(_ShouldSetPublishDir)' == 'true' and '$(RuntimeIdentifier)' != '' ">$(OutDir)$(RuntimeIdentifier)\$(_PublishDirName)\</PublishDir> |
There was a problem hiding this comment.
I had thought you were going with <OutDir>/publish/<RID> ?
There was a problem hiding this comment.
I was, but I got cold feet.
The issue that made me go back to this folder structure is because when you publish "portable" and then publish "self-contained" (or vice versa), your "portable" publish output will contain the RID-specific publish outputs as well:
/<OutDir>
/publish
App.dll
App.deps.json
...
/win10-x64
App.dll
App.deps.json
...
Thus, you can't just copy the "publish" folder for portable, you need to exclude all the RID specific publish folders. So I felt it would be better to keep the current folder structure, since it will be a better user experience.
There was a problem hiding this comment.
Okay I see, the xcopy experience isn't as good
|
|
||
| <PropertyGroup> | ||
| <_DotNetHostExecutableName>dotnet</_DotNetHostExecutableName> | ||
| <_DotNetHostExecutableName Condition="'$(OS)'=='Windows_NT'">$(_DotNetHostExecutableName).exe</_DotNetHostExecutableName> |
There was a problem hiding this comment.
For Cross Publish you should check the RID here rather than the current OS
There was a problem hiding this comment.
Oops - nice catch. I'll fix it.
There was a problem hiding this comment.
👍 It kind of sucks the rid is an opaque string, I guess the best to do here is look for the prefix win?
There was a problem hiding this comment.
I guess the best to do here is look for the prefix win?
Yes, that was going to be my approach. Is there a better approach? We could add a C# task that takes in a RID and returns the OS value for the RID, but that seems a bit heavy-weight for something so simple.
There was a problem hiding this comment.
yeah agreed, all of the rid handling logic I've seen is just doing a split anyways, we don't need c# for that
|
After the RID comment |
…ension or not. This supports cross-publish.
Support publishing self-contained applications.
Add NETStandard assets only for NETStandard projects
Reverting DebugType change
Use SHA256 OneShot APIs
I also fixed a minor issue where we were always writing the compile assemblies into the published deps.json file.
Fix #21 - There is nothing to do for "self-contained" apps at build time, since it is a publish time decision.
@brthor @livarcocc @nguerrera
/cc @dotnet/project-system