Why MVVM Light copies system assemblies to application folder?

Question

Adding MVVM Light reference to a WPF projects adds a large number of system assemblies to the list of dependencies in the accompanying MSI Setup project. These assemblies (50+ in number) are then copied to the application folder when the app is installed. Why is it so? Why can't it reference it from GAC directly?

Note: Copy Local option is set to True for MVVMLight.dll. I obviously can't set it to False.

Reproducing it is extremely simple. I'm using VS2015 Community.

1. Create a new WPF Application project.
2. Add NuGet reference to MVVM Light (or the Lib-only version; doesn't matter).
3. Add an MSI Setup project to the solution (must have the extension installed).
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.

Why? And how to fix it?

Update

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.

Trunk

I have an app targeting 4.5 and Galasoft.MVVMLight adds me about 4-5 dlls. How do you add it to the project? – Hendecagon

@BudaFlorin: Directly through nuget. Nothing special. I'm using VS2015 Community just in case. Also note that this happens only in the setup project (MSI), not the bin directory of the main project itself. – Trunk

I'll appreciate if anyone could just confirm they can reproduce it. – Trunk

Answer 1

I don't know why it happens but I can offer a workaround. Just open the project's Detected Dependencies folder, select all of the System dlls, right-click and select Exclude.

Peony

Thanks for the input. This will probably be the last thing I'll do after all else fails. Part of my unwillingness to use this approach is that it might fail to find appropriate assemblies in the GAC on user's machine just like it is failing to target them on the dev machine. – Trunk

been there done that... you commit the files to source control and run it through a CI/CD pipeline and suddenly it'll randomly detect all kinds of other stuff and include it again because you didn't exclude THOSE files... trust me.. not worth the effort and full of risk. – Cardsharp

Answer 2

Overly agressive dependency scanning is one of the many reasons I don't use Visual Studio Deployment Projects. Instead I use WiX / IsWiX. Both open source and the later written by myself.

For more information see:

http://www.github.com/iswix-llc/iswix-tutorials

Cardsharp