Open antonyoni opened 3 years ago
Tagging subscribers to this area: @vitek-karas, @agocke See info in area-owners.md if you want to be subscribed.
Author: | antonyoni |
---|---|
Assignees: | - |
Labels: | `area-HostModel`, `untriaged` |
Milestone: | - |
This issue appears to be related: https://github.com/dotnet/wpf/issues/3711
any news on the issue?
If you add -p:PublishSingleFile=true
to the build step as well as the publish step, this seems to solve it. I guess defining the PublishSingleFile
property in the build outputs the file that's missing. So the working version is:
mkdir test
cd test
dotnet new console
dotnet restore -r win-x64
dotnet build --no-restore -r win-x64 --configuration Debug -p:PublishSingleFile=true
dotnet publish --no-build -r win-x64 --configuration Debug -p:PublishSingleFile=true --output ./publish
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
If you add
-p:PublishSingleFile=true
to the build step as well as the publish step, this seems to solve it. I guess defining thePublishSingleFile
property in the build outputs the file that's missing. So the working version is:mkdir test cd test dotnet new console dotnet restore -r win-x64 dotnet build --no-restore -r win-x64 --configuration Debug -p:PublishSingleFile=true dotnet publish --no-build -r win-x64 --configuration Debug -p:PublishSingleFile=true --output ./publish
Yep, that solves it. Thank you!
Is this something that still needs to be fixed then or just documented?
If you add
-p:PublishSingleFile=true
to the build step as well as the publish step, this seems to solve it. I guess defining thePublishSingleFile
property in the build outputs the file that's missing. So the working version is:mkdir test cd test dotnet new console dotnet restore -r win-x64 dotnet build --no-restore -r win-x64 --configuration Debug -p:PublishSingleFile=true dotnet publish --no-build -r win-x64 --configuration Debug -p:PublishSingleFile=true --output ./publish
This works when you're building both with the same configuration, if build is happening with a different configuration than publish, you run into the same error.
Edit: If you're cross-compiling for a different architecture, it's still broken. This works:
dotnet build -c Release --no-restore -p:PublishSingleFile=true && dotnet publish --no-build -c Release -r osx-x64 -o ~/tools/coral/osx-x64
This does not:
dotnet build -c Release --no-restore -p:PublishSingleFile=true && dotnet publish --no-build -c Release -r osx-arm64 -o ~/tools/coral/osx-arm64
Edit 2: It gets even weirder, Windows builds don't work either!
This is basically a duplicate of https://github.com/dotnet/sdk/issues/14827
The problem is that you can't set new properties in Publish because they may change things during the build which later get consumed during Publish.
How can I do this with Cake's DotNetBuild()?
I had the same problem, I fixed it by adding
<SelfContained>true</SelfContained>
to the csproj file.
On .NET 8 you have to set the "self contained" property to true, so you have to add
-p:PublishSingleFile=true --self-contained true
on both build and publish commands in order to work.
On .NET 8 you have to set the "self contained" property to true, so you have to add
-p:PublishSingleFile=true --self-contained true
on both build and publish commands in order to work.
Wow, I just had the same experience when troubleshooting a build issue. PublishSingleFile is set in the project, self contained should be the default when a runtime identifier is specified (according to docs at least).. yet it refused to build without using both of these. I don't get it, something feels very wrong here.
Description
Running the following on Windows 10 or Server Core 2019:
results in the following error message (truncated):
Removing the
--no-build
parameter or using--no-restore
fixes the issue.Configuration
Can also be reproduced on docker images:
mcr.microsoft.com/dotnet/sdk:5.0
mcr.microsoft.com/dotnet/sdk:5.0-windowsservercore-ltsc2019
Other information
Full error messages / stack trace: