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.
Create a new WPF Application project.
Add NuGet reference to MVVM Light (or the Lib-only version; doesn't matter).
Add an MSI Setup project to the solution (must have the extension installed).
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.
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.
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
Related
Attempting to create nuget package to upload to our own nuget sever, and would like to eliminate the manual process of creating and editing the nugspec file. Everything I've read, says the setting can be pulled from the project file (if using package reference). And that the settings exist on the Package tab of the project properties window. But that tab is not there.
Using vs 2019, .NetFramework 4.7.2, project is a library, and has been migrated to package reference.
I took an existing project, right clicked the references, and used the migrate option. Package tab is non-existent
I also set the nuget package manager to default to packageReference, and create a new class library.
Package tab also non-existent
The required package (when using non-SDK Style with package reference) nuget.build.tasks.pack has bee added to the references of both projects mentions
Any help would be appreciated
The package tab is only available for SDK style projects. Non-SDK style projects use a different project system in Visual Studio, which doesn't contain that project properties tab. The new project system (on github, the old one is closed source) was initially made to look the same as the old project system, but slowly they're diverging. The Reference/Dependencies node in Solution Explorer is one obvious example, as is the Package tab in the project properties window.
To create the MSBuild properties used by pack, you'll need to manually edit the project file as XML. Within Visual Studio, you need to right click the project in Solution Explorer, select "unload project", now when you single click the project, or right click and select edit, you'll see the project XML. Once done, right click the project again and select reload project. Alternatively, edit it with a text or XML editor outside of Visual Studio, and Visual Studio will detect the change and prompt you to reload the project when you alt-tab back.
My suggestion, however, is to convert your non-SDK style project to an SDK style project. "Standard" class library projects work fine, and I'm not aware of any disadvantages (unless some developers on your team are using Visual Studio 2015 or earlier still), given the non-SDK style project is already using PackageReference. Some other project types might have limited Visual Studio experiences when targeting .NET Framework in an SDK style project. Other project types might not be compatible with SDK style projects at all. However, most people creating NuGet packages are doing so with standard class library projects, which shouldn't have any problems.
There is a "unsupported" tool try-convert to convert non-SDK style projects to SDK style. Personally, I just delete the csproj, create an empty directory, run dotnet new classlib on the console, move the csproj to my existing project's directory, rename the project file, and delete that temporary/empty directory. If you have anything other than .cs files in your project that need explicit entries in the csproj, hand edit the csproj if you're comfortable with msbuild, otherwise load the project in Visual Studio and use the Solution Explorer and Properties windows.
Some people believe that SDK style projects are only for .NET Core or .NET Standard. That's not true, but unfortunately the Visual Studio new project templates give that impression. You will need to create the class library project targeting .NET 5, .NET Standard, or .NET Core. But once the csproj is created, edit the csproj (with SDK style projects it's no longer necessary to unload the project) and change <TargetFramework>net5.0</TargetFramework> to <TargetFramework>net472</TargetFramework>. Another advantage of SDK style projects is it's easy to multi-target, a useful technique to slowly modernize your projects to newer runtimes. Add an s to the XML element name to make it plural, and add extra target frameworks as a semi-colon delimited list <TargetFrameworks>net472;net5.0</TargetFrameworks>. When changing between TargetFramework and TargetFrameworks, Visual Studio should prompt you to reload the project, but I found that it still has some issues. So I suggest closing the solution and opening it again, then everything should work great.
When I create a clickonce deploy of a wpf application many microsft dll's are missing in the deployment.
f.e. system.dll, system.data.dll, system.reactive.core.dll, system.xaml.dll, ...
Any suggestions ?
Since you still need to install the .NET Framework on the computer on which you want to install the ClickOnce application, it doesn't make much sense to include these assemblies in the deployment. They should be available in the GAC anyway.
You can include any other assemblies - including the system.reactive.* ones - by including them under Project->Properties->Publish->Application Files... in Visual Studio before you publish.
If you set the Copy Local property of these assembluies to True in the Solution Explorer, they should be included by default.
Note that if these assemblies are referenced from another project than the one you publish, you should copy the references to the WPF application project that you publish. If they are part of a NuGet package you should also add that NuGet package to the project being published.
I am authoring a management pack with custom views using Silverlight / WPF (shared code) and MP authoring console and MP authoring tool in Visual Studio.
I am following this tutorial on custom views.
Widget for SCOM operation and web console - custom
In Section 4.1: It mentions: Add a reference to Microsoft.EnterpriseManagement.CompositionEngine and Microsoft.EnterpriseManagement.Presentation.Core assemblies. These can typically be found in the Console folder of the Operations Manager installation. Attention: the assemblies from the RTM/CU1 installation will not work! You need to download the sample project files and use the included assemblies.
I cannot add references to the Silverlight project. I get an error message:
Is there any way to get around this?
I understand that the .net runtime is different than that of Silverlight. Yet, this tutorial shows a working example, so it there a missing step or a different binary. What am I missing?
In Section 4.1: It mentions: Add a reference to Microsoft.EnterpriseManagement.CompositionEngine and Microsoft.EnterpriseManagement.Presentation.Core assemblies. These can typically be found in the Console folder of the Operations Manager installation. Attention: the assemblies from the RTM/CU1 installation will not work! You need to download the sample project files and use the included assemblies.
The important bit is the bit in bold, you need to download the sample project and copy the references from there. Were you doing this?
http://gallery.technet.microsoft.com/Creating-a-Widget-for-104711ac
If you download this zip and go to the following sub directory
\Creating a Widget for Operations Manager Dashboard - Walkthrough %231.zip\Creating a Widget for Operations Manager Dashboard - Walkthrough #1\Section_4\AlertSummarySilverlight\Bin\Debug
You'll see the two assemblies in this folder. Copying them out of the zip into another folder and add a reference to them. This works for me in Silverlight 5.
We have a Silverlight 5 project and we currently have a folder of shared library DLL's. We are in the process of changing to use NuGet for these libraries wherever possible.
One of the NuGet packages we want to use is MVVMLight, to replace the MVVM Light SL4 DLL's we are currently using, which were never upgraded when we moved from SL4 to SL5.
However, when we installed the NuGet package containing the SL5 DLL's it automatically changed our existing references to the Microsoft.Practices.ServiceLocation DLL file to one which came with the MVVM Light package, which has the same version number, but a different public key.
This has caused a conflict with some of our other code which is using the Prism library, which uses the Microsoft.Practices.ServiceLocation DLL, but, signed with the original public key.
Obviously we cannot use the same named DLL twice in the same folder, so, any suggestion on how to resolve this issue, whilst keeping both Prism and MVVM Light packages installed from NuGet.
Thanks very much,
Martyn.
I have exactly the same problem with Microsoft.Practices.ServiceLocation.dll. In my case, this could be resolve if the nuget package of MvvmLight was dependent of CommonServiceLocator as I suggested here : http://mvvmlight.codeplex.com/discussions/429311
So far, no news about that.
Edit : Laurent just push a version of MVVM Light using the CommonServiceLocator from Nuget.
The Portable.CommonServiceLocator NuGet package contains the existing signed CSL binaries as well as the PCL one that supports windows 8, .net 4.5 and others. Still waiting on Microsoft to include the PCL in their official package, but the binaries are the same in the one I mentioned.
You can also try using Portable.MvvmLightLibs, which is a PCL version. That one supports all of the frameworks (WP7.5+, .NET 4.5, Store, SL4+) and uses the official Microsoft-signed CSL libraries.
I want to pack my file in to a single executable file "setup.exe", my application is written in c# and WPF, I know that there are a lot of applications out in the store for creating a installation pack, but the point is which one would help me to build my installation pack just like Devexpress dose ?
For an UI similar to DevExpress you will need a setup authoring tool which offers an external UI and rich graphics.
Advanced Installer and InstallShield have some great UI themes which can get you started. You can also find a list of setup tools here:
http://en.wikipedia.org/wiki/List_of_installation_software
You'll probably have to roll a custom solution for this one. I expect nothing less of the Devexpress team then creating their own installer.
If you're application is not heavily bound into the registry and all kind of windows folders it should not be that hard to create an application that extracts some files into a directory and create some great UI while copying.