Cannot publish self-contained worker project referencing another

[markmnl]

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).

[markmnl]

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..

[scalablecory]

@jeffschwMSFT

[scott-ngan-cko]

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

[swaroop-sridhar]

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

[gimmi]

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

[kitattyor]

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>

[ata18]

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!

[luantian-terark]

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.

[darkguy2008]

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.

[doug62]

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.

[MarcoLuglio]

@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

[JasonGiedymin]

You can specify multiple targets like so:
<RuntimeIdentifiers>win-x64;osx-x64;linux-x64</RuntimeIdentifiers>

as per the docs "Multiple RIDs can be defined as a semicolon-delimited list in the project file's element. "

[bricelam]

Duplicate of #10566

[MarcioAB]

Add RuntimeIdentifier win-x64 in both projects P1 & P2 results in the following error message:
Assets file 'C:\xyz\P2\obj\project.assets.json' doesn't have a target for 'net6.0/win-x64'. Ensure that restore has run and that you have included 'net6.0' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project's RuntimeIdentifiers.

[darkguy2008]

Add RuntimeIdentifier win-x64 in both projects P1 & P2 results in the following error message: Assets file 'C:\xyz\P2\obj\project.assets.json' doesn't have a target for 'net6.0/win-x64'. Ensure that restore has run and that you have included 'net6.0' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project's RuntimeIdentifiers.

When you change frameworks or runtimeidentifiers in the .csproj file, make sure to delete the bin & obj folders and recompile, I've gotten that before and it gets fixed when I remove those folders to make a clean build. Also check your .vscode/tasks.json file if you have any.

[darkguy2008]

@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

Thank you and @doug62 , I ended up using project variables as suggested, just forgot to get back to you guys here :)

[MarcioAB]

Thanks but same error message even with bin & obj folders deleted.

The steps to reproduce:

1. Create and sucessfully Publish a single P1 "hello" project.
2. Add single P2 "hello" project and make P1 to reference P2.
3. Publish gets error "It is not supported to build ... please specify a RuntimeIdentifier ..."
4. Add "win-64" as RuntimeIdentifier in both P1 and P2.
5. Publish gets error "Assets file 'C:\xyz\P2\obj\project.assets.json' doesn't have a target for 'net6.0/win-x64'. Ensure that restore has run and that you have included 'net6.0' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project's RuntimeIdentifiers."

[jozefizso]

This issue still exists in the .NET 6 SDK.

[ChangeTheCode]

I also have this issue. If I try to create an application dotnet publish xxx.csproj --no-restore --configuration release -p:PublishSingleFile=true --self-contained the build failed with the error "error NETSDK1031: It is not supported to build or publish a self-contained application without specifying a RuntimeIdentifier."
If a add -r winx64 it works. Now the interesting thing the MS documentation says there is no parameter -r.

dotnet publish [<PROJECT>|<SOLUTION>] [-a|--arch <ARCHITECTURE>]
   [-c|--configuration <CONFIGURATION>]
   [-f|--framework <FRAMEWORK>] [--force] [--interactive]
   [--manifest <PATH_TO_MANIFEST_FILE>] [--no-build] [--no-dependencies]
   [--no-restore] [--nologo] [-o|--output <OUTPUT_DIRECTORY>]
   [--os <OS>] [-r|--runtime <RUNTIME_IDENTIFIER>]
   [--sc|--self-contained [true|false]] [--no-self-contained]
   [-s|--source <SOURCE>] [-v|--verbosity <LEVEL>]
   [--version-suffix <VERSION_SUFFIX>]

[adschmu]

I had the same issue with a test project referencing an ASP.NET Core web project.

This could be worked around with GlobalPropertiesToRemove="SelfContained" in .NET 6 (see #10566).

With .NET 7 SDK, this appears to be fixed for my projects, and I do not need the workaround anymore.