mvvmlight
mvvmlight copied to clipboard
lbugnion
MVVM Light adds large number of system assemblies to the installer
When targeting .NET 4.5 or later, adding MVVM Light to my WPF project injects a large number of system assemblies to the application folder upon installation.
Here's how to produce this:
- Create a new WPF Application project, targeting .NET 4.5 or above.
- Add NuGet reference to MVVM Light (or the Lib-only version; doesn't matter).
- Add an MSI Setup project to the solution (extension needs to be installed beforehand).
- Add Primary Project Output of WPF application to the setup project.
There you go. A long list of System.X.Y will be added to the list. If you build and install the setup project, you'll see all these DLLs in Program Files folder.
The problem does not appear if WPF application targets .NET Framework 4.0 and you add NuGet reference AFTER that. But if you target .NET 4.5, 4.5.1 or 4.6, the long list of dependencies appears again. Think MVVM Light (or NuGet) is having trouble finding the correct package sub-folder.
Having the same problem - boosts the size of the installer package quite drastically !!
check the "Copy Local" property on the references. It should be False - if True then it will copy that file into the output and use that instead of the system copy of the file.
@CADbloke Which references are you talking about? BCL Assemblies or MVVMLight assemblies? If you're referring to BCL assemblies, know that the assemblies copied to the setup project are NOT even referenced in the project; they still somehow get their way to the installer. If you're talking about MVVMLight assemblies, I don't think I have the liberty NOT to copy them locally. Where would it find them then?
The Assemblies are automatically picked up as Detected Dependencies in the Installer. They are not referenced in the Application. Referencing MVVMLight in the App creates these Detected Dependencies, bloating the Installer!
oh. Darn. I was hoping it was something obvious & easy. But, alas, no, it rarely ever is.
Does the new version (5.4.1) do anything regarding this issue, so that I consider upgrading?
Hi, this is a relatively new issue and was not on the backlog. Since releasing the net standard version was critical, I decided to postpone looking into this particular issue. I will do my best to check what's happening here asap. Change log is always at http://mvvmlight.net/installing/changes
Just tried this again with 5.4.1. Still the same issue :(
New clean WPF Project targetting .Net 4.6.2. Added an Setup Project, and included the Primary Output from the WPF Project. Installer automatically detects no dependencies, which is correct.
Added MVVMLightLibs 5.4.1 with Nuget and the Setup Project now has 65 Detected Dependencies - apart from the 3 Galasoft ones, most of them are System.* assemblies - many duplicated (System.Collections x 2, System.Diagnostic.Debug x 2, System.Globalisation x 2 etc, etc).
Does exactly the same when installing the Libs, the StandardLibs or the full package.
Thanks for trying and reporting again. This is very annoying. I think this is new, correct? At first I thought the culprit was CommonServiceLocator, but if it does the same with StandardLibs, which doesn't have this reference... I'll ping the .NET guys to ask them if they know what's going on. Unfortunately they are not always very responsive (love you guys, but it's true...)
Thanks Laurent,
Be good to get to the bottom of it. Not sure how 'new' the issue is.
Just tested with a fresh project. If I Nuget MVVMLightLibs 4.4.43.7, the Detected Dependencies of the Installer project behave themselves (2 x Galasoft, Microsoft.Practices.ServiceLocation, System.Windows.Interactivity)
If I update to MvvmLightLibs 5.0.1, the Detected Dependencies immediately jumps to an extra 60+ dependencies.
Not seen any updates as yet. I really like the MVVMLight framework, but the bloat it's causing to my setup projects is really annoying!
Still looking forward to a solution. Too many of my projects depend upon MVVM Light and MSI installer. You said you were going to contact MS guys on this. Did you ever hear back from them?
This issue is indeed with Microsoft. It is highlighted here - https://stackoverflow.com/questions/48060230/system-reference-troubles-when-introducing-netstandard-library-dependency
