我们是否需要限制 .NET Core 库中的依赖项？

Question

我有一个用完整的 .NET 编写的库，我正在将它移植到 .NET Core。我打算让它以.netstandard1.1为目标（为了也与.NET45兼容）。

当我使用 Visual Studio 创建项目时，它会自动依赖于 NETStandard.Library nuget 包。

我的库只需要两个包：

• System.Runtime
• System.Runtime.InteropServices

两个问题：

1. 我是否需要将我的项目依赖项限制为仅这两个包？改写：可能是 nuget（或 Visual Studio 或其他神奇的东西）设法自行限制为仅需要的包而不是完整的 NETStandard.Library？

2. 如果第一个问题的答案是否定的，那么执行该限制是否是个好主意？

提前致谢。 （对不起我的英语，我不是母语人士）

Answer 1

你的问题有一些方面...

1. netstandard1.1 框架选项会将编辑器（此处为 VS Code）中可用的 API 界面限制为该版本可用的内容。刚刚在netstandard1.1（不可用）和netstandard1.6（可用）的VS Code 上使用File.OpenRead 进行了测试。
2. NETStandard.Library 依赖项（1.6 版适用于这两种情况）是一个包依赖项。编译程序集后，程序集本身将声明实际使用的外部程序集（也称为引用程序集）（例如 System.Runtime 和 System.Linq），而不是在 NETStandard.Library 元包中找到的所有程序集。

只要您不为 NuGet 打包它，程序集引用限制无论如何都会为您完成。然而，NuGet 打包将引用 NETStandard.Library 包

如果您使用 NuGet 并且减少对您很重要，我想正确的术语是 NuGet 依赖修剪，手动过程解释 here （简短版本：复制元包中的所有引用并删除所有您不使用的)。

Answer 2

1. 我不确定这是否是 VS 错误，但似乎 VS 不喜欢构建库并且不包含 NETStandard.Library 包:) 所以，不。
2. 除非您使用 Visual Studio Code 或记事本等，否则这会减慢您的开发速度，因为 VS 会阻止您构建项目等。所以，不要再说了。

底线。 过早的优化可能会导致比收益更多的问题。先移植你的库，然后再检查是否需要优化它。