Why am I getting 'Assembly '*.dll' must be strong signed in order to be marked as a prerequisite.'?

后端 未结 27 662
隐瞒了意图╮
隐瞒了意图╮ 2021-01-29 20:28

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 th

相关标签:
27条回答
  • 2021-01-29 20:47

    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.

    0 讨论(0)
  • 2021-01-29 20:48

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

    Build-->Rebuild Solution

    0 讨论(0)
  • 2021-01-29 20:49

    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.
    0 讨论(0)
  • 2021-01-29 20:50

    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".

    0 讨论(0)
  • 2021-01-29 20:51

    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.

    0 讨论(0)
  • 2021-01-29 20:53

    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.

    0 讨论(0)
提交回复
热议问题