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

问题描述

我在Visual Studio 2015中有一个.NET核心项目。在其中，我使用了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

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

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

这意味着每个解决方案的隐藏 .vs 文件夹将不再重叠（即，解决方案不要分享）

  。\解决方案\A\ProjectA.sln 
。\解决方案＼ ＼A\global.json 
.\解决方案\A＼ v.vs\ 
 
 .\解决方案\B\ProjectB.sln 
 .\解决方案\B\global.json 
 .\解决方案＼ ＼B\.vs\ 
  

您可以通过本文获得更多信息：

NuGet包引用

您可以在csproj格式，而不需要在具有特殊格式的单独文件中指定它们。 NuGet包引用采用以下格式：

。

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

 < 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> 
  

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:

.\Solutions\A\ <-- Directory for Solution A
.\Solutions\B\ <-- 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)

.\Solutions\A\ProjectA.sln
.\Solutions\A\global.json
.\Solutions\A\.vs\

.\Solutions\B\ProjectB.sln
.\Solutions\B\global.json
.\Solutions\B\.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屋！