0

I've seen several questions on this board which are similar, but I think several problems can cause this message, and my particular problem may not have been among them, and certainly my solution appears much simpler and more effective than any of the others.

I have a project which was using packages.config.

I used the Visual Studio UI to migrate by projects references from package.config to PackageReference (https://devblogs.microsoft.com/nuget/migrate-packages-config-to-package-reference/). I did this because it allows building with msbuild /t:restore mysln.sln - which doesn't work with packages.config.

I think this GENERALLY works (I tried 5 or 6 times on other projects). But on one project when I rebuilt, I got the error message:

c:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VisualStudio\v16.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets(236,9): error MSB3188: Assembly 'C:\Users\lew
is\.nuget\packages\mousekeyhook\5.6.0\lib\net40\Gma.System.MouseKeyHook.dll' must be strong signed in order to be marked as a prerequisite.
lewis
  • 1,116
  • 1
  • 12
  • 28

4 Answers4

2

The error message about demanded signed assemblies is usually shown in the following combinations:

  • The project can be published (such as a VSTO project).
  • The project uses PackageReferences for NuGet.
  • A referenced NuGet package is a netstandard2.0 package.

You could easily reproduce this by creating a new VSTO Word Add-In and reference NGenerics Version 1.5.3 via NuGet.

(Another reason could be version conflicts of the referenced assembly, say you reference assemblies A and B via NuGet, and A itself references a different version of B; then you would have to reference the same version of B as A does.)

With the help of a Microsoft Service call we found out that in such a scenario, the referenced assembly (in our case NGenerics v. 1.5.3) is marked as CopyLocal=false internally by the build process. If you use packages.config instead of PackageReferences for NuGet and mark the referenced assembly as CopyLocal=false in the Properties window, then you get the same compile error.

Solution: When using packages.config, set the assembly reference property of the affected assembly to CopyLocal=true. When using PackageReferences, edit the project file manually and add an assets option as in the following example:

    <PackageReference Include="NGenerics">
      <Version>1.5.3</Version>
      <ExcludeAssets>compile</ExcludeAssets>
    </PackageReference>

The name of the ExcludeAssets and IncludeAssets setting is misleading. ExcludeAssets is copying the mentioned items to the output, while IncludeAssets keeps them from going to the output directory. You could as well say <IncludeAssets>none</IncludeAssets>. See documentation at https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files

JSpot
  • 450
  • 4
  • 12
  • As it turns out, the NGenerics.dll will not be included in the manifest and thus not in the publish output when published. So deployment is still a problem here. – JSpot Jan 03 '20 at 10:44
  • As of now, Microsoft reports to us that support for PackageReference in VSTO projects ist neither supported nor planned. You could change that with a vote for this: [VSTO projects created in Visual Studio 2019 do not support Package Reference as the package management format.](https://developercommunity.visualstudio.com/content/problem/886124/vsto-projects-created-in-visual-studio-2019-do-not.html) – JSpot Jan 16 '20 at 10:48
1

My solution to this problem:

  • Squirrel away the Gma.System.MouseKeyHook.dll from the packages folder
  • Delete the reference to Gma.System.MouseKeyHook.dll from nuget
  • Add a folder called 'ThirdPartyComponents' and put Gma.System.MouseKeyHook.dll in there.
  • Create a REFERENCE (not PackageReference) using the 'Add Reference' command in Visual studio

DONE - error gone.

.CSPROJ DIFF FOR FIX:
index f0abf00..f87ab3e 100644
--- a/X.csproj
+++ b/X.csproj
@@ -123,6 +123,9 @@
   -->
   <ItemGroup>
     <Reference Include="Accessibility" />
+    <Reference Include="Gma.System.MouseKeyHook">
+      <HintPath>..\ThirdPartyComponents\Gma.System.MouseKeyHook.dll</HintPath>
+    </Reference>
     <Reference Include="Microsoft.Office.Interop.Excel, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL">
       <EmbedInteropTypes>True</EmbedInteropTypes>
     </Reference>
@@ -632,9 +635,6 @@
     <PackageReference Include="log4net">
       <Version>2.0.8</Version>
     </PackageReference>
-    <PackageReference Include="MouseKeyHook">
-      <Version>5.6.0</Version>
-    </PackageReference>
     <PackageReference Include="Newtonsoft.Json">
       <Version>12.0.3</Version>
     </PackageReference>

Apparently having a requires the signing stuff, but having a regular does not.

lewis
  • 1,116
  • 1
  • 12
  • 28
  • We have the same problem: VSTO project referencing NGenerics 1.5.3 via Nuget. With packages.config everything ist fine, but with PackageReferences, we get the error. Referencing the affected assemblies locally and un-Nuget-ting ist not a real solution. In our project we reference other projects which are already using PackageReferences. We would either have to put every DLL in a local folder and hold it in source control (ugh) or get back to packages.config and reference our own assemblies via a local nuget repository. – JSpot Dec 27 '19 at 09:00
  • We also have a maze of projects with references referencing other projects. And we've so far only had to do this in one place for this one DLL. Your mileage may vary and it would be nice if MSFT just fixed this problem (at least turning the error into an ignorable warning). But I've so far ONLY found this necessary on the use in the top level project (not the class library projects). Best of luck, and if you find a better solution, please let me know here ;-) – lewis Dec 28 '19 at 13:53
  • Lewis Pringle see my solution below! (Sorry, I got the user reference not working.) – JSpot Jan 02 '20 at 12:03
0

I leave my other answer as it is because it might help with other projects. However, for VSTO, the situation is according to a Microsoft Support Case we made:

  • PackageReferences is not supported for VSTO projects. You have to use packages.config
  • ClickOnce deployment for non-VSTO projects with PackageReferences works (reported by the Microsoft escalation engineer).

You could encourage support for PackageReferences by voting for: VSTO projects created in Visual Studio 2019 do not support Package Reference as the package management format

JSpot
  • 450
  • 4
  • 12
0

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

ayala
  • 331
  • 1
  • 9