Visual Studio正在寻找一个没有publicKeyToken的旧Nuget包

Question

我的项目中有一个Nuget包，以前是未签名的，没有强名称。

我已经发布了一个现在签名的新版软件包。

当我将新版本的Nuget包添加到我的解决方案时，项目中引用Nuget包中的程序集的任何位置都会导致以下构建错误：

错误CS0012类型“JsonWebToken”在未引用的程序集中定义。 您必须添加对程序集“TSC.Business.DataContracts，Version = 2.10.6.0，Culture = neutral，PublicKeyToken = null”的引用。

如您所见，编译器仍然期望没有PublicKeyToken的程序集版本。

我需要尝试确定为什么编译器仍然期望此包的publicKeyToken为null。

我尝试过的事情 - 一切都没有运气：

• 通过从packages.json，packages目录，csproj文件，bin路径中删除旧版本并运行完全清理来完全卸载旧的Nuget包。

• 验证packages.json中新版本的publicKeyToken是否正确 - 它是

• 清除我的临时ASP.Net文件

• 哎呀，甚至安装VS2019并检查那里是否存在问题 - 它确实存在

有没有人知道编译器可以在哪里寻找这个null的publicKeyToken？

Answer 1

从项目目录开始，在磁盘上查找project.assets.json 。 它可能位于obj目录中。 如果找到它，请删除它以及名为*.*proj.nuget.*所有其他文件。 这些将在下一个有用的构建中重新生成。

Answer 2

NuGet包是设计不可变的。 这意味着它的包含内容（我的意思是特定版本的包ID）无论如何都会因为任何原因而改变。 当您开始对程序集进行强名称签名时，您应该已经更改了程序包版本。 我的猜测是你没有，如果这是正确的，你就会收到错误，因为NuGet利用了包的不变性和积极的缓存。

当您谈到packages文件夹时，我假设您指的是使用packages.config项目解决方案的解决方案包文件夹。 NuGet还有一个全局包文件夹。 如果确实需要更改软件包版本的内容，则需要从全局软件包版本中删除旧内容。 但请记住，每个恢复第一个包的人都会遇到同样的问题，需要删除他们的全局包文件夹。 因此，无论何时进行任何更改，都必须更改软件包的版本。 如果您需要在最终版本制作之前生成用于测试的包，请利用语义版本控制的预发布标签。

Answer 3

我错误地回答了我在其他答案中提出的问题，但实际上是在阅读错误信息时，很明显所遇到的问题是由你认为的其他问题引起的。 我决定保留我的另一个答案，因为我已经看过很多次人们试图改变他们已经用于测试的软件包版本的内容而不理解为什么他们在尝试使用更新的软件包时看不到他们的更改。 无论如何，强名称签名程序集只能对其他强名称签名程序集具有引用/依赖关系，这意味着您的项目仍然引用一些非强名称签名的程序包（或者可能是项目引用，我不记得是否可以与packages.config项目一起发生，它不应该与PackageReference ）。 但正如错误消息所示，您的项目当前没有引用TSC.Business.DataContracts, Version=2.10.6.0, Culture=neutral, PublicKeyToken=null 。

快速确定项目正在使用哪个程序集的方法之一就是强名称签名项目。 虽然这意味着您使用的所有软件包都必须使用强名称签名，但如果您使用任何非强名称签名的第三方软件包，则无法使用。 无论如何，如果你这样做，你会得到这个错误：

MSB3188：程序集“<assembly>”必须是强签名才能标记为先决条件。

相反，您看到的错误是“类型'JsonWebToken'在未引用的程序集中定义”。 这意味着您正在引用一个程序集（我假设来自一个包），该程序集具有返回JsonWebToken类型的对象的方法或属性，并且在您的代码中使用了var jwt = 。 这会导致项目在定义该类型的程序集上具有程序集依赖项（与程序包相关性不同），但定义该类型的程序集未使用/r参数传递给编译器。 除非您自己运行csc.exe，否则这意味着您的项目无法通过项目或包引用获取引用。

原因可能是使用未正确声明其自身nuget依赖关系的包，或者您的项目可能正在使用packages.config并且项目引用使用TSC.Business.DataContracts, Version=2.10.6.0, Culture=neutral, PublicKeyToken=null 。 如果您的项目使用的是PackageReference ，那么所有依赖项都是可传递的，这意味着如果您引用使用包的项目，那么这些包也将自动提供给您的项目。 我不认为，同样是真正的packages.config项目，但我不知道到底是否ResolveAssemblyReferences在构建发生之前或运行后CSC.EXE。

假设它是一个包问题，而不是一个传递项目引用问题，当包作者使用nuspec文件来创建它们的包，因为它容易出错时，就会发生这种情况。 这就是为什么NuGet团队强烈建议使用SDK样式项目（他们可以针对.NET Framework，他们不仅限于.NET Core和.NET Standard），并使用没有nuspec的dotnet pack来自动打包所有内容。 NuGet依赖项会自动添加，因此无法实现包创作错误的类型。 如果使用nuspec打包包，请考虑切换到SDK样式项目并停止使用nuspec，否则请仔细检查包以确保它们具有正确的依赖关系（ nuget.exe pack可以自动为包和项目引用添加NuGet依赖项，但它更容易出错）。

也许我应该在这里停止我的信息，但还有另一种可能性不太可能。 我希望简单地解释一下，它不仅仅是帮助而是混淆。 由于您说在启动强名称签名时确实增加了包版本号，我希望这意味着您还增加了程序集版本号。 如果是这样，那么您应该知道版本2.10.6.0是否应该是强名称签名。 如果它应该是，那么您在构建和打包TSC.Business.DataContracts或您的项目正在使用的任何包依赖于TSC.Business.DataContracts时也遇到问题，因为显然它使用的是未签名的dll版本。 如果版本2.10.6.0是预签名版本，那么您的项目正在使用针对此旧版TSC.Business.DataContracts编译的软件包，尽管该软件包错误地无法声明对任何软件包提供的nuget依赖性提供TSC.Business .DataContracts.dll。