.runtimeconfig.json in PackageReference not copied to OutDir
I have a nuget package that contains a managed dll and a corresponding runtimeconfig.json (both in /lib/net6.0). That nuget package is referenced in a C# project. When I build the project only the dll is copied to OutDir, the runtimeconfig.json is missing.
What I have to do now is
Is there a better solution to this?
36 Replies
What is the purpose of runtimeconfig? Isn't it used in the build?
This file is used to configure the dotnet runtime on application startup https://learn.microsoft.com/en-us/dotnet/core/runtime-config/
.NET Runtime config options - .NET
Learn how to configure the .NET runtime using configuration settings.
It's not necessary to build a project, only to execute the assembly
I wonder why Nuget doesn't add the include
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Also true
There seems to be a similar issue here https://github.com/dotnet/sdk/issues/1675
GitHub
SDK doesnt publish exes correctly when used as a project reference ...
Often a group of exes need to be built and deployed together. This is common in applications like Roslyn where we ship several exes as a single unit: csc, vbc and VBCSCompiler. Rather than building...
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
The reason it's in there is because that nuget package contains a managed dll which is the entry point in a self hosted runtime scenario
The docs say, "When a project is built, an [appname].runtimeconfig.json file is generated in the output directory.". So I would imagine if your project needed one it would also get generated
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
The Nuget one was probably generated when that project was built
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Maybe something here can help you generate the right config https://learn.microsoft.com/en-us/dotnet/core/runtime-config/
.NET Runtime config options - .NET
Learn how to configure the .NET runtime using configuration settings.
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Neither do I
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
You
init a nuget after building it
In .NET 6 "The .NET SDK no longer generates the runtimeconfig.dev.json file by default". Maybe that's why your build isn't making its ownThe scenario is as follows:
1. There exists a native executable over which I have no control
2. There exist several nuget packages that contain a mix of managed and unmanaged binaries. The unmanaged binaries will be executed at some point by the native executable. These packages act as an app host. They startup the dotnet runtime, execute some managed code on it and then load the consumer of the nuget package as a managed plugin into the runtime.
3. There exists a C# project which consumes these nuget packages. This project can be seen as a plugin to the main framework, which is located in one of the nuget packages
"if you still require this file, add <GenerateRuntimeConfigDevFile>true</GenerateRuntimeConfigDevFile> to your project"
I think your main build would have previously, in .NET 5, recognised that it needs a runtimeconfig and generated one to suit all the Nuget dependencies, but now you have to force it to generate one
I already have a runtimeconfig which is perfectly fine. I just need it to be in the right place
The C# project is not the entry point of the application so it shouldn't configure the runtime either
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
The runtimeconfig you have was generated for the Nuget package it came with, where the authors are not aware of which other libraries that package will be used with, so I still think something on your side should be generating one based on the total dependencies of your solution
I have full control over the nuget packages, but why should someone else generate the runtimeconfig for an assembly that was already built?
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
You have control of the packages but the package author doesn't
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I'm sorry I can't follow you. The contents of the nuget package are essentially an app. You could in theory do
dotnet exec Bla.dllUnknown User•3y ago
Message Not Public
Sign In & Join Server To View
why not?
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
tebeco#0205
generate that on publish on the REAL built project
Quoted by
<@!689473681302224947> from #.runtimeconfig.json in PackageReference not copied to OutDir (click here)
React with ❌ to remove this embed.
tebeco#0205
sdk have targets for these
Quoted by
<@!689473681302224947> from #.runtimeconfig.json in PackageReference not copied to OutDir (click here)
React with ❌ to remove this embed.
tebeco#0205
ship a target plug-in onto existing targets
Quoted by
<@!689473681302224947> from #.runtimeconfig.json in PackageReference not copied to OutDir (click here)
React with ❌ to remove this embed.
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Ok, so we have our own runtime bootstrapping that roughly follows the AppHost example. We have our own logic to find the runtime and hostfxr but that's not important here. What is important, is that we start the CLR from C++ and then we load the managed dll (Bla.dll) and query it for a specific static method, which we then call.
That static method then loads the lib that is built by the C# project. The problem is that we have multiple teams working on different parts of the whole code base, so everything has to be somewhat modular. And we chose nuget to carry these modular pieces because we mainly use C# and VS.
For several reasons, the part that hosts the dotnet runtime is not the final node in the dependency hierarchy. As I said earlier, the C# project in question is the final dependency and it needs to 1. build against the API that we publish with the AppHost, and 2. have the AppHost located in the right location because it's the final project that will eventually be used to publish everything (the AppHost, main framework and itself). This C# project is a plugin, it doesn't contain the entry point of the application or even the dotnet runtime so I don't see why this project should be responsible for creating a runtimeconfig. It has no idea which exact runtime version will be used or where it will be located in the end.