sdk icon indicating copy to clipboard operation
sdk copied to clipboard

Cannot publish self-contained worker project referencing another

Open markmnl opened this issue 6 years ago • 18 comments

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 avatar Dec 01 '19 23:12 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..

markmnl avatar Dec 02 '19 00:12 markmnl

@jeffschwMSFT

scalablecory avatar Dec 02 '19 17:12 scalablecory

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

scott-ngan-cko avatar Dec 18 '19 22:12 scott-ngan-cko

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

swaroop-sridhar avatar Jan 04 '20 01:01 swaroop-sridhar

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

gimmi avatar Mar 18 '20 15:03 gimmi

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>

kitattyor avatar Mar 19 '20 03:03 kitattyor

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!

ata18 avatar Jul 26 '20 03:07 ata18

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.

luantian-terark avatar Sep 29 '20 07:09 luantian-terark

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.

darkguy2008 avatar Nov 20 '20 13:11 darkguy2008

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.

doug62 avatar Nov 28 '20 17:11 doug62

@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

MarcoLuglio avatar Dec 14 '20 15:12 MarcoLuglio

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 <RuntimeIdentifiers> element. "

JasonGiedymin avatar Jan 21 '21 14:01 JasonGiedymin

Duplicate of #10566

bricelam avatar Aug 13 '21 19:08 bricelam

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.

MarcioAB avatar Jan 10 '22 20:01 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.

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 avatar Jan 10 '22 21:01 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 :)

darkguy2008 avatar Jan 10 '22 21:01 darkguy2008

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

MarcioAB avatar Jan 10 '22 21:01 MarcioAB

This issue still exists in the .NET 6 SDK.

jozefizso avatar Sep 27 '22 17:09 jozefizso

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

ChangeTheCode avatar Oct 24 '22 11:10 ChangeTheCode

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.

adschmu avatar Jan 10 '23 13:01 adschmu