Building WPFToolkit from sources

Feb 15, 2010 at 4:45 PM
Edited Feb 16, 2010 at 1:51 PM

This may be helpful to others so I am posting it here.  These are the changes I needed to make to build the February 2010 release of the toolkit to completion.

(6) Rebuild again, you should have 0 errors and 0 warnings on all projects, ending up with

[ Steps ]

(1) Build everything first to identify projects with errors.

(2) Build result should be:

========== Build: 11 succeeded or up-to-date, 3 failed, 0 skipped ==========

(3) Correct Project -> Controls.DataVisualization.Toolkit.VisualStudio.Design

as follows:

Remove Reference -> Microsoft.Windows.Design.Extensibility

Add Reference -> Microsoft.Windows.Design.Extensibility

From -> C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies

(4) Correct Project -> Controls.Input.Toolkit.Design

as follows:

Remove Reference -> Microsoft.Windows.Design.Extensibility

Remove Reference -> Microsoft.Windows.Design.Interaction

Add Reference -> Microsoft.Windows.Design.Extensibility

Add Reference -> Microsoft.Windows.Design.Interaction

From -> C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies

(5) Correct Project -> Controls.Layout.Toolkit.Design

as follows:

Remove Reference -> Microsoft.Windows.Design.Extensibility

Remove Reference -> Microsoft.Windows.Design.Interaction

Add Reference -> Microsoft.Windows.Design.Extensibility

Add Reference -> Microsoft.Windows.Design.Interaction

From -> C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies

(6) Rebuild again, you should have 0 errors and 0 warnings on all projects, ending up with

========== Rebuild All: 14 succeeded, 0 failed, 0 skipped ==========

[ Comments ]
I changed my startup project to WPFToolkitSamples.  The samples are helpful, but seem to only incorporate examples for more recent enhancements rather than a general set of examples.  It would be nice to have an examples project that did full coverage of the toolkit.  As mentioned in other posts, having a change/issues log would be most helpful.  Especially given that we presently have to hunt around for breaking changes to get the requisite information (http://blogs.msdn.com/delay/default.aspx is the only place they appear to be posted).
This toolkit release does appear to be close to a production level version.  My impression is that the quality of the code base has firmed up nicely.
WPFToolkit needs its own equivalent of the Silverlight Gallery sample, incorporating themes and leveraging the enhanced capabilities of WPF, not just duplicating what the Silverlight equivalent provides.  This would go a long way to making it easy to sell WPF to clients, given the rich set of services provided by the latest incarnation of the toolkit.  It really does have some gems that dramatically speed up the development process if you leverage the provided code base.
Lastly, I hope Microsoft continues VS2008 support for the toolkit.  There has been a tendency to push new product releases onto developers by dropping support for earlier products.  Sometimes this is necessary to get us to move.  However, in this case, we've only really had SP1 and a couple the subsequent releases of supported tools to get our product development going.  Speaking only for myself, it will not be practical to switch to VS2010 for about a year.  Projects will be gradually moved over when the dust settles with 2010.  The "settling" period has become a reality of Microsoft product releases that is now incorporated into product development decisions.
It's no longer fun to be an early adopter.

 

Feb 16, 2010 at 2:02 PM

Despite the modified assembly references in changeset 39793 the build still fails in the same way as before without the above adjustments.  The assembly path now points to the Blend 3 installation directory, however these assemblies cause build errors.  On all of my client VS2008 installations, I have to make the above changes to resolve build problems even after installing Blend 3.

The above change seems more generic, since it does not require the installation of Blend.  Is there an issue with the assemblies used above?

If Blend is to be a requisite component of the build process, why not incorporate the required elements into the Blend SDK, so that we're not forced into installing all of Blend just to build the toolkit.  The Blend SDK makes much more sense as a dependency for the toolkit for a variety of reasons.