Should `dotnet publish` also take the elements specified in "copyToOutput"?
See original GitHub issueSteps to reproduce
This is more of a design question than a bug, up to the CLI team to decide.
Have an app such as HelloWorldMvc. In its project.json it specifies “copyToOutput”:
"copyToOutput": {
"include": [
"Views",
"wwwroot"
]
}
When I execute dotnet run
it runs fine. When I execute dotnet publish
and then dotnet path\to\publish.dll
I get runtime errors as the files it required weren’t copied. Shouldn’t the build includes be “inherited” by the publishOptions includes? In the meantime I’ll add:
"publishOptions": {
"include": [
"Views",
"wwwroot"
]
}
Expected behavior
No need to specify the same stuff twice, unless there’s differences in what’s needed for build and for publish. Publish can be overriden if that’s what’s intended.
Actual behavior
Without “publishOptions” my published app won’t run well, even tough under dotnet run
it runs as expected.
Environment data
dotnet --info
output:
.NET Command Line Tools (1.0.0-preview1-002702)
Product Information:
Version: 1.0.0-preview1-002702
Commit Sha: 6cde21225e
Runtime Environment:
OS Name: Windows
OS Version: 10.0.14295
OS Platform: Windows
RID: win10-x64
Issue Analytics
- State:
- Created 7 years ago
- Reactions:5
- Comments:5 (3 by maintainers)
I am definitely desiring an ability to tell either
copyToOutput
orpublishOptions
to just inherit the other’s definition. This shouldn’t be an automatic default, but it’d be awesome if we could specify it, say with"publishOptions": { "inherit": "copyToOutput" }
or something similar.As of right now, to update to the new schema, I’m having to duplicate the value of
content
under both new keys.I believe that the desired behavior is now in given the move to MSBuild and csproj. I will close this issue, but please reopen if it still repros with the latest CLI tooling that is based on MSBuild. Thanks!