在.Net标准2.0项目中添加dll参考

Question

I want to add Dll reference of system assemblies System.Runtime.Caching assembly in my .net Standard 2.0 project(using VS2019). Due to some policy restrictions nuget usage is not possible so we need to add a dll reference(assuming target system has same version of .net framework installed),

How can add this reference so that it works in different systems without using path?

I tried following without any success:

1. Adding with reference manager dialog. This adds hint path(relative) which might not work in some systems(or when directory is changed).
2. Adding <PackageReference> adds nuget package which is restricted hence can not be used.
3. Tried adding override to Microsoft.Common.targets as <AssemblySearchPaths Condition=" '$(AssemblySearchPaths)' == ''">{GAC}</AssemblySearchPaths> in csproj so that GAC is searched first. Note: Third party package management or nuget local feed is not being accepted. Also msbuild.common.targets file has {TargetFrameworkDirectory} option for resolving assemblies, so I tried adding <Reference Include="System.Xml"> to check if msbuild would search in target framework binaries but I still get same error.

In old style .net framework csproj structure(not SDK style) Adding something like <Reference Include="System.Xml"> used to work at runtime and compile time both, but it does not anymore.

Does DLL reference as mentioned above does not work in .net standard and core anymore?

Answer 1

You don't want to fight with current .NET/MSBuild architecture and NuGet. If you cannot create a local NuGet server you need to provide your path to libraries on your own. MSBuild is smart enough to find packages but if you will not provide any feed he will not resolve all of them. Under the hood, MSBuild has hardcoded paths that search for libraries as a fallback but these paths change over time when the framework evolves.

.NET Framework isn't equal to .NET Core, it's the standalone solution not related to Windows anymore so you shouldn't assume it will work as the previous framework.

Only one stable solution is to include all libs inside the project folder.

Reference still works but you need to supply a path like that(otherwise MSBuild probably will struggle to find libraries):

  <ItemGroup>
    <Reference Include="lib\$(TargetFramework)\*.dll" HintPath="%(FilePath)" />
  </ItemGroup>

I think you should speak with your client and tell him he needs a more robust solution than fighting with a chosen framework because it's detrimental for him and you.