Why an MSI and what makes the solution hard to open?

Jan 16, 2014 at 10:16 PM
Edited Jan 16, 2014 at 10:31 PM
I noticed that the only download option is an MSI file. Why? Update Controls is just a bunch of DLLs, why do I have to "install" it? So I thought, that's okay, I'll build from source. But after getting the latest version, the main projects would no longer open in VS2010 Professional. I thought maybe it might require a later version so I tried to open the solution in VS2013 Express. It, too, wouldn't open the projects:

This version of Visual Studio is unable to open the following projects. The project types may not be installed or this version of Visual Studio may not support them.
For more information on enabling these project types or otherwise migrating your assets, please see the details in the "Migration Report" displayed after clicking OK.
 - UpdateControls, "C:\...\updatecontrols\Portable\UpdateControls\UpdateControls.csproj"
 - UpdateControls.Test, "C:\...\updatecontrols\Portable\UpdateControls.Test\UpdateControls.Test.csproj"
 - UpdateControls.XAML, "C:\...\updatecontrols\WindowsStore\UpdateControls.XAML\UpdateControls.XAML.csproj"
 - UpdateControls.Test.App, "C:\...\updatecontrols\WindowsStore\UpdateControls.Test.App\UpdateControls.Test.App.csproj"
 - UpdateControls.XAML, "C:\...\updatecontrols\Silverlight\UpdateControls.XAML\UpdateControls.XAML.csproj"
 - UpdateControls.XAML, "C:\...\updatecontrols\WindowsPhone\UpdateControls.XAML\UpdateControls.XAML.csproj"
I assume the "Migration Report" is UpgradeLog.htm but this has no meaningful information, because VS project types are identified by GUID, e.g. UpdateControls.csproj has two GUIDs, 786C830F-07A1-408B-BD7F-6EE04809D6DB and FAE04EC0-301F-11D3-BF4B-00C04F79EFBC. Thanks MS for this wonderful naming scheme. Google says... ahh. "Portable Library Project."

Okay so does this require "Portable Library Tools 2"? Can it still be built for .NET Framework 3.5 (as my main app still builds in VS2008)?
Jan 17, 2014 at 2:57 AM
Good questions. The short answer is that I've reorganized the code to take advantage of new platforms. For old platforms, use the old builds.

I used to release Update Controls as an MSI because it targeted Windows Forms. The MSI installed the controls into the toolbox, and created a Visual Studio command for creating independent properties.

It still works with Windows Forms, but without an MSI you have to manage the toolbox yourself.

Then I started focusing on XAML. And we added features like Independent<T> (that was yours, right?) and ViewModelBase that took away the need for a command. So the MSI became less important. Add to that the rise of NuGet as a distribution mechanism, and I stopped building MSIs altogether.

It was a good thing, too, since Visual Studio 2012 stopped supporting Setup and Deployment projects.

Now Portable Class Libraries have come along. With them, I can target WPF, Silverlight, Windows 8, Windows Phone, Android, and iOS (using Xamarin). And, I can hit all those platforms with one project, rather than linked source files. So I reorganized the solution to clean it up and put it on the path to continue forward.

The down side is that Update Controls Portable Class Library only targets .NET 4.5 and above. So if you want to target 3.5 or 4, you'll need to grab an earlier version.

Option 1

Download the MSI. I won't be building any new MSIs, so this is the pre-PCL version.

Option 2

Install an earlier version with NuGet:
Install-Package updatecontrols -Version
If you want to build the code in VS2010, just pull down an earlier changeset. I even moved the history over to GitHub so you can easily fork it and create a branch at any point you like.

Hope this helps.
Jan 17, 2014 at 6:06 PM
So when did the .NET 3.5 support disappear? The comment for Nov 25, 2012 says "Added portable class libraries" but there is no comment that says Desktop versions were removed.
Jan 17, 2014 at 6:19 PM
The last changeset to support 3.5 is 87721, Version That was almost a full year after originally adding PCL support.