Share via

how can i set the path for Dependencies in xxx.deps.json?

Rosenbohm, Mario 40 Reputation points
2026-06-22T21:05:07.5466667+00:00

Hello,

I have a number of DLLs (C# projects) that are loaded by a third-party EXE.
Each of these DLLs has a .deps.json file listing its dependencies.
The individual DLLs cannot be located in the same directory.
If all the dependencies of a DLL are in the same directory as the DLL itself, everything loads correctly.

I would like to load all dependencies from a shared directory.

How can I configure this in the xxx.deps.json file, or can I specify a directory for the dependencies for each DLL?

best regards

Mario

Developer technologies | C#
Developer technologies | C#

An object-oriented and type-safe programming language that has its roots in the C family of languages and includes support for component-oriented programming.

0 comments No comments

1 answer

Sort by: Most helpful
  1. Nancy Vo (WICLOUD CORPORATION) 6,510 Reputation points Microsoft External Staff Moderator
    2026-06-23T03:00:42.9733333+00:00

    Hello @Rosenbohm, Mario ,

    Thanks for your question.

    You cannot specify a custom directory path directly inside the xxx.deps.json file. The .deps.json file acts strictly as a manifest. It tells the runtime what dependencies (and versions) your DLL requires, but it is not designed to tell the runtime where to look for them on your local drive. By default, the runtime will only probe the application base directory or the folder where the DLL resides.

    However, since you want to maintain a clean architecture with a shared dependency folder, you can refer to some following workarounds.

    1. Using additionalProbingPaths:

    While you cannot set paths in the .deps.json file, you can use the [YourDllName].runtimeconfig.json file. You can add an additionalProbingPaths array to instruct the host to look in your shared directory.

    Example in xxx.runtimeconfig.json:

    {
      "runtimeOptions": {
        "additionalProbingPaths": ["C:\\Path\\To\\Your\\SharedDependencies"]
      }
    }
    

    Note: Because a third-party exe is loading your DLLs, this approach heavily depends on how that exe initializes its host. Sometimes, host applications ignore the runtimeconfig.json of dynamically loaded plugins.

    1. Custom AssemblyLoadContext.

    For modern .NET (.NET Core / .NET 5+), I suggest loading plugins with shared dependencies is through code using AssemblyLoadContext paired with an AssemblyDependencyResolver.

    Instead of relying on configuration files, you take control of the loading process:

    • You create a custom AssemblyLoadContext.
    • You use AssemblyDependencyResolver to parse your DLL's .deps.json file.
    • You override the Load method. When your plugin needs a dependency, your custom context intercepts the request and you explicitly tell it to load the DLL from your shared directory path using LoadFromAssemblyPath().

    I hope this addresses your question. If this response was helpful, please consider following the guidance to provide feedback.

    Was this answer helpful?


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.