search

lbugnion / mvvmlight

The main purpose of the toolkit is to accelerate the creation and development of MVVM applications in Xamarin.Android, Xamarin.iOS, Xamarin.Forms, Windows 10 UWP, Windows Presentation Foundation (WPF), Silverlight, Windows Phone.
http://www.mvvmlight.net
MIT License
1.16k stars 311 forks source link

MVVM Light adds large number of system assemblies to the installer #15

Open Shujee opened 6 years ago

Shujee commented 6 years ago

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:

  1. Create a new WPF Application project, targeting .NET 4.5 or above.
  2. Add NuGet reference to MVVM Light (or the Lib-only version; doesn't matter).
  3. Add an MSI Setup project to the solution (extension needs to be installed beforehand).
  4. 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.

Shujee commented 6 years ago

Did you get a chance to look into this?

ChrisStanyon commented 6 years ago

Having the same problem - boosts the size of the installer package quite drastically !!

CADbloke commented 6 years ago

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.

Shujee commented 6 years ago

@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?

ChrisStanyon commented 6 years ago

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!

CADbloke commented 6 years ago

oh. Darn. I was hoping it was something obvious & easy. But, alas, no, it rarely ever is.

Shujee commented 6 years ago

Does the new version (5.4.1) do anything regarding this issue, so that I consider upgrading?

lbugnion commented 6 years ago

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

ChrisStanyon commented 6 years ago

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.

lbugnion commented 6 years ago

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

ChrisStanyon commented 6 years ago

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.

abgenullt commented 6 years ago

Hi,

any updates here? I've got the same problem...

ChrisStanyon commented 6 years ago

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!

Shujee commented 6 years ago

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?

Ryan-EK commented 6 years ago

This issue is indeed with Microsoft. It is highlighted here - https://stackoverflow.com/questions/48060230/system-reference-troubles-when-introducing-netstandard-library-dependency