dotnet restore 继续使用本地项目而不是 nuget 包 [英] dotnet restore keeps using local project instead of nuget package

问题描述

我在 Visual Studio 2015 中有一个 .NET-core 项目.在其中，我使用了 Nuget 包，但在发现包中的错误后，我检查了它的源代码并将库项目包含到我的解决方案中进行调试问题.成功解决问题后，我向上游发送了修复程序，它被接受并发布了新的 Nuget 包版本.所以我去了，从我的解决方案中删除了库项目，并打算将包更新到固定版本以继续处理我的项目.Visual Studio Nuget 包管理器发现了新版本，一段时间内一切正常.

然而，它没有用.每次我尝试更新或重新安装包时，库项目都会重新出现在我的解决方案中，而不仅仅是转到 nuget 包依赖项.(显然，它仍然包含我的检出版本而不是当前的 nuget 包版本，因此出现 NU1007 警告 - 指定的依赖项与它最终得到的不同.)

我已经删除了项目中的所有用户/临时文件，我已经删除了project.lock.json 文件.使用全局文件搜索，在我的项目目录下的任何文件中都没有出现库项目的文件路径(其源代码在主项目目录之外被检出).然后我运行 dotnet restore，它没有说任何有趣的东西，但它创建了 project.lock.json 文件，在里面，它添加了旧版本的包作为"type": "project" 带有 path 去它的 project.json 和 msbuildProject 去它的 xproj 文件在一个完全不同的目录中.

dotnet 在哪里记住/找到路径?应该这样做吗?我该怎么做才能阻止它这样做，而是再次开始使用标准 Nuget 包源?

解决方案

您必须将解决方案放在不同的目录中，因为 VS2015 中的 .NET Core 项目具有独特的文件系统要求，并且将它们放在同一目录中时表现不佳(每个解决方案都会生成一个隐藏的 .vs 文件夹，它们最终会重叠).

例如，您可以将目录结构更改为此:

.SolutionsA <-- 解决方案 A 的目录.SolutionsB <-- 解决方案 B 的目录.A <-- 项目 A.B <-- 项目 B

这意味着每个解决方案的隐藏 .vs 文件夹将不再重叠(即，解决方案不共享此文件夹)

.SolutionsAProjectA.sln.解决方案Aglobal.json.解决方案A.vs.解决方案BProjectB.sln.解决方案Bglobal.json.解决方案B.vs

您可以通过这篇文章获得更多信息:

NuGet 包参考

您可以在 csproj 格式中添加 NuGet 包引用，而无需在具有特殊格式的单独文件中指定它们.NuGet 包引用采用以下形式:

.

例如，如果您想在上面的项目中添加对 WindowsAzure.Storage 的引用 您只需要将以下行添加到其他两个包引用中:

 <PackageReference Include="Microsoft.NETCore.App" Version="1.0.0"/><PackageReference Include="Microsoft.NET.SDK" Version="1.0.0"/><PackageReference Include="WindowsAzure.Storage" Version="7.2.1"/></项目组>

I have a .NET-core project in Visual Studio 2015. In it, I used a Nuget package, but after finding a bug in the package, I checked out its source code and included the library project into my solution to debug the issue. After successfully resolving the problem I sent the fix upstream, it was accepted and a new Nuget package version was released. So I went, removed the library project from my solution and intended to update the package to the fixed version to continue working on my project. Visual Studio Nuget Package Manager found the new version and everything seemed fine for a while.

However, it did not work. Every time I try to update or reinstall the package, the library project reappears in my solution instead of just going to the nuget package dependencies. (Obviously, it still contains my checked-out version instead of the current nuget package version, so the NU1007 warning appears – dependency specified was different than what it ended up with.)

I have deleted all user/temporary files in the project, I have deleted the project.lock.json file. Using a global file search, there is not a single appearance of the file path to the library project (its source code was checked out outside the main project’s directory) in any file under my project’s directory. Then I run dotnet restore, it does not say anything interesting, but it creates the project.lock.json file, and inside, it adds the old version of the package as "type": "project" with path going to its project.json and msbuildProject going to its xproj files in a completely different directory.

Where does dotnet remember/find the path? Should it be doing this? What can I do to stop it from doing this and instead start using standard Nuget package source again?

解决方案

You must place the solutions into separate directories as .NET Core Projects in VS2015 has unique file system requirements, and will behave poorly when you put them in the same directory (each solution will generate a hidden .vs folder, and they will end up overlapping).

For example you could change the directory structure to this:

.SolutionsA <-- Directory for Solution A
.SolutionsB <-- Directory for Solution B
.A <-- Project A
.B <-- Project B

This would mean that the hidden .vs folders for each solution will no longer overlap (ie, the solutions do not share this)

.SolutionsAProjectA.sln
.SolutionsAglobal.json
.SolutionsA.vs

.SolutionsBProjectB.sln
.SolutionsBglobal.json
.SolutionsB.vs

You can get additional information with this article: Organizing Your Project to Support .NET Framework and .NET Core which contains an additional note:

Renaming project.json to {project-name}.project.json

• This prevents potential conflict in Visual Studio when trying to restore packages for the libraries in the same directory. For more
  information, see the NuGet FAQ under "I have multiple projects in the same folder, how can I use separate packages.config or project.json
  files for each project?".
• Alternative: Create the PCL in another folder and reference the original source code to avoid this issue. Placing the PCL in another
  folder has an added benefit that users who do not have Visual Studio
  2015 can still work on the older projects without loading the new
  solution

---

Additional Information

In addition, you might want to read more about the .NET Core Tooling in Visual Studio

csproj Format

The csproj file format has been significantly simplified to make it more friendly for the command line experience. If you are familiar with project.json, you can see that it contains very similar information. It also supports a wildcard syntax, to avoid the need of listing individual source files.

This is the default csproj that dotnet new creates. It provides you with access to all of the assemblies that are part of the .NET Core runtime install, such as System.Collections. It also provides access to all of the tools and targets that comes with the .NET Core SDK.

<Project>
  <Import Project="$(MSBuildExtensionsPath)$(MSBuildToolsVersion)Microsoft.Common.props" />
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="***.cs" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NETCore.App" Version="1.0.0" />
    <PackageReference Include="Microsoft.NET.SDK" Version="1.0.0" />
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)Microsoft.CSharp.targets" />
</Project>

As you can see, the resulting project file definition is in fact quite simple, avoiding the use of complex values such as GUIDs. A detailed mapping of project.json to .csproj elements is listed here.

Because the improved .csproj file supports wildcards, you don’t require the full listing of code files in the project file. This enables a great tooling experience: Files added to the folder will automatically show up in the Solution Explorer. Changes made in files will automatically modify the project file if needed.

NuGet Package references

You can add NuGet package references within the csproj format, instead of needing to specify them in a separate file with a special format. NuGet package references take the following form:

.

For example, if you want to add a reference in the project above to WindowsAzure.Storage you just need to add the following line to the other two package references:

  <ItemGroup>
    <PackageReference Include="Microsoft.NETCore.App" Version="1.0.0" />
    <PackageReference Include="Microsoft.NET.SDK" Version="1.0.0" />
    <PackageReference Include="WindowsAzure.Storage" Version="7.2.1" />
  </ItemGroup>

这篇关于dotnet restore 继续使用本地项目而不是 nuget 包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！