我试图使用c# 4.0编译我的excel插件,并在Visual Studio中构建我的项目时开始遇到这个问题。重要的是要告诉你,我以前从来没有遇到过这个问题。什么会导致这种情况发生?
当前回答
您需要使用密钥对程序集进行签名。进入选项卡签名下的项目属性:
其他回答
在我的解决方案中有太多的项目需要逐一检查和单独更新,所以我通过以下方法解决了这个问题:
右键单击我的解决方案并选择“管理解决方案的NuGet包…” 进入更新选项卡 找到受影响的包并选择Update 单击OK,这将使包的所有实例保持最新
为任何人添加我的解决方案,这可能会有所帮助。
I had a ClickOnce solution throwing this error. The app referenced a common "Libs" folder and contained a project reference to a Foo.dll. While none of the projects in the solution referenced the static copy of the Foo.dll in the "Libs" folder, some of the references in that folder did (ie: my solution had refs to Libs\Bar.dll which referenced Foo.dll.) Since the CO app pulled all the dependencies from Libs as well as their dependencies, both copies were going into the project. This was generating the error above.
我通过将我的Libs\Foo.dll静态版本移动到一个子文件夹Libs\Fix\Foo.dll来解决这个问题。此更改使ClickOnce应用程序只使用DLL的项目版本,并且错误消失了。
我在从包中迁移Excel插件后遇到了这个问题。配置到PackageReference。似乎和这个问题有关。
如果你不使用ClickOnce,下面的工作作为一个粗略的解决方案(它将从.manifest文件中省略所有依赖信息):
Unload project, edit .csproj Find the section looking like this: <!-- Include additional build rules for an Office application add-in. --> <Import Project="$(VSToolsPath)\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" Condition="'$(VSToolsPath)' != ''" /> Edit a renamed copy of the referenced .targets file (in my case, the file resolved to C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets and I made a copy Microsoft.VisualStudio.Tools.Office_FIX.targets in the same folder - didn't check if it works from a different folder). Find the GenerateApplicationManifest element and change its attribute Dependencies="@(DependenciesForGam)" to Dependencies="". Change the section found in 2. to reference your edited .targets file instead.
每当VS附带的.targets文件版本更新(或者你不会得到更新)时,这将不得不重复,但我希望它能很快得到修复…
我就有这个问题。这是因为我有许多项目指向相同的组装,但从不同的版本。我解决它选择相同版本的所有项目在我的解决方案。
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.
推荐文章
- dynamic (c# 4)和var之间的区别是什么?
- Visual Studio: ContextSwitchDeadlock
- Visual Studio:如何打破处理异常?
- VS 2017 Git本地提交数据库。每次提交时锁定错误
- 返回文件在ASP。Net Core Web API
- 自定义HttpClient请求头
- 无法启动IIS Express Web服务器,注册URL失败,访问被拒绝
- 如果我使用OWIN Startup.cs类并将所有配置移动到那里,我是否需要一个Global.asax.cs文件?
- VS2013外部构建错误"error MSB4019: The imported project <path> was not found"
- 从另一个列表id中排序一个列表
- 等待一个无效的异步方法
- 无法加载文件或程序集…参数不正确
- c#中枚举中的方法
- 如何从字符串中删除新的行字符?
- 如何设置一个默认值与Html.TextBoxFor?