我有一个包含两个项目的解决方案 - 主要项目和单元测试项目。在Visual Studio 2015中打开时,会找到所有引用并成功构建项目。在Visual Studio 2017中打开时,找不到几个但并非所有NuGet包引用,并且编译失败。一些失败的参考文献是......
...但是其他NuGet引用没有问题。该解决方案是使用VS2015创建的。在查看.csproj文件时,没有什么特别的东西会跳出来。
我正在考虑在VS2017中从头开始重建它,以试图找出问题。
是否有其他人遇到过这个问题,并且/或者有任何人提出为什么会出现这种情况以及应该采取哪些措施来促进修复?
更新 我创建了一个引用.NET 4.7.1的全新VS2017 WebApi项目,并成功编译。然后我添加了NuGet包System.Data.Common 4.3.0。 NuGet安装过程似乎已完成,没有任何错误,但我仍然留下无效的引用。这很容易复制。
答案 0 :(得分:2)
好的,回答我自己的问题。
我找到了我认为的答案。此特定项目最初是使用.NET 4.6.2在VS2015中开发的。当更改为VS2017时,我们选择将.NET升级到4.7.1。问题在于.NET版本,而不是VS版本。
较新版本的.NET将许多这些NuGet程序集添加到标准库中。 NuGet包与本机.NET 4.7.1命名空间冲突。例如,在.NET 4.7.1中,可在程序集System.Data.dll中找到命名空间System.Data.Common。不再需要添加NuGet程序集System.Data.Common.dll。事实上,如果我添加System.Data.Common NuGet包程序集,我现在有两个具有命名空间System.Data.Common的程序集 - 一个在System.Data.dll中,另一个在System.Data.Common.dll中 - 因此参考问题。
解决方案是使用.NET 4.7.1版本并删除额外的NuGet程序集。对于System.Security冲突也是如此。与System.Net.Http的冲突实际上已移入名为Microsoft.AspNet.WebApi.Client的NuGet程序集。
我希望所有这些都可以帮助别人...(呃......)....
BTW - 当使用VS2015与.NET 4.7.1时,这些冲突会被抑制并且永远不会显示。这感觉就像VS2015的缺点。很高兴VS2017向他们展示了真正的问题......
答案 1 :(得分:0)
检查packages.config
文件以确保Nuget包实际列为项目的依赖项。
此外,在VS 2015中打开解决方案并仔细检查相关引用的文件路径。确保未从Visual Studio 2015特有的文件路径引用DLL。