1

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

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

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

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

正如你所看到的，编译器仍然期待一个没有 PublicKeyToken 的程序集版本。

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

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

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

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

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

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

有谁知道编译器还能在哪里寻找这个空的 publicKeyToken？

4

3 回答 3

1

project.assets.json从项目目录开始在磁盘上查找。它可能在obj目录中。如果找到它，请删除它以及所有其他名为*.*proj.nuget.*. 这些将在希望工作的下一个版本中重新生成。

于 2019-07-29T18:21:47.000 回答
1

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

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

于 2019-07-30T04:39:32.493 回答
1

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

一种快速确定您的项目正在使用哪个程序集没有强名称签名的方法是对项目进行强名称签名。虽然这意味着您使用的所有包都必须是强名称签名的，但如果您使用任何没有强名称签名的 3rd 方包，这将不起作用。无论如何，如果你这样做，你会得到这个错误：

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

相反，您看到的错误是“'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）并且dotnet pack在没有 nuspec 的情况下使用来自动打包所有内容。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 编译的包，

于 2019-07-30T12:28:53.320 回答