【发布时间】:2019-10-21 22:54:53
【问题描述】:
我在这里读过一些与我类似的问题,但大约在一年前得到了回答,我们的想法是检查是否有任何关于此的消息。
假设我有一个具有以下结构的解决方案:
-
点网解决方案
- DotNetProjectReferenceSubProjects(这个项目是生成nuget包的项目)
- 项目A
- 项目B
-
项目C
-NugetPackageInsideProjectC
结构说明
这个项目的想法是从公共/私有云中检索文档,但我想让调用对调用者透明,所以我构建了这样的解决方案:
- CloudHandler.Library.csproj
- CloudHandler.Services.Factory.csproj
- CloudHandler.Plugin.Aws.csproj
- CloudHandler.Plugin.PrivateCloud1.csproj
- CloudHandler.Plugin.Gcp.csproj
- CloudHandler.Plugin.PrivateCloud2.csproj
CloudHandler.Library.csproj 参考 CloudHandler.Services.Factory.csproj
CloudHandler.Services.Factory.csproj 参考资料
- CloudHandler.Plugin.Aws.csproj
- CloudHandler.Plugin.PrivateCloud1.csproj
- CloudHandler.Plugin.Gcp.csproj
- CloudHandler.Plugin.PrivateCloud2.csproj
CloudHandler.Plugin.Aws.csproj 参考 AWSSDK.S3
当我打包 CloudHandler.Library 甚至 CloudHandler.Services.Factory 时,使用此引用的项目会抛出异常,因为它找不到 AWSSDK.S3 引用。
如何打包包含所有引用的 DotNetProjectReferenceSubProjects? (这些项目引用的项目和 NuGet 包?)
提前致谢。
我已经阅读了一些建议添加 csproj 文件的想法,并且在 nuspec 上引用了它。 考虑以后维护项目,没有知识的人很难搞清楚。
【问题讨论】:
-
你能澄清一下吗?
DotNetProjectReferencingSubProjects几乎从未打算 直接捆绑ProjectA、ProjectB和ProjectC;通常,它们都是自己的自己的 nupkg,而DotNetProjectReferencingSubProjects只是宣传对其他人的包依赖性。那是正确和正常的。如果这不是你想要的,你能更具体吗? (当然,您需要打包和部署所有这些) -
我已经编辑了这个问题,我不知道是否有助于理解。 “通常,他们都是自己的 nupkg”。 (我也读过它,但想法是封装它)
-
随着更新,听起来你在这里遇到的问题是“传递依赖链”;在切换到 SDK 风格的项目时,这个问题几乎完全得到了解决;你在使用 SDK 风格的项目吗?即一种新型的csproj? (这很好针对 .NET Framework;它不仅适用于 .NET Core)
-
我从来没有听说过你告诉我的这个,但我只是用谷歌搜索了一下,显然该项目是基于 sdk 风格的
-
“使用这个引用的项目”是?如果是这样:假设您使用的是任何类似最近的构建工具,它应该会自动展开依赖关系树;因此,如果树在某处具有该依赖关系,您将永远不会看到 AWSSDK.S3 出现问题
标签: c# .net nuget-package .net-standard-2.0