Skip to content

Conversation

@swaroop-sridhar
Copy link
Contributor

This change reorders certain publish targets in preparation for upcoming changes to single-file publish support in .net 5.

The behavior of dotnet publish /p:PublishSingleFile=true is different in .net 5, compared to .net core 3, as explained in this document. In some cases, the single-file bundler in HostModel library will leave certain types of files unbundled into the single-file app. These files need to be copied into the publish directory.

Currently, the Single-file bundle generator after the copy step, which places files in the publish directory. However, this model is unsuitable in .net 5, because the files to be copied will only be determined after bundle-generation.

Therefore, the BundlePublishDirectory targets now run before the copy step, along with the ILLink and ReadyToRun targets. In an upcoming change, the GenerateBundle task will generate outputs to trim ResolvedFileToPublish based on the PublishSingleFile settings. This change actually simplified a few other targets.

This change reorders certain publish targets in preparation for upcoming changes to single-file publish support in .net 5.

The behavior of `dotnet publish /p:PublishSingleFile=true` is different in .net 5, compared to .net core 3, as explained in [this document](https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md#build-system-interface).
In some cases, the single-file bundler in HostModel library will leave certain types of files unbundled into the single-file app.
These files need to be copied into the publish directory.

Currently, the Single-file bundle generator after the copy step, which places files in the publish directory.
However, this model is unsuitable in .net 5, because the files to be copied will only be determined after bundle-generation.

Therefore, the `BundlePublishDirectory` targets now run before the copy step, along with the `ILLink` and `ReadyToRun` targets.
In an upcoming change, the `GenerateBundle` task will generate outputs to trim `ResolvedFileToPublish` based on the `PublishSingleFile` settings.

This change actually simplified a few other targets.
Copy link
Member

@dsplaisted dsplaisted left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How were the files which were bundled deleted from the publish directory with the previous logic? Did the bundle task itself handle that?

CreateReadyToRunImages">
CreateReadyToRunImages;
GeneratePublishDependencyFile;
BundlePublishDirectory">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since BundlePublishDirectory runs before files are copied to the publish directory now, should it be renamed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @dsplaisted. I've renamed the target BundlePublishDirectory to GenerateSingleFileBundle.

@swaroop-sridhar
Copy link
Contributor Author

How were the files which were bundled deleted from the publish directory with the previous logic? Did the bundle task itself handle that?

In current logic, the SDK makes the decision of whether a file is bundled into the single-file app, or left on the disk in the publish directory (based on ExcludeFromSingleFile and IncludeSymbolsInPublishDirectory properties).

Therefore, the copy task only copied the unbundled files to the publish directory here: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L228

However, in .net 5, the decision of what to bundle will be a bit more complex, and will be dealt by the HostModel.Bundler which will return the set of files to keep in the publish directory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants