1

Let's say that we include Nuget Package Microsoft.Extensions.Configuration in a Console .Net Core app, and include the same package in another Console .Net Core app.

When we publish these two apps, each app would publish:

Microsoft.Extensions.Configuration.Abstractions.dll
Microsoft.Extensions.Configuration.dll

in each folder.

If we had 10 console apps using the same package, we would have these dlls in 10 different folders in the application server. If we reference to multiple NuGet packages, the number of dependency dll files would multiply.

Is there a way to consolidate these dlls in one folder in the app server, so when we publish our executable, all we need to do is move the executable and configuration file to the server, and it will find these dlls in a common folder. Sort of setting a dll Path.

Stephen Kennedy
  • 20,585
  • 22
  • 95
  • 108
Yogi
  • 410
  • 4
  • 16
  • 2
    So you're looking for [the .Net Core equivalent of the GAC](https://stackoverflow.com/questions/35538093/is-there-any-gac-equivalent-for-net-core)? – gunr2171 Jul 09 '19 at 20:15
  • What stops you from put all the executable's/config's in the same folder?...with that, problem solved. – Asons Jul 09 '19 at 21:49
  • Yes kind of equivalent to GAC but in a simple folder. The problem with executables / config's in the same folder is a bit messy, plus, the config filenames need to be different for each .exe. Also, having a bunch of dlls and a bunch of exe and a bunch of configs in the same folder really defeats the purpose of FileSystem. As a workaround, this could be done. But we are still hoping to house the DLLs in one folder – Yogi Jul 09 '19 at 23:52
  • After researching further this link: https://natemcmaster.com/blog/2019/01/09/netcore-primitives-3/ gives a fix, which is to add "AdditionalProbingPaths" to appName.runtimeconfig.json. But then we will still need to put full path to the DLL runtime in appName.deps.json. For example, something like this: "runtimes/win/lib/netstandard2.0/System.Threading.AccessControl.dll" could be changed to "C:\CoreDLL\System.Threading.AccessControl.dll" . By changing these two files the DLLs can be housed in one common folder. But we need to save these files because they got wiped out on every publish – Yogi Jul 10 '19 at 00:19
  • @Yogi If that answers your question, you should create an answer below and accept it so others who have the same question can find it easily. – Trisped Jul 10 '19 at 20:06

1 Answers1

1

In consideration of Trisped's suggestion, I am posting an answer that neither me nor my boss are completely satisfied with. But for the time being to the best of my knowledge, the way to consolidate these DLLs is by writing a utility program to move those DLLs to a designated common DLL folder. And, at the same time update both .deps.json file and .runtimeconfig.json file with the new location path of the common DLL folder and additionalProbingPaths folder path structure, respectively.

We can't do this by hand manually because there would be too many DLLs to move and too tedious to edit .deps.json file, which got wiped out everytime we publish the Console App solution. I have written the utility program. Unfortunately this is company's IP so I can't share the code.

The idea is to enumerate the DLLs in the publish folder and store those filenames in a collection / dictionary, and later on use that dictionary to update the runtime dll paths in .deps.json. For CLI use, I use these options:

-c Release -f netcoreapp3.0 --self-contained false -r --runtime win-x64 -o <publisheFolder>

It would be very helpful if Visual Studio Publish Profile would include a folder that we can specify, where all Third Party and Nuget Package DLLs will reside, in addition to the Publish folder, where only the app executable, app dll, configuration files, deps.json and runtimeconfig.json will reside. Even better if the CLI would allow additional option to specify the DLL folder and, not include the runtime folder when --self-contained false is indicated.

After all, isn't one of the main purpose of DLL to allow applications to share code with each other?

Yogi
  • 410
  • 4
  • 16