Sdk: Cannot publish self-contained worker project referencing another

Created on 2 Dec 2019  路  11Comments  路  Source: dotnet/sdk

When trying to publish single file exe for worker projects get error runtime identifier is required, but it was!

This happens when referencing another core 3 console project.

$ dotnet publish -r linux-x64 -c Release --self-contained true
Microsoft (R) Build Engine version 16.3.0+0f4c62fea for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 102.79 ms for C:\Dev\magnet-filewatcher\src\watcher\watcher.csproj.
  Restore completed in 102.79 ms for C:\Dev\magnet-filewatcher\src\worker\worker.csproj.
C:\Program Files\dotnet\sdk\3.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(127,5): error NETSDK1031: It is not supported to build or publish a self-contained application without specifying a RuntimeIdentifier.  Please either specify a RuntimeIdentifier or set SelfContained to false. [C:\Dev\magnet-filewatcher\src\watcher\watcher.csproj]

Steps to reproduce

  • Create new worker project with dotnet new worker
  • Add reference to your another core 3.0 console project with dotnet add reference
  • .NET Core SDK (3.0.100)
  • Windows 10 X64
    es).

Most helpful comment

I had the same problem with NetCore 3.1

This was not working:

dotnet publish .\src\MyProj\MyProj.csproj `
  --configuration Release `
  --runtime win-x64 `
  --self-contained true

Fixed by removing --self-contained true (that is the default anyway)

dotnet publish .\src\MyProj\MyProj.csproj `
  --configuration Release `
  --runtime win-x64

All 11 comments

I found one can get around the error by specifying <RuntimeIdentifier>linux-x64</RuntimeIdentifier> in the .csproj in both the worker and referenced console project..

@jeffschwMSFT

This is also happening to me when creating a self-contained console that references another console. Having <RuntimeIdentifier>win-x64</RuntimeIdentifier> in both .csproj gets around the issue though

This issue should be moved to https://github.com/dotnet/sdk repo

I had the same problem with NetCore 3.1

This was not working:

dotnet publish .\src\MyProj\MyProj.csproj `
  --configuration Release `
  --runtime win-x64 `
  --self-contained true

Fixed by removing --self-contained true (that is the default anyway)

dotnet publish .\src\MyProj\MyProj.csproj `
  --configuration Release `
  --runtime win-x64

Same issue with NetCore 3.1.

Temporary workaround as suggested by @markmnl

Add this to *.csproj file. Change RIDs as you wish
<PropertyGroup> <RuntimeIdentifier>win-x64</RuntimeIdentifier> </PropertyGroup>

The various combinations of --runtime and --self-contained w/ and without
<PropertyGroup> <RuntimeIdentifier>win-x64</RuntimeIdentifier> </PropertyGroup>
is all very confusing.

@gimmi 's suggestion worked for me. Thanks!

Perhaps it will be helpful:

  1. Create a new classlibrary, then move all shared classes which are in base projects into the new project.
  2. Remove reference of two console projects.
  3. Add reference between classlibrary and console projects.

This is still happening in .NET 5. Any fixes? Specifying the RuntimeIdentifier in the .csproj file is NOT a solution because if you develop on Windows, then deploy for Linux, you'll need to have two .csproj files for each OS, NOT GOOD.

I have a similar/related issue, when i build for linux (Docker/Linux/Raspberry) I get:

ld not load file or assembly 'LibUsbDotNet, Version=3.0.0.0, Culture=neutral, PublicKeyToken=c677239abe1e02a9'. The system cannot find the file specified. Also notice for linux it doesn't emit the libusbdotnet.dll,

Tip for @darkguy2008 - you can put variables into your build so you can use 1 project file.

@darkguy2008 property groups support conditions: <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
Still not a fix but better than having multiple files.
Reference is in: https://docs.microsoft.com/en-us/visualstudio/msbuild/propertygroup-element-msbuild?view=vs-2019
and https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-conditional-constructs?view=vs-2019

Was this page helpful?
0 / 5 - 0 ratings