.NET Core项目依赖“流血”问题

Question

.NET Core中的引用封装似乎已经发生了变化，使得一个项目中的引用可以“渗透”到另一个项目中。

在较早版本的.NET中，被项目“X”所引用的程序集不会暴露给引用项目“X”的其他解决方案中的项目。

例如，如果您有一个“Domain”项目引用了“Entity Framework”，将该“Domain”项目的引用添加到解决方案中的另一个项目中，并不能让该项目访问任何“Entity Framework”类。

这是一件好事情（至少在我看来是这样）。

今晚我在一个.NET Core 2.1应用程序中试验时，创建了一个利用EF Core的域项目。

然后我创建了一个单元测试项目（迫不及待地想要利用新的EF Core InMemory提供程序），并引用了我的域项目。

令我完全措手不及的是，即使我没有将EF Core NuGet包带入到单元测试项目中，该项目也能够访问EF Core类； 我唯一的假设是它能够通过我的域项目访问EF，即：

这似乎是极为不可取的；在我的单元测试中，我并不太关心引用与其他项目（如ASP.NET Core Web项目）之间的引用泄漏，但当涉及到其他项目时，我非常关心这种引用泄漏。

是否有一种方式可以隐藏/保护我的Domain项目中的这些包引用，使其不被引用它的其他项目所看到？

- RMD

---

我注意到NuGet包不是唯一的“泄漏”问题。即使您更改引用链：App-> Library1-> Library2，您也可以直接在App中使用Library2类。感谢@TheGeneral的答案，我发现PrivateAssets也可以与已引用的项目一起使用。 - jgasiorowski

Answer 1

这是一件奇怪的事情，我以前从未注意到过，

然而，请看这个链接

控制依赖资产

PrivateAssets 这些资产将被使用，但不会流向父项目

和标签

编译 lib文件夹的内容，并控制您的项目是否可以编译针对文件夹中的程序集

右键单击 类库 -> 依赖项 -> Nuget -> 包，并将 PrivateAssets 设置为编译...我似乎能够在调用的 .Net Core 项目中使用（同时隐藏依赖项）。

免责声明，我只是出于好奇心玩了一下这个设置，不确定这样做是否有任何副作用

- TheGeneral

---

“编译”关键字完美地工作了；而“all”关键字有点太严格了（它阻止了某些库的动态加载，例如System.Linq.Dynamic.Core）。令人遗憾的是，ASP.NET Core的IServiceCollection的AddDbContext扩展方法需要完整的EF Core包，这有点违背了我只想将该引用限制在我的域项目中的愿望。 - RMD

@RMD 那也是我的经历。 - TheGeneral

由于未知原因，我无法从IDE更改“私有资产”属性，但通过编辑.csproj文件，这个解决方案对我有效。 - Tohid