2

I created a setup project using Microsoft Visual Studio Installer Projects (0.9.3, this is latest for Visual Studio 2019). After setup is executed it installs Nuget package assemblies that are different from the assemblies generated during build.

Why is it doing that and how can I make it to chose assemblies consistent with build assemblies?

My application is for 4.7.2 framework. Typical example is System.ValueTuple.dll (4.0.2)

Build retrieves assembly from: C:\Users\.nuget\packages\system.valuetuple\4.5.0\lib\net47\System.ValueTuple.dll

Install retrieves assembly from: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.7.2\Facades\System.ValueTuple.dll

While install based on 4.0.2 creates a concern but works, when I upgrade nuget package to version 4.6 (and assembly to 4.0.3) install switches to using assembly C:\Users\vgdev.nuget\packages\system.valuetuple\4.5.0\ref\net47\System.ValueTuple.dll

If you look closer, you will notice path above has \ref folder and it contains "reference" assembly. Reference assemblies are not meant to be installed and cause errors BadImageformatException.

The build after Nuget package upgrade continues to pull packages from the correct \lib folder and application works fine. So what I want to do is to make installer work consistently with build. Any advice?

ben92
  • 80
  • 8
  • Microsoft might seem to ship that functionality for years, but actually it is dead already, https://devblogs.microsoft.com/buckh/visual-studio-setup-projects-vdproj-will-not-ship-with-future-versions-of-vs/ Don't use something never updated since 2015 and bother yourself. – Lex Li Nov 05 '19 at 18:40

2 Answers2

4

Install retrieves assembly from: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.7.2\Facades\System.ValueTuple.dll

Which way do you reference that package? I can only reproduce this issue when I add reference manually.(Right-click project=>Add reference=>Browse...) If you're doing so, please remove that reference, and add that reference back by Nuget Package Manager UI.

My application is for 4.7.2 framework. Typical example is System.ValueTuple.dll (4.0.2). When I upgrade nuget package to version 4.6 (and assembly to 4.0.3)

I can only find it with latest 4.5.0 here. And I think it contains the assembly version 4.0.3 instead of 4.0.2.

(I guess something corrupts the process when VS recognize your assembly version cause in most machines it displays 4.0.3 while in one machine, it displays 4.0.2, quite strange...)

The build after Nuget package upgrade continues to pull packages from the correct \lib folder and application works fine. So what I want to do is to make installer work consistently with build. Any advice?

Cause of the issue:

This strange behavior may have something to do with Setup project. I can reproduce same situation and I found this issue only occurs when I use PackageReference format to manage nuget packages in my application.(.net 4.7.2)

PackageReference format is the new nuget package manage format after VS2017. I'm not sure if the Setup project fully support for it.

Here're two suggestions which may help:

1.I found this issue only occurs when using PackageReference format. So you can try using Packages.config format in your application. And I've checked the setup project can recognize this format well.

Uninstall all PackageReference format packages, and go Tools=>Nuget Packages Manager=>Nuget Package Manager to set the Allow format selection... to true.

Clean all nuget cache and click ok. After that delete bin and obj folders, then restart VS to add those packages back using Packages.config format.

2.If you continue to use PackageReference format. Try excluding the assembly from ref folder, and manually add that from lib folder by Add=>Assembly=>Browse.

enter image description here

Note: Since Setup project may not fully support packageReference format projects, actually I think #1 could be more suitable for your situation. And you can create a new simple project with packages.config format to check if the issue can be resolved by Packages.config format. Hope it helps :)

LoLance
  • 25,666
  • 1
  • 39
  • 73
  • 1. I reference System.ValueTuple indirectly by installing Microsoft.Extensions.Configuration.Json. Version 3.0.0 if former depends on System.Text.JSon and hat one pulls System.ValueTuple. 2. System.ValueTyple is 4.5 at this point, not 4.6. – ben92 Nov 07 '19 at 01:44
  • 1
    I concur that this appears to be a PackageReference issue, as switching to packages.config does indeed solve the problem. It is a legit workaround. Unfortunately, this solution has a big downside to me: about 10 PackageReference packages turn into 64 in packages.config. It's a lot of maintenance :(. – ben92 Nov 07 '19 at 01:48
  • 1
    Regarding proposal #2. Adding assemblies from nuget global cache has clear risk: there is no automated process that would check that all dependent assemblies are of correct versions. Upgrade a few assemblies and then you have to go through the list verifying that all files in deployment match, – ben92 Nov 07 '19 at 01:53
  • 1
    Agree with that, i think the Installer project template doesn't have the full support for packageReference format, as **Lex Li** commented, the installer project is a bit old though it now supports extensions for VS2017 and VS2019. (But I think it may not fully support the new sdk format and packageReference). You can see similiar situation [here](https://stackoverflow.com/questions/58601200/my-visual-studio-2019-wpf-app-is-setting-a-dll-as-the-output-when-it-should-be-a). – LoLance Nov 07 '19 at 01:57
  • 1
    @ben92 Actually #1 and #2 are workarounds. And I prefer to use #1 though it will add many lines in `packages.config`, it's obvious the Installer project template(popular before VS2017) can recognize the old packages.config(the only format before VS2017) . As for the issue that sometimes Installer project can't recognize packageReference well, I suggest you contact the team which supports this extension [here](https://marketplace.visualstudio.com/items?itemName=VisualStudioClient.MicrosoftVisualStudio2017InstallerProjects&ssr=false#qna). – LoLance Nov 07 '19 at 02:04
  • Lance, I did accept your answer which appears to be the best choice under the circumstances. I would even give you two votes as I re-posted the question on the extension Q&As (thank you again!). Regretfully, my vote did not count because I am low on reputation. But let me tell you that I really do appreciate the time you put into this! PS Perhaps, you can up vote my question: I would eventually get enough points to up vote your answer! – ben92 Nov 07 '19 at 04:33
  • One has to have at least 15 score! – ben92 Nov 07 '19 at 15:25
  • I can accept it, you are right! I just need to wait 48 hours first. – ben92 Nov 07 '19 at 22:07
0

It seems that the root cause of the problem is the usage of the BuiltProjectOutputGroupDependencies target by visual studio setup projects instead of the ReferenceCopyLocalPathsOutputGroup target (see PackageReferences put ref instead of lib assemblies in the output group used by VS installer projects).

The proposed workaround is to overwrite the BuiltProjectOutputGroupDependencies target at the end in the project file of your main project:

<Target
Name="BuiltProjectOutputGroupDependencies"
DependsOnTargets="$(BuiltProjectOutputGroupDependenciesDependsOn)"
Returns="@(BuiltProjectOutputGroupDependency)">
<ItemGroup>
    <BuiltProjectOutputGroupDependency Include="@(ReferenceCopyLocalPaths->'%(FullPath)');
                                          @(ReferenceDependencyPaths->'%(FullPath)');
                                          @(NativeReferenceFile->'%(FullPath)');
                                          @(_DeploymentLooseManifestFile->'%(FullPath)');
                                          @(ResolvedIsolatedComModules->'%(FullPath)');
                                          @(ReferenceComWrappersToCopyLocal->'%(FullPath)')"/>
</ItemGroup>
</Target>
mbihler
  • 11
  • 2
  • From Review: Hi, while links are a great way of sharing knowledge, they won't really answer the question if they get broken in the future. Add to your answer the essential content of the link which answers the question. In case the content is too complex or too big to fit here, describe the general idea of the proposed solution. Remember to always keep a link reference to the original solution's website. See: [How do I write a good answer?](https://stackoverflow.com/help/how-to-answer) – sɐunıɔןɐqɐp Feb 12 '21 at 10:21
  • I believe I tried this code and setup still was not pickup up references. Have you tried it yourself? – ben92 Mar 09 '21 at 16:50
  • @ben92 The manipulation of the main project file helped in my case. Had the same problem like you: The setup project was picking the wrong assemblies (ref instead of lib assemblies). – mbihler Mar 09 '21 at 20:51