我试图使用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.