我试图使用c# 4.0编译我的excel插件,并在Visual Studio中构建我的项目时开始遇到这个问题。重要的是要告诉你,我以前从来没有遇到过这个问题。什么会导致这种情况发生?
当前回答
就我而言,我将项目升级到。net 4.7.2,但仍然使用旧的visual studio版本(2015年)构建。 当我在VS 2019中构建项目时,构建失败消失了。
其他回答
尝试update-package -重装-ignoredependencies
我猜您没有使用强名称程序集。当两个项目引用相同程序集的略有不同的版本,而一个更依赖的项目引用这些项目时,我就犯过这个错误。在我的案例中,解决方案是从.csproj文件中的程序集名称中删除键和版本信息(无论如何这都无关紧要),然后进行干净的构建。
不同程序集版本之间的更改与引用它们的解决方案部分兼容。如果你的情况不是这样,你可能需要做更多的工作来解决这个问题。
NuGet
使用NuGet很容易陷入这种情况,如果:
将包安装到解决方案中的一个项目。 将该包的新版本部署到包源。 将其安装到同一解决方案中的另一个项目。
这将导致解决方案中的两个项目引用该包程序集的不同版本。如果其中一个引用了另一个并且是ClickOnce应用程序,您将会看到这个问题。
要解决这个问题,在Nuget包管理器控制台中发出update-package [package name]命令,将所有内容都提升到一个公平的竞争环境,此时问题就会消失。
您应该在解决方案级别而不是在项目级别管理NuGet包,除非有令人信服的理由不这样做。解决方案级包管理避免了依赖关系的多个版本。在使用管理UI时,如果Consolidated选项卡显示1个或多个包具有多个版本,请考虑将它们合并为一个。
删除DLL(错误发生的地方)并重新构建解决方案解决了我的问题。谢谢
当我在更新WindowsAPICodePack后遇到这种情况时,我只是重新构建了解决方案。
构建——>重建方案
I recently hit this problem. In my case, I have NuGet packages on different assemblies. What I had was different versions of the same NuGet packages associated with my own assemblies. My solution was to use the NuGet package manager upon the Solution, as opposed to the individual projects. This enables a "consolidation" option, where you can upgrade your NuGet packages across as many projects as you want - so they all reference the same version of the assembly. When I did the consolidations, the build failure disappeared.
推荐文章
- 在没有事件源注册的情况下写入Windows应用程序事件日志
- 并发HashSet<T>在。net框架?
- 从控制器内获得控制器和动作名称?
- 新建T()
- 如何将枚举绑定到WPF中的组合框控件?
- 拒绝访问该路径
- Visual Studio - Resx文件默认“内部”为“公共”
- 使用linq转换列表到字典,不用担心重复
- 在Visual Studio 2010中有快速查找文件的方法吗?
- 单元测试:日期时间。现在
- 什么是回调?
- 返回匿名类型的结果?
- 何时使用IList,何时使用List
- ConfigurationManager。AppSettings在.NET Core 2.0中可用?
- 在c#的控制台应用程序中使用'async