编译器声称 NuGet 包缺少命名空间，反编译器不同意？-解网

问：

我有一个项目（称之为）包含一些常用的枚举和标记类型，这是由解决方案中的许多项目完成的。Fancy.Common.TypesProjectReference

但是，我希望将其中一个项目（称为）作为 NuGet 包发布，因此我创建了一个的 NuGet 包，发布到我们公司的源。Fancy.Service.ClientFancy.Common.Types

我下载了这个 NuGet 包。用 JetBrains 的 dotPeek 反编译器打开它，我可以看到它包含所有正确的枚举定义等;似乎没什么不对劲。

当我将 to in 替换为新的 NuGet 包时，出现以下错误：ProjectReferenceFancy.Common.TypesFancy.Service.Client.csprojPackageReference

The type or namespace 'Common' does not exist in the namespace 'Fancy' (are you missing an assembly reference?)

不出所料，谷歌被证明是无济于事的。我快要放弃软件开发，去山里当隐士了，我到底做错了什么？

我试过：

清洁溶液
在 CI 管道中构建
确保和的框架相同（它们都是 net6.0。Fancy.Common.TypesFancy.Service.Client
检查拼写错误（没有，我将项目从使用项目引用转换为同一项目的包引用，名称没有更改。

ETA：@PMF建议我可能有依赖关系，而这些依赖关系又直接指向 .事实证明确实如此，但似乎不是问题的原因。ProjectReferenceFancy.Service.ClientProjectReferenceFancy.Common.Types

除了另一个项目之外，它没有依赖项，如果我将其更改为，错误仍然存在。Fancy.MessagesProjectReferenceFancy.Common.TypesPackageReference

预计到达时间2：花了六十分钟追查依赖关系，终于找到了，正如@PMF所建议的那样，存在依赖冲突。

C# 命名空间 NuGet

这是否仅在测试了使用相同版本号的包的早期版本的计算机上发生？NuGet 要求包是全局唯一且不可变的，因此，一旦它在全局包文件夹中提取包，它就不需要再次下载相同的包。但这意味着，在发布“真实版本”之前，软件包作者在测试其软件包时需要注意并使用唯一的预发行版本号。在同一解决方案/存储库中，对创建将要发布的包的项目使用 ProjectReference（而不是 PackageReference）。

1赞 PMF 6/20/2023

稍微戳一下：我看到这种行为的一个场合是如果无法正确读取 nuget。在 nuget 中，dll 是否位于？lib\net6.0\Fancy.Common.Types.dll

1赞 Kile Kasmir Asmussen 6/20/2023

@PMF 正如你所说，我第一次验证时不够勤奋。

答：

0赞 Kile Kasmir Asmussen 6/20/2023 #1

问题的根源在于，在依赖关系的深层树的某个地方，有一个项目。一旦我消除了它，它就编译了。ProjectReferenceFancy.Common.Types

使用 dotnet 包时的另一个“陷阱”：没有针对此类冲突的健全性检查。

一个比我不那么慷慨的人可能会认为这是一个明显的设计缺陷，这可能会使普通的dotnet开发人员在他们的职业生涯中损失一百个小时的生产力。

上一个：如何在 C# 中以 root 身份解析命名空间 [CS0234]

下一个：C# Visual Studio 生成：找不到依赖项项目生成/DLL 的错误，但它位于 /bin 中，并且其生成成功

编译器声称 NuGet 包缺少命名空间，反编译器不同意？

Compiler claims NuGet package missing namespace, decompiler disagrees?

评论