If you run Visual Studio 2005 Extensions for Windows Workflow Foundation setup from a folder that already contains a setup.exe, your old setup.exe may run giving you the illusion of installing the WWF extensions. When you open up a WF project in Visual Studio 2005, you may receive an error message stating “Project type is not supported by this installation”. To correct this problem, run the extensions setup from a folder without any other executable (or at least without any setup.exe files).
Last week Microsoft officially released .NET Framework 3.0. .NET Framework 3.0 is the latest managed code programming model for Windows. It combines the power of the .NET Framework version 2.0 with new technologies for building applications that have visually compelling user experiences, seamless communication across technology boundaries, and the ability to support a wide range of business processes. These new technologies are Windows Presentation Foundation, Windows Communication Foundation, Windows Workflow Foundation, and Windows CardSpace.
The .NET Framework 3.0 is included as part of the Windows Vista operating system. If you are using Windows XP or Windows 2003, you can download the latest framework from Microsoft at:
Microsoft recently released v1.4 of SyncToy with Windows Vista compatibility. SyncToy is an intuitive GUI tool for synchronizing files between folders and devices that can be downloaded from Microsoft for free. It can be used on Windows Vista or Windows XP, and the latest version requires .NET Framework 2.0 to be installed. In addition to Vista compatibility, Version 1.4 of SyncToy fixes some bugs and updates some documentation from the previous version 1.2 that was released back in March.
There are some other tools that allow file synchronization, e.g. AllWay Sync which works beautifully, and my favorite command-line tool called Robocopy, which is part of the Windows 2003 Server Resource Kit. Both of these programs are also free, and are part of my essential tools list.
Up until Visual Studio 2005 and .NET Framework 2.0, the actual build process of solution or project files was pretty much a black-box phenomenon for developers. With .NET Framework 2.0 and Visual Studio 2005, Microsoft unveiled its new build platform called MSBuild. MSBuild essentially provides a transparent build process through Visual Studio IDE, as well as allows developers to build projects and solutions from the command line. This allows us to fully customize our builds and create builds on machines where Visual Studio is not even installed.
On a recent team project I was using continuous integration or CI (an Agile practice) via CruiseControl.NET. It was a breeze to automatically build projects and solutions using MSBuild on our build server (a run-of-the-mill Dell workstation running Windows XP without Visual Studio 2005 installed) whenever someone checked-in any files to source control. This allowed us to be confident at all times that various pieces our distributed project integrate well. Moreover, since MSBuild can build projects and solutions from command line, I had some batch files setup that would build release versions of our projects, create setup files (using NSIS), archive older versions of setup files, and move new setup files to a network share where MIS / Operations folks could install the new version on the production server from.
In Visual Studio 2005, project and solution files are nothing more than MSBuild XML build scripts. This allows us full control over the build process. For example, in a web project, Visual Studio 2005 does not provide any user interface to modify pre and post build actions. However, since solution file is simply an MSBuild script, we can modify such actions manually by opening up the solution file in any text/XML editor.
MSBuild can perform several key tasks out of the box. Each task is essentially a unit of work (UOW) that contributes to the entire build process, e.g. copy files and folders, compile files, etc. If we ever require tasks that do not ship with MSBuild, we can always create custom tasks in any .NET language by simply implementing the ITask interface or deriving from the Task class.
In conclusion, MSBuild allows developers full control of the build process so that builds can be fully customized. This may not be so crucial in smaller projects, but for enterprise solutions that typically comprise of several projects and many dependencies, MSBuild is definitely a God-send!
