ResolveAssemblyReferences does not work with PackageReference

Daniel-Svensson commented 6 years ago

I've been trying to update som of our existing projects to use the new PackageReference format to include nuget packages. One of them is a WPF application using ClickOnce. We been able to use workarounds found to make all project compile and run with the exception of projects with clickonce enabled.

The problem seems to be that libraries coming from nuget packages are marked included as "Prerequisite (auto)" in ClickOnce instead of "Include (auto)" which is problematic.

This prevents them from beeing automatically included in the clickonce manifest
This makes build fail when referencing libraries which are not strongly signed

Others seems to have this issue: I found this https://stackoverflow.com/questions/46736788/clickonce-application-with-packagereferences-auto-to-prerequisites which seems to concern the same issue.

This has previously been reported at https://github.com/NuGet/Home/issues/6116 but was closed since it was the wrong repository.

If might be possible to work around by checking the "ReferenceCopyLocalPaths" or "_ReferencesFromNuGetPackages" and mark instead of just checking the Private Flag.

It seems the Target ResolveNuGetPackageAssets is the origin of the References with Private=true which causes ResolveAssemblyReferences to fail. See https://github.com/NuGet/NuGet.BuildTasks/blob/1d8af3499f94a32c1d128a42faceade39c1f4337/src/Microsoft.NuGet.Build.Tasks/ResolveNuGetPackageAssets.cs#L791

Steps to reproduce

In VS 2017 (15.4 or earlier) build the "HttpClient.sln" solution found att https://github.com/Daniel-Svensson/OpenRiaPlayground/tree/feature/clickonce_repro/HttpClient

Build log is availible at https://github.com/Daniel-Svensson/OpenRiaPlayground/raw/feature/clickonce_repro/HttpClient/clickonce_failure.buildlog

Expected behavior

The solution should build successfully
The manifest file should include all nuget references as installd

Actual behavior

Nuget references are market as Prerequisite

C:\Users\crmdas\.nuget\packages\openriaservices.client.core\4.5.0\lib\net45\OpenRiaServices.DomainServices.Client.Web.dll
    AssemblyType = Managed
    CopyLocal = false
    DependencyType = Prerequisite
    FusionName = OpenRiaServices.DomainServices.Client.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null
    ImageRuntime = v4.0.30319
    IsPrimary = true
    NuGetIsFrameworkReference = false
    NuGetPackageId = OpenRiaServices.Client.Core
    NuGetPackageVersion = 4.5.0
    NuGetSourceType = Package
    OriginalItemSpec = C:\Users\crmdas\.nuget\packages\openriaservices.client.core\4.5.0\lib\net45\OpenRiaServices.DomainServices.Client.Web.dll
    Private = false
    ReferenceAssembly = C:\Users\crmdas\.nuget\packages\openriaservices.client.core\4.5.0\lib\net45\OpenRiaServices.DomainServices.Client.Web.dll
    ReferenceSourceTarget = ResolveAssemblyReference
    ResolvedFrom = {RawFileName}
    Version = 4.0.0.0

Build fails if reference is not strong named

Errors
    C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(3743,5): error MSB3188: Assembly 'C:\Users\crmdas\.nuget\packages\openriaservices.client.core\4.5.0\lib\net45\OpenRiaServices.DomainServices.Client.Web.dll' must be strong signed in order to be marked as a prerequisite. [C:\Dev\github\Daniel-Svensson\OpenRiaPlayground\HttpClient\WpfClient\WpfClient.csproj]
    C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(3743,5): error MSB3188: Assembly 'C:\Users\crmdas\.nuget\packages\openriaservices.client.core\4.5.0\lib\net45\OpenRiaServices.DomainServices.Client.dll' must be strong signed in order to be marked as a prerequisite. [C:\Dev\github\Daniel-Svensson\OpenRiaPlayground\HttpClient\WpfClient\WpfClient.csproj]

Environment data

Visual Studio 2017 15.4+

Daniel-Svensson commented 6 years ago

If the ResolveAssemblyReference task is updated it should probably be straight forward to fix #3057 at the same time

ddotlic commented 5 years ago

@Daniel-Svensson Do you know if there's any workaround for this? I've seen some anecdotal evidence that this has been fixed in 15.8, but it hasn't: I'm running 15.8.4, have an Excel Add-in project using ClickOnce and have the exact same problem as above. The problem disappears if I revert back to packages.config.

Daniel-Svensson commented 5 years ago

@ddotlic most issues are resolved for me. We had some new issues which required workarounds but from the release notes it looks that the recently released15.8.5 might resolve them.

ddotlic commented 5 years ago

@Daniel-Svensson where recently means today 😉 was waiting for it to come out, will verify if it solves the issue, thanks!

ddotlic commented 5 years ago

@Daniel-Svensson Well, shiiiit. This does not work for an Excel Add-In project deployed through ClickOnce. Build still fails with the (in)famous Assembly <...> must be strong signed in order to be marked as prerequisite.

Daniel-Svensson commented 5 years ago

I suggest you use the send feedback feature from within vs 2017 and report the bug with a repro. We reported one of the issues resolved in 15.8.5 when 15.8.1 had just been released so it did not take that much time.

As to find a workaround I used the structured msbuild log viewer and looked at the different output and input to the ResolveAssemblyReferences task

ddotlic commented 5 years ago

@Daniel-Svensson thanks for both suggestions, I will definitely put them to good use. I was just disappointed because it looked like “my” issue was resolved in 15.8.5 when in fact 4 similar issues were... cheers!

Aurelianus commented 5 years ago

I've got the same issues with my excel vsto addin containing netstandard20 project references.

You've got two options

using NuGet PackageManagement via PackageReference and running into Assembly <...> must be strong signed in order to be marked as prerequisite.`` Workaround [https://stackoverflow.com/a/51803308/727183] killing your ClickOnce
using packages.config and miss nuget packages referenced by netstandard dependency in your output (probably issue #https://github.com/dotnet/standard/issues/529).

Visual Studio 15.8.8, Excel Addin netframework 4.7.2

My Workaround - switch all project references to net472 - no issues

ddotlic commented 5 years ago

My Workaround - switch all project references to net472 - no issues

@Aurelianus That's very useful info - I thought I tried that but maybe I didn't (almost by accident, my project is targeting 4.7.1 but no real reason for it). I've opened up an issue for Visual Studio which is currently being "Triaged" (for weeks); I assume that we're relatively few encountering this so low priority.

ddotlic commented 5 years ago

My Workaround - switch all project references to net472 - no issues

@Aurelianus What do you mean by "all project references" - I can only influence my projects and they are set to 4.7.2.

I cannot choose which framework has been chosen by the 3rd party NuGet packages... IOW, am still unable to make this work (sigh).

Aurelianus commented 5 years ago

@ddotlic i mean that all subprojects referenced by have been reset to net472 targetframework. Thus i have no netstandard projects. The problem is not related to PackagesReferences (nuget packages) thus you shouldn't notice these.

ddotlic commented 5 years ago

@Aurelianus I don't see how you can "guarantee" that the referenced projects will use net472 (unless all projects are under your control).

While I can - and have - used net472 when referencing them, all of the problematic ones resolve to net46, net471 and whatnot (whatever was provided by the author of the library).

IOW, there's no issue with netstandard, we're squarely in the land of the full .NET framework.

Aurelianus commented 5 years ago

In my case I've got a big solution with most of the subprojects under my control. If your foreign libs cause the issue you can probably add another compilation target (if they are open source).

ddotlic commented 5 years ago

@Aurelianus yeah, I could provide PRs for the affected packages but it’s silly - it inflates package size for no other benefit apart from mine 😞 so they’d rightfully refuse. The issue really ought to get fixed...

filmor commented 4 years ago

The Visual Studio issue on this was closed because it didn't get enough attention in form of comments and votes...

rrelyea commented 4 years ago

Feedback issue: AB#690368 & DTS issue: AB#1048917 are likely related to this core issue. This stack overflow info may also be relevant: https://stackoverflow.com/questions/46736788/clickonce-application-with-packagereferences-auto-to-prerequisites

Welchen commented 4 years ago

Ran into this issue just now myself. Was updating my VSTO projects and now they don't work after being published.

Forgind commented 4 years ago

I think the fix @sujitnayak made for AB#1052258 will solve this. That will ship with 16.6 preview 3, so if you're still seeing this problem after that, let me know.

Forgind commented 4 years ago

Closing, assuming this is resolved.

sujitnayak commented 4 years ago

As mentioned, the fix to support PackageReferences in VSTO Addin projects in available in the preview channel - Visual Studio 2019 16.6 Preview 3.

dotnet / msbuild