无法识别已安装的特定于项目的 nuget 包 [英] Installed project-specific nuget packages not being recognized

问题描述

我有一个由于 nuget 错误而无法构建的 Web 项目.

我们有许多网站都使用名为 Sitecore 的网络 CMS.我们不同的网站在不同的版本下运行.因此，我们有一个面向多个版本的通用库如此处所述.

所以，我有一个如下所示的项目结构.请记住，这是一个逻辑表示.将所有这些文件视为解决方案的根目录.

• Common.sln
  • Common.SC65.csproj
    • MyClass.cs [共享]
    • MyClass.SC65.cs
    • packages.Common.SC65.config
  • Common.SC70.csproj
    • MyClass.cs [共享]
    • MyClass.SC70.cs
    • packages.Common.SC70.config
  • Common.SC72.csproj
    • MyClass.cs [共享]
    • MyClass.SC72.cs
    • packages.Common.SC72.config

这是我现在遇到的错误:

<块引用>

C:\Path\Website.ProjectSC65\packages\Microsoft.Bcl.Build.1.0.14\tools\Microsoft.Bcl.Build.targets(225,5): 错误:找不到 C:\Path\Common\packages.config.确保此项目已安装 Microsoft.Bcl.Build，并且 packages.config 位于项目文件旁边.

这让我相信问题出在 Bcl 目标文件中，并且似乎在大喊这一行:

Website.ProjectSC65"引用了 Common.SC65.

我偶尔会遇到一些奇怪的问题，因为 nuget 包表现得很有趣，但无论我做什么，我似乎都无法摆脱这个问题.大多数情况下，一些 Update-Package -reinstall 组合可以解决我的问题.每个项目我都需要这些不同的包，因为它们支持不同版本的框架.

我完全知道它正在寻找技术上不存在的包文件，因为它应该引用packages.Common.SC65.config".

更奇怪的是，我现在在 Internet 上找不到任何引用上述技术来引用项目级依赖项的内容.我知道我曾经发现过这一点，但我不知道是否应该这样做.

那么，我需要知道的主要事情:

1. 什么可能导致我的项目构建中出现上述错误，以及如何我会修吗?
2. 设置 nuget 包的正确方法是什么在项目级别?(不是解决方案级别)

解决方案

好的，所以似乎一切都不支持包含项目级配置的技术.>

在我的 Web 项目中，我使用了 /packages/Microsoft.Bcl.Build.1.0.14/tools/Microsoft.Bcl.Build.targets 文件并修改了它所抱怨的行.

我通过替换这一行来做到这一点:ReferencedProjectPackagesConfig="$(MSBuildProjectDirectory)\packages.config"

使用这一行:

ReferencedProjectPackagesConfig="$(MSBuildProjectDirectory)\packages.$(MSBuildProjectName).config"

将项目名称注入到属性中效果很好.如果我有其他 nuget 包，我从链上的其他库中引用的其他 nuget 包可能会导致问题，这些库只是packages.config".不过就目前而言，这是一个不错的解决方案.

虽然这感觉真的很糟糕.我很想听听其他答案，尤其是那些不涉及修改包内部结构的答案.

I have a web project that won't build because of a nuget error.

We have many websites that all use a web CMS called Sitecore. Our different websites work under different versions. Thus, we have a common library that targets many versions as described here.

So, I have a project structure like seen below. Please keep in mind this is a logical representation. Consider all these files being at the root of the solution.

• Common.sln
  • Common.SC65.csproj
    • MyClass.cs [shared]
    • MyClass.SC65.cs
    • packages.Common.SC65.config
  • Common.SC70.csproj
    • MyClass.cs [shared]
    • MyClass.SC70.cs
    • packages.Common.SC70.config
  • Common.SC72.csproj
    • MyClass.cs [shared]
    • MyClass.SC72.cs
    • packages.Common.SC72.config

This is the error I'm having now:

C:\Path\Website.ProjectSC65\packages\Microsoft.Bcl.Build.1.0.14\tools\Microsoft.Bcl.Build.targets(225,5): error : Could not locate C:\Path\Common\packages.config. Ensure that this project has Microsoft.Bcl.Build installed and packages.config is located next to the project file.

That leads me to believe that the problem lies in that Bcl targets file, and it seems to be yelling about this line:

<ValidatePackageReferences Packages="@(ValidatePackages)"
                           ReferencingProject="$(BclBuildReferencingProject)"
                           ReferencingProjectPackagesConfig="$(BclBuildReferencingProjectConfig)"
                           ReferencedProject="$(MSBuildProjectFullPath)"
                           ReferencedProjectPackagesConfig="$(MSBuildProjectDirectory)\packages.config"
                           TreatWarningsAsErrors="$(TreatWarningsAsErrors)" />

"Website.ProjectSC65" has a reference to Common.SC65.

I have occasionally had weird problems with nuget packages acting funny, but I can't seem to shake this issue no matter what I do. Mostly some Update-Package -reinstall combination solves my issues. I need these different packages per project, as they support different versions of the framework.

I am fully aware that it is looking for a packages file that doesn't exist technically, as it should be referencing 'packages.Common.SC65.config'.

What's weirder still, I can't find anything on the internet now that references the above technique to reference project level dependencies. I know I found this at one point, but I have no idea if this is how it should be done.

So, the main things I need to know:

1. What could be causing the error above in my project build, and how would I fix it?
2. What is the proper way of setting up nuget packages on a project level? (not a solution level)

解决方案

Alright, so it seems like that technique of including project level configuration isn't supported out of the box on everything.

In my web project, I took the /packages/Microsoft.Bcl.Build.1.0.14/tools/Microsoft.Bcl.Build.targets file and modified the line it was complaining about.

<ValidatePackageReferences Packages="@(ValidatePackages)"
                           ReferencingProject="$(BclBuildReferencingProject)"
                           ReferencingProjectPackagesConfig="$(BclBuildReferencingProjectConfig)"
                           ReferencedProject="$(MSBuildProjectFullPath)"
                           ReferencedProjectPackagesConfig="$(MSBuildProjectDirectory)\packages.config"
                           TreatWarningsAsErrors="$(TreatWarningsAsErrors)" />

I did so by replacing this line: ReferencedProjectPackagesConfig="$(MSBuildProjectDirectory)\packages.config"

With this line:

ReferencedProjectPackagesConfig="$(MSBuildProjectDirectory)\packages.$(MSBuildProjectName).config"

Injecting the project name into the property does work well. This may cause issues later if I have other nuget packages I'm referencing from other libraries higher up the chain that are simply "packages.config". For now though, this is a decent solution.

This feels really hacky though. I'd love to hear other answers, especially ones that don't involve modifying the internals of a package.

这篇关于无法识别已安装的特定于项目的 nuget 包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！