I have a project Project.Api
that references another project Project.DomainModel
. When I build the API project for release by running
dotnet restore && dotnet build -c Release
It builds successfully. However, when I try to publish
dotnet publish -c Release -o published --no-restore --no-build ./Project.Api
I get this error:
/usr/local/share/dotnet/sdk/2.1.302/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Publish.targets(168,5): error MSB3030: Could not copy the file "xxxx/Project.DomainModels/bin/Debug/netcoreapp2.1/Project.DomainModels.dll" because it was not found. [xxxx/Project.Api/Project.Api.csproj]
According to the error, it's looking for the referenced project in the Debug
directory, but of course it won't find it there because it will be in the Release
directory.
Project.Api.csproj
file looks like this:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="AutoMapper" Version="8.0.0" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\Project.DomainModels\Project.DomainModels.csproj" />
</ItemGroup>
</Project>
Any idea why it is looking in the Debug directory instead of Release? Getting this on both a Mac and linux machine.
Produce an executableWhen publishing your app and creating an executable, you can publish the app as self-contained or framework-dependent. Publishing an app as self-contained includes the . NET runtime with the app, and users of the app don't have to worry about installing . NET before running the app.
Build compiles the source code into a (hopefully) runnable application. Publish takes the results of the build, along with any needed third-party libraries and puts it somewhere for other people to run it.
Description. dotnet publish compiles the application, reads through its dependencies specified in the project file, and publishes the resulting set of files to a directory. The output includes the following assets: Intermediate Language (IL) code in an assembly with a dll extension.
NET Core 3.1) SDK CLI, framework-dependent executable (FDE) is the default mode for the basic dotnet publish command. You don't need to specify any other parameters, as long as you want to target the current operating system. In this mode, a platform-specific executable host is created to host your cross-platform app.
Your mistake is --no-build
, with this flag you don't let to dotnet for creating project's references dll file.
UnSuccessful publish:
dotnet publish -c Release -o published --no-restore --no-build .\App\
CSC : error CS0006: Metadata file 'C:\Path\App.Domain\bin\Release\netstandard2.0\App.Domain.dll' could not be found [C:\Path\App\App.csproj]
Successful publish:
dotnet publish -c Release -o published --no-restore .\App\
App.Domain -> C:\Path\App.Domain\bin\Release\netstandard2.0\App.Domain.dll
App -> C:\Path\App\bin\Release\netcoreapp2.1\App.dll
App -> C:\Path\App\bin\Release\netcoreapp2.1\App.Views.dll
App -> C:\Path\App\published\
Answer's sample dotnet --info
:
.NET Core SDK (reflecting any global.json):
Version: 2.1.500
Commit: b68b931422
Runtime Environment:
OS Name: Windows
OS Version: 10.0.17763
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.500\
Host (useful for support):
Version: 3.0.0-preview-27122-01
Commit: 00c5c8bc40
Read more about MSBuild, I hope this answer could help you to better understating dotnet build process.
tl;dr Create a Release publish profile with a <LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
property and also specify the publish profile in the dotnet publish command, i.e.,
dotnet publish -c Release /p:PublishProfile=Release -o published --no-restore --no-build ./Project.Api
I know this is an old question, but in case anyone else runs into it, I had a similar issue, and in my case, the solution was to make sure I had a Release publish profile, or create one if I did not. The publish profile contains a LastUsedBuildConfiguration property with a value of Release, which seems to be the key issue.
Essentially, dotnet publish -c Release
says we will build and then publish the Release build configuration. When we also specify --no-build, we are saying to skip the build step. So, we specify a build configuration to use, then tell it not to build.
Enter the LastUsedBuildConfiguration property. This property can be set in a publish profile, or is set dynamically by MSBuild during the build step. I haven't delved too far into the SDK, but here's what I suspect is happening. Since we're skipping the build step, LastUsedBuildConfiguration is not being set and is therefore not available to dotnet publish. In this case, dotnet publish assumes its default build configuration, which is Debug.
To test this, I ran the following dotnet publish commands:
When I run this command, it looks in bin/Debug (no PublishProfile specified):
dotnet publish -c Release --no-restore --no-build
When I run this command, it looks in bin/Debug (PublishProfile, but no -c Release):
dotnet publish --no-restore --no-build /p:PublishProfile=Release
When I run this command, it finally looks in bin/Release (both -c Release and PublishProfile):
dotnet publish -c Release --no-restore --no-build /p:PublishProfile=Release
Only in the last case, when both -c Release and /p:PublishProfile=Release was dotnet publish using the bin/Release directory.
That sorted it for me, hope it helps someone else out as well.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With