272

I'm trying to compile my excel addin using C# 4.0, and started to get this problem when building my project in Visual Studio. It's important to tell you that I haven't had this problem before. What could cause this to happen?

Kit
  • 20,354
  • 4
  • 60
  • 103
Sergey Kucher
  • 4,140
  • 5
  • 29
  • 47
  • 72
    As a quick try, clear out both the `bin` and `obj` folders of your project, and build the project again. Sometimes this works. – Jason Evans Feb 27 '11 at 13:43
  • are you signing the assembly ? – Felice Pollano Feb 27 '11 at 13:50
  • 3
    @Jason, Cleaning the project and rebuilding worked for me. I had just recently signed the assemblies and the project would build, but wouldn't publish. – Kratz Jul 07 '11 at 12:34
  • 1
    @Kratz - Glad this tip worked for you :) It's a bit like fixing your computer by rebooting it! – Jason Evans Jul 08 '11 at 08:42
  • This happened to me when configuration manager reset the build settings on several of my projects (i.e. they were not set to build on "Rebuild All"), after versioning those projects and rebuilding the error would occur. – alan Nov 16 '11 at 14:27
  • My issue was because two projects were using different references. When I consolidated the references for the solution it worked. – Mike Mar 06 '19 at 21:23

28 Answers28

271

When I had this problem I fixed it by turning off the 'Enable ClickOnce security settings'.

Menu: Project | 'Project name' Properties... | Security tab | 'Enable ClickOnce security settings' check box.

CharleZ
  • 2,727
  • 1
  • 13
  • 2
  • 2
    Did not work for me in VS2012 (checkbox is re.checked automagically during publish). I used this answer instead, as the DLL was needed for the build process only. http://stackoverflow.com/a/8123074/17713 – Matthias Meid Apr 29 '13 at 10:08
  • 3
    When using ClickOnce, this check box is automatically selected each time the application is published with the Publish wizard. See https://msdn.microsoft.com/en-us/library/1sfbfyk0.aspx for more information. – David Murdoch Apr 28 '15 at 16:54
  • 9
    I have MSVS 2015 and I don't see the security tab under project properties – zeta Aug 11 '16 at 18:57
246

My guess is that you're not working with strongly named assemblies. I've had this error when two projects reference slightly different versions of the same assembly and a more dependent project references these projects. The resolution in my case was to remove the key and version information from the assembly name in the .csproj files (it didn't matter anyway), and then do a clean build.

Changes between the different assembly versions were compatible with the parts of the solution referring to them. If this is not the case with you, you might have to do some more work to resolve the issue.

NuGet

With NuGet it's easy to get into this situation if:

  1. You install a package to one project in your solution.
  2. A new version of that package is deployed to the package source.
  3. You install it to another project in the same solution.

This results in two projects in your solution referencing different versions of that package's assemblies. If one of them references the other and is a ClickOnce app, you'll see this problem.

To fix this, issue the update-package [package name] command at the Nuget Package Manager Console to bring everything up to a level playing field, at which point the problem goes away.

You should manage NuGet packages at the solution level rather than at the project level unless there is a compelling reason not to. Solution level package management avoids the potential of multiple versions of dependencies. When using the management UI, if the Consolidated tab shows 1 or more packages have multiple versions, consider consolidating them to one.

Kit
  • 20,354
  • 4
  • 60
  • 103
  • 7
    Here is some more info: http://social.msdn.microsoft.com/Forums/en/csharplanguage/thread/6c24bb92-e488-4a91-b4e7-dc3269904697. Also, clearing *bin* and *obj* and (if in your control) setting the assembly version to the same value (e.g. leaving the build number zero) helps. – Kit Mar 09 '11 at 19:43
  • 3
    I've tacked a bit onto the end of your answer to reflect my own experience today with NuGet and this same error. Hope it helps someone out sometime (possibly even myself in a few months' time!). – Neil Barnwell May 29 '12 at 16:07
  • 2
    This error keeps popping up for me and removing the assembly name from the .csproj file, then cleaning has consistently fixed it for me. Thanks! – ScubaSteve Sep 17 '13 at 12:57
  • 1
    You may want to see [this answer](http://stackoverflow.com/a/29925343/160173) if the above answer didn't work and you think you added the NuGet reference to one of your projects using Intellisense/ReSharper. – David Murdoch Apr 28 '15 at 16:51
  • The solution contain 4 projects. One project **B** is class library. B's dll was being referenced in rest of three. The other two project's (**C** and **D**) executable are being referenced in **A**. So I build A and got very same issue. The **fix** was to rebuild rest of two projects first. And then rebuilding project **A** fixed issue. – Vikram Singh Saini May 21 '15 at 11:08
  • I had: Project A referencing lib_a, Project B referencing lib_a. I had his error because the versions of lib_a at each project were different. Similar to different versions of packages. This answer helped me figure this out – Alonzzo2 Nov 26 '15 at 13:37
  • Thanx! I just update the packages with NuGet and it fixed up! – vaheeds Feb 01 '17 at 07:11
  • Thanks! great, i have removed the old package and add the new package, clean and rebuild the solution, build successful. – charulatha krishnamoorthy Nov 18 '17 at 06:10
  • "two projects reference slightly different versions of the same assembly" rang a bell – Park JongBum Aug 08 '19 at 00:39
70

See this answer.

Go to the publish page and click on "Application Files". From there you should see a list of your DLL's. Ensure that the ones that are giving you trouble have their Publish Status marked as "Include" rather than "Prerequisite".

Community
  • 1
  • 1
Otiel
  • 18,404
  • 16
  • 78
  • 126
  • 2
    The exel addin project doesn't have Application Files button. http://stackoverflow.com/questions/6378801/i-do-not-have-application-files-dialog-box-in-my-vs2010/6379771#6379771 – Sergey Kucher Nov 25 '11 at 20:58
  • @SergeyKucher: I didn't know that. Thanks for the update. As your question doesn't precise it's for an Excel addin, I think my answer is still valid here (I had the same error message on a *winforms* project and solved it this way). – Otiel Nov 25 '11 at 21:35
  • I have a winforms project which built fine until I used the publish wizard after which I got the OP's errors. Changing the publish status fixed the problem. Thanks – Kristian Dec 17 '15 at 10:54
  • 7
    In my case, this issue was solved changing Publish Status from INCLUDE (auto) to just INCLUDE. Anyway, your answer helped not to thrust on shown values. Thanks a lot – Julio Nobre Aug 18 '16 at 15:56
23

I've had this problem. It happened because i had many projects pointing to the same assembly but from different versions. I solve it selecting the same version to all projects in my solution.

daniel
  • 331
  • 2
  • 3
13

If you have changed your assembly version or copied a different version of the managed library stated in the error you may also have previously compiled files referencing the wrong version. A 'Rebuild All' (or deleting you 'bin and 'obj' folders as mentioned in an earlier comment) should fix this case.

Sogger
  • 15,962
  • 6
  • 43
  • 40
  • A 'Rebuild All' performs a clean first, and is equivalent to 'clean' then 'build'. Good to note though is that sometimes when files have been manually copied or copied with different timestamps, the 'clean'/'rebuild' functionality does not remedy the problem and it is required to manually delete the 'bin' and 'obj' folders. – Sogger Nov 01 '12 at 16:51
  • For this issue related to Excel, deleting the bin/obj folders worked for me, the other approaches didn't. – William Melani Feb 04 '15 at 17:59
7

If you tried all the other answers in this question and you:

  • Have multiple projects in your solution
  • Have a project (Project A) that references another project (Project B), whose project references a NuGet package.
  • In Project A, you used Intellisense/ReSharper to bring in the reference to the NuGet package referenced in Project B (this can happen when a method in Project B returns a type provided by the NuGet package and that method is used in Project A)
  • updated the NuGet package via NuGet Package Manager (or CLI).

...you may have separate versions of the NuGet packages DLL in your projects' References, as the reference created by Intellisense/ReSharper will be a "normal" reference, and not a NuGet reference as expected, so the NuGet update process won't find or update it!

To fix this, remove the reference in Project A, then use NuGet to install it, and make sure the NuGet packages in all projects are the same version. (as explain in this answer)

Life Pro Tip:

This issue can come up whenever ReSharper/Intellisense suggests to add a reference to your project. It can be much more deeply convoluted than the example above, with multiple interweaving projects and dependencies making it hard to track down. If the reference being suggested by ReSharper/Intellisense is actually from a NuGet package, use NuGet to install it.

Community
  • 1
  • 1
David Murdoch
  • 87,823
  • 39
  • 148
  • 191
  • Yes, avoid using Resharper to add references. Resharper will take the reference dll from the debug (or release if you're in release mode) folder. That will cause a lot of issues, specially in huge projects. – cepriego Nov 04 '16 at 19:03
6

Adding my solution for this issue for anyone it might help.

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.

I fixed the problem by moving my Libs\Foo.dll static version into a subfolder, Libs\Fix\Foo.dll. This change made the ClickOnce app use only the project version of the DLL and the error disappeared.

Nick Gotch
  • 9,167
  • 14
  • 70
  • 97
6

Deleting the DLL (where the error is occurred) and re-building the solution fixed my problem. Thanks

Kishore
  • 653
  • 6
  • 16
  • See https://social.msdn.microsoft.com/Forums/en-US/6c24bb92-e488-4a91-b4e7-dc3269904697/project-wont-build-anymore-strong-named-problem?forum=csharplanguage – user8128167 Jun 29 '17 at 18:44
6

you need to sign the assembly with a key. Go in the project properties under the tab signing: enter image description here

Felice Pollano
  • 32,832
  • 9
  • 75
  • 115
6

I encountered this problem after migrating an Excel Addin from packages.config to PackageReference. Seems to be related to this issue.

The following works as a crude workaround if you're not using ClickOnce (it will omit all the dependency information from the .manifest file):

  1. Unload project, edit .csproj

  2. 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)' != ''" />

  3. 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).

  4. Find the GenerateApplicationManifest element and change its attribute Dependencies="@(DependenciesForGam)" to Dependencies="".

  5. Change the section found in 2. to reference your edited .targets file instead.

This will have to be repeated whenever the version of the .targets file shipped with VS is updated (or you won't get the updates), but I'm hoping it will be fixed soon...

FunctorSalad
  • 2,502
  • 25
  • 20
  • 2
    To add to this, a slightly gentler way of fixing the issue is to copy the whole section from the file located in point 3 (ie: just find the file, don't copy and rename it), to your own project's .**proj file, and make the same change as described in point 4. This will override the behaviour just for your project, and won't then affect anything else on your machine. If there are changes to the original file in a future VS update, you may still need to repeat the process. – Adam Jul 17 '19 at 22:21
5

When this happened to me with the WindowsAPICodePack after I updated it, I just rebuilt the solution.

Build-->Rebuild Solution

Nathan
  • 789
  • 11
  • 20
4

There were too many projects in my solution to go through and individually update so I fixed this by:

  • Right-clicking my solution and selecting 'Manage NuGet Packages for Solution...'
  • Going to the Updates tab
  • Finding the affected package and selecting Update
  • Clicked OK and this brought all instances of the package up to date
RagtimeWilly
  • 5,265
  • 3
  • 25
  • 41
4

Unloading and reloading the problem project solved it for me.

ChrisO
  • 5,068
  • 1
  • 34
  • 47
4

I went to publish, application files, found the dll throwing the error changed it to 'Include' from 'Include (Auto)'. I can now publish.

Jimmy
  • 575
  • 5
  • 10
3

Now Here is a different approach to the problem:

  • Right click on the project and select the 'Unload Project' option. You will notice you project becomes unavailable.

  • Right click on the unavailable project and select the 'Edit' option.

  • Scroll down to the ' < ItemGroup > ' tag that contains all the resource tags.

  • Now go to the reference that has been displayed on the error list, you will notice it it uses a single tag (i.e. < Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >).

  • Change that to look as follows:

.

<Reference Include="assemble_name_here, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" >
    < Private > True < / Private >
    < HintPath > path_here\assemble_name_here.dll < / HintPath >
< / Reference >
  • Save your changes, Right click on the unavailable project again and click on the 'Reload Project' option, then build.
Kjartan
  • 18,591
  • 15
  • 71
  • 96
TechManiac
  • 214
  • 3
  • 12
3

This is caused when you change the version of the .dll that is referenced. You need to delete all items, or the .dll in the target build folder.

jacefarm
  • 6,747
  • 6
  • 36
  • 46
Hoang Ha
  • 31
  • 2
3

Is your assembly properly signed?

To check this, press Alt+Enter on your project (or right click, then Properties). Go to "Signing". Verify that the check box "Sign the assembly" is checked and the strong name key file is selected and "Delay sign only" is unchecked.

Arseni Mourzenko
  • 50,338
  • 35
  • 112
  • 199
  • I havent signed the *.dll, but there was no problem with it before (i didnt have the compilation error before). The dll referenced in one of referenced projects of the published one, I found ugly solution to reference the dll directly from the published project, can you please tell me why does it work now? Or how could I solve the proble in opther way ? Thank you – Sergey Kucher Feb 27 '11 at 15:16
  • 1
    @user520535: well, if you haven't signed the library before, you should. It is not the only way for this library to be able to be used by signed assemblies (a signed assembly cannot call a not-signed one), but working with not signed assemblies is also very tricky when you deal with plug-ins/add-ins. Now, why it started to cause problems now and not before? I've no idea. – Arseni Mourzenko Feb 27 '11 at 23:28
  • @user520535: if it helped, you're free to accept or upvote the answer. – Arseni Mourzenko Mar 02 '11 at 13:59
2

If your main project using some library projects and have reference to them, you can cause this problem if your project reference to a assembly dll file instead to library project when you change something in your library project (ex: rename a class).

You can check all references to your main project by view in Object Browser window (menu View->Object Browser). A reference to a dll file always has a version number. Ex: TestLib [1.0.0.0]

Solution: delete the current reference of your main project to the library project and add reference to that library project again.

Huy Nguyen
  • 918
  • 1
  • 10
  • 11
2

I got the similar compiler error. Once I add the dependent project of the dll file to the solution, issue resolved.

Minny
  • 21
  • 1
1

After trying most of the solutions here, I finally just added a reference to the project from the click once project, this changed it to Include (Auto) from Include and it finally worked.

PatFromCanada
  • 2,738
  • 1
  • 27
  • 27
1

What helped me was I went onto Package Manager Solution and looked at the installed package which was causing the issue. I saw that several projects were referencing the same package but different versions. I aligned them based on my needs and it worked.

Artexias
  • 195
  • 2
  • 14
0

I had this in a solution w/ 6 projects. One of my projects was referring to the named assembly as a file reference. The others were all pointing to the project reference.

I usually get a different error in these cases.

My solution was to delete the named assembly anywhere it was referenced and add it back. Once I worked through the project, ths problem disappeared. Before doing this, I tried cleaning the solution as well as making sure none of the projects were signed.

hope it helps someone...

greg
  • 1,673
  • 1
  • 17
  • 30
0

If its a mismatch of a dependencies dependencies, go to the NuGet package manager at the solution level and check the Update and Consolidate tabs, harmonise it all.

Luke Puplett
  • 42,091
  • 47
  • 181
  • 266
0

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.

Simon Miller
  • 890
  • 7
  • 7
0

I also bump into kind of problem, all I just had to do is delete the .dll (can be found in reference) that causing the error and add it again.

Works like a charm.

FritsJ
  • 71
  • 2
  • 12
0

Try with update-package -reinstall -ignoredependencies

Stella Oliveira
  • 1
  • 1
0

Just go to Publish -> Application File -> And change the effected dll publish status from prerequisite to include! This worked for me!

SWIK
  • 714
  • 7
  • 12
0

In my case, I upgraded the project to .net 4.7.2 but still built in old visual studio version (2015). When i built the project in VS 2019, the build failure disappeared.

ayala
  • 331
  • 1
  • 9