Open markmnl opened 4 years ago
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
`
`
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:
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
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
Duplicate of #10566
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.
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 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 :)
Thanks but same error message even with bin & obj folders deleted.
The steps to reproduce:
This issue still exists in the .NET 6 SDK.
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>]
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.
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.
Steps to reproduce
dotnet new worker
dotnet add reference
.NET Core SDK (3.0.100)