This entry starts by looking at the new features in Windows Forms 2.0, and then proceeds to describe the migration strategy for existing Windows Forms 1.0 applications that are to be migrated to .NET Framework 2.0.
New Windows Forms Controls
We've added some new controls to Whidbey:
Other WinForms Improvements
Deployment Improvements
ClickOnce, a no-touch deployment and update mechanism for rich client applications. You can create a ClickOnce application through the Publish Wizard, which publishes an application to a URL. You can choose whether the application is available in online/offline modes or only whilst online. This has nothing to do with the functionality of the application, but it allows you to choose whether the shortcut to the application is in the start menu or as a URL. Publish Wizard allows you to sign the deployment manifest with a key, so that only the application publisher can make modifications to the application. The wizard copies all the files and the deployment manifest to a location (typically a URL). By default applications are set up to require full trust, but you can modify them to use a lower trust model. If necessary, the application prompts users for permissions to install the application if it requires a higher level of trust than would otherwise be granted to it.
Designer Features
Migration
The good news is that you can take any WinForms 1.x application and use it unchanged in the Whidbey environment using the existing controls. When you open a WinForms 1.x solution in Visual Studio 2005, the Visual Studio Conversion Wizard will kick in and offer to convert the project and solution files across to the new format, but it will leave the code completely intact. The old controls still exist, but are deprecated: for practical purposes, that means that they are not visible from the toolbox, but are available.
The bad news is that if you want to migrate a WinForms 1.x application to utilise 2.0 functionality today, you'll have to do a little work by hand. There are some controls that are fairly easy to upgrade (e.g. StatusBar -> StatusStrip), but others that are much harder (e.g. DataGrid -> GridView). One approach to see the changes between the controls is to compare the output from the designer tools. For example, toolbar separators are treated as a special kind of button in the ToolBar control, but exist in their own right as separate controls in the ToolStrip. These minor changes should be fairly easy to fix with search and replace or a sed-style script, however.
A Comparison of Old and New Controls
One thing to bear in mind is that the DataGridView does not include support for hierarchical tables, something the old DataGrid was good at doing.
Office Information Bridge Framework (IBF) is a new solution that provides a standardised way for developers to integrate a company data-centric application into Office. IBF includes a means of specifying business entities and relationships between those entities, providing methods to retrieve the data, and creating a task pane for Office that provides a user interface for the functionality. For example, if you have a company HR system, you could use IBF to allow users to retrieve information from that system into a spreadsheet or Word document. IBF is a free download for anyone with an Office 2003 Professional Edition licence, from the following location:
The architecture of an Information Bridge Framework solution:
In IBF, you specify classes representing the business entities (customer, customers collection, order, orders collection), with appropriate attributes to control XML serialisation (e.g. [XmlRoot("Customer"), Namespace="urn-Northwind")]. You then provide GetX methods that retrieve a specific entity based on some known criteria (e.g. GetOrdersByOrderID). From Visual Studio, you can add entities to an Information Bridge Framework solution and map them to the underlying method calls for populating the information. Lastly, you can create a user interface that exposes the information and enables users to search for data based on some criteria.
For more information, check out the technical white paper on MSDN.
MSBuild is the new build system in Visual Studio 2005. It has been built from the ground up in managed code, with scalability, performance and extensibility as core goals.
When designing MSBuild, the development team had several different customer audiences that they kept in mind:
MSBuild is actually built into the operating system, rather than the development environment. This means you can build Visual Studio projects without VS installed; all you need is Windows (and .NET Framework 2.0 until Longhorn).
MSBuild is driven by project files, which are created either by Visual Studio (automatically) or by hand by a developer. These are XML files that describe the build process elements (targets: build, clean, rebuild etc. that each contain constituent tasks) and inputs (items and properties). The project file is ultimately fed into the MSBuild engine, which in turn then generates the output.
The XML input to MSBuild is of course strongly-typed; the schema ships with VS 2005 Beta 1 and is called msbuild.xsd: if you include the namespace definition in Visual Studio when editing with its inbuilt XML editor, you'll get full Intellisense when working with MSBuild project files.
You can write the entire build process from scratch, if you like: here's a sample build project that compiles a C# application:
<?xml version="1.0" encoding="utf-8" ?> <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <OutputPath>Bin\</OutputPath> <AssemblyName>MSBuildSample</AssemblyName> </PropertyGroup> <ItemGroup> <Compile Include="MSBuildSample.cs"></Compile> <Reference Include="System.dll"></Reference> </ItemGroup> <Target Name="Build"> <MakeDir Directories="$(OutputPath)" Condition="!Exists('$(OutputPath)')" /> <Csc Sources="@(Compile)" References="@(Reference)" OutputAssembly="$(OutputPath)$(AssemblyName).exe" /> </Target> </Project>
To make the process simpler, MSBuild reuses elements of the build process through the use of .targets files, which define a compile target which is the override for any defaults. For example, Microsoft.CSharp.targets defines how to build C# applications with MSBuild; a similar file exists for J# and VB in the .NET Framework 2.0 directory (as specified in the LIBPATH environment variable).
The Excel add-in is one of two just released Business Intelligence solutions available for download:
These are free of charge to licensed customers and include full documentation and PSS support.
The aim for the Excel Add-in for Analysis Services is to provide a fuller reporting solution for OLAP cubes than is natively enabled in Excel PivotTables. You can use it to build a report structure with different grouping and segmentation options, and you can then fill that structure with data from an OLAP cube.
Some nice features:
If you're looking for a spreadsheet-based client into Analysis Services and you're finding PivotTables slightly too structured, this add-in is well worth evaluating.
Data Mining is about exploring your data, finding patterns and performing predictions. Where querying and analysis tells you what, data mining tells you why and how. In SQL Server 2005, data mining is made accessible and easy to use through an integrated user interface, cross-product integration and familiar, standard APIs. From the two algorithms that existed in SQL Server 2000, there are now a total of seven algorithms available out of the box, and it's possible to extend this further using an SDK.
Data OrganisationHow can we organise data to provide the most pertinent information? OLAP provides fast queries with aggregations, but the hierarchies are schema-driven. That makes it hard to know what hierarchies are meaningful or provide actionable information. "Intelligent" OLAP provides self-organising cubes with data-driven hierarchies. You can achieve this with a data mining dimension: from a cube, you generate a mining model that is used in turn to create a new dimension.
For example, the clustering algorithm takes the input data and attempts to segment it into groups. You could now rename those groups, before creating a data mining dimension and using them as dimension members for slicing data. Similarly, a decision trees algorithm could be used to generate a parent-child dimension. This enables us to determine (for example) which groups of customers are the most profitable, in a far more intelligent way than if we'd used OLAP alone without integrating data mining algorithms.
Data CleansingHow do we clean data as we load it into the data warehouse? We can use DTS pipeline integration in combination with a DM clustering algorithm to separate out clean and bad data. This can help us detect spurious data members (for example, a parent younger than 10 years old).
The steps are as follows: