I have a project with some NuGet dependencies, using PackageReference
:
<ItemGroup>
<PackageReference Include="Microsoft.CSharp" Version="4.7.0" />
<PackageReference Include="Microsoft.Xaml.Behaviors.Wpf" Version="1.1.19" />
</ItemGroup>
I don't want the dependencies to be installed directly in the bin\${buildConfiguration}\${framework}
folder (files in parentheses (
)
):
bin
Debug
net472
(MyLibrary.dll)
(Microsoft.CSharp.dll)
(Microsoft.Xaml.Behaviors.Wpf.dll)
Rather, I want each build's dependencies in a deeper subfolder, like this:
bin
Debug
net472
(MyLibrary.dll)
MyLibrary
(Microsoft.CSharp.dll)
(Microsoft.Xaml.Behaviors.Wpf.dll)
I know I can use a nuget.config
file to control where the solution's packages should be downloaded to, but the build output of the NuGet dependencies remains the same -- the bin/release/framework folder.
Note that I want more than just to move the files, which could be accomplished with a post-build step, and wouldn't be very useful. I need that the reference to the dependent DLL should change while building to refer the subfolder instead of the root folder; so I can copy the entire contents of the root folder as a whole to a different location, and still have it work.
MyLibrary.dll
is constructed using an SDK-format project, which uses PackageReference
; it can be either .NET Framework, .NET Core, or .NET Standard.
How can I do this?
Some background
I've authored a Visual Studio debugging visualizer for expressions. Debugging visualizers are single DLLs that are copied by hand -- along with their dependencies -- to a specific subfolder under Documents -- e.g. Visual Studio 2019\Visualizers
-- or to the Visualizers
subfolder of the VS install folder.
If there are two visualizers that depend on different versions of the same library, one is liable to break. Deleting a visualizer is a hit-and-miss affair of removing unneeded dependencies.
This is compounded by the need to create multiple DLLs when writing a visualizer for .NET Core or .NET Standard; each of those DLLs might have their own dependencies.
If it were possible to output dependencies to a subfolder with the same name, that would be a step in the right direction.
(Developer community feature request and (now-closed) request to document better solutions to this problem)