 | |
| Figure 1. Wearing a Target: Designer-generated code in Visual Studio .NET 2003 is easily accessible, and thereby easily, accidentally modified.
|
Practical Uses of Partial Classes in Visual Studio 2005
Hide-protecting code is one of the best uses of partial classes; you can prevent mishaps and provide useful code-layer abstraction at the same time. In Visual Studio 2005, Microsoft uses partial classes to hide designer-generated code. For example, in Visual Studio .NET 2003, the designer-generated code for a Windows form is encapsulated within the region "Windows Form Designer generated code" (see
Figure 1). Very often, developers will accidentally modify the code within this region and cause the form to display incorrectly.
In Visual Studio 2005 however, the designer-generated code is no longer visible in the Code View window (see
Figure 2). Instead, it is hidden within Solution Explorer.
To see the designer-generated code, go to Solution Explorer and click on the Show All Files button (see
Figure 3). Under the name of the Windows form, you will see a file post fixed with the "
Designer.vb" name. Double-clicking on
Form1.Designer.vb will reveal the designer-generated code:
Partial Public Class Form1
Inherits System.Windows.Forms.Form
<System.Diagnostics.DebuggerNonUserCode()> _
Public Sub New()
MyBase.New()
'This call is required by the
' Windows Form Designer.
InitializeComponent()
...
 | |
| Figure 2. Out of Sight, Out of Mind: In Visual Studio 2005, the designer-generated code is not visible. |
Notice that the
Form1.Designer.vb file appears under the
Form1.vb file in Solution Explorer. This is a good way to represent the relationship between the two files. So what does Visual Studio do to represent this relationship? The answer lies in the
.vbproj or
.csproj (for C# projects) file. Open the file in Notepad and use
Ctrl + F to locate the
<ItemGroup> element:
...
<ItemGroup>
<Compile Include="Form1.vb">
<SubType>Form</SubType>
</Compile>
<Compile Include="Form1.Designer.vb">
<DependentUpon>Form1.vb</DependentUpon>
<SubType>Form</SubType>
</Compile>
...
 | |
| Figure 3. Unhidden: Showing all hidden files in Solution Explorer. Choose Designer.vb from the list to see the designer-generated code. |
As you can see, the
<DependentUpon> element indicates that
Form1.Designer.vb is dependent on
Form1.vb. So how is this information useful to us?
Recall that earlier in this article I mentioned two partial classes, MyClass1.methods.vb and MyClass1.properties.vb. Assume that these two classes serve as a template and contain general-purpose functions (and you generally would not make changes to these two classes). You may add a third partial class to add business-specific functions. And so, it would be useful to hide the first two partial classes in Solution Explorer by modifying the
.vbproj/.csproj file:
<ItemGroup>
<Compile Include="MyClass1.vb">
<SubType>MyClass1</SubType>
</Compile>
<Compile Include="MyClass1.properties.vb" >
<DependentUpon>MyClass1.vb</DependentUpon>
<SubType>MyClass1</SubType>
</Compile>
<Compile Include="MyClass1.methods.vb" >
<DependentUpon>MyClass1.vb</DependentUpon>
<SubType>MyClass1</SubType>
</Compile>
 | |
| Figure 4. Hidden: Hiding the partial classes in Solution Explorer. |
When the project is loaded in Visual Studio 2005, you should see the two partial classes hidden, as shown in
Figure 4.
Unfortunately, at this moment you need to manually modify the project file in order to hide partial classes. Hopefully in the next beta Microsoft will build this function into Visual Studio. Or someone else will write a plugin for that.
In this article, you have seen how to split the definitions of a class into multiple classes using the "partial" keyword. The greatest use of partial classes is undoubtedly the separation of UI and business logic. I am interested to know how else you may be using partial classes. .