About additionalAssemblyPaths in .runtimeconfig.json #96083
-
I have a native application that exposes an API to .NET (Framework in the past, 8 now) via a mixed C++/CLI assembly that depends on native DLLs (installed in WinSxS) that vary in each version. This assembly was installed in the GAC for .NET Framework. I also have a C# project that replicates the public surface of the mixed assembly and creates a reference assembly (since with the C++/CLI compiler you can't make reference assemblies or I didn't get it), and that reference assembly is the one I provide to users in a NuGet package. If a new version of the main program is released that requires the mixed assembly to be recompiled (because the version numbers of the components that are installed in WinSxS have changed), it is recompiled but the version number of the mixed assembly is not changed (because the public surface exposed to .NET has not changed), so the client programs continue to run even though the version of the main program has changed. I only change the version number of the assembly (and of the reference assembly and thus of the NuGet package) in case the public surface of the assembly changes. In .NET Framework, users who program in .NET, add a NuGet package with that reference assembly and when running their applications, as the mixed assembly is in the GAC, they can run their programs from any directory. Now that I have ported the application to .NET 8, and since we don't have GAC, I am installing the mixed assembly in the application installation directory which is: If I create a console application that uses the mixed assembly, for it to run, I must copy it (.exe, .dll, .runtimeconfig.json) in the folder Looking for information to solve this problem, I see that in theory this is solved by adding the path where the runtime assemblies are in "additionalAssemblyPaths" of the .runtimeconfig.json file of the application: "additionalAssemblyPaths": [
"C:\\Program Files\\Digi21.net\\Digi3D.NET"
] but when I run the program, it is not able to locate the assembly. If I copy this same program to Could someone help me? Maybe I didn't understand the meaning of "additionalAssemblyPaths". |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
The problem is that the NuGet packages I am deploying do not provide Runtime assemblies and therefore the applications that are built against these NuGet packages do not provide the "runtime" node and therefore the loader does not know how to locate the assemblies. To solve this problem I have created a repository that implements an application that adds the "runtime" node with the assembly name to the |
Beta Was this translation helpful? Give feedback.
The problem is that the NuGet packages I am deploying do not provide Runtime assemblies and therefore the applications that are built against these NuGet packages do not provide the "runtime" node and therefore the loader does not know how to locate the assemblies.
To solve this problem I have created a repository that implements an application that adds the "runtime" node with the assembly name to the
.deps.json
file of the compiled application.This application can be added as a Post Build Event in the NuGet package.