Amanda Silver - Demonstration of code separation in next version of Visual Basic

Partial classes are mainly useful in scenarios where code generation is involved. Whether that's the Visual Studio designer or your own code generation system doesn't matter, partial classes will be useful.

Basically, if you're generating code, you're going to want to have some way for the programmer to extend the generated code. And you're going to want to do that in a way that lets the programmer treat the generated code as a black box, and most importantly in such a way that regenerating the code will not overwrite your programmer's code. As anyone who's dealt with code generation can tell you, hand-crafted code is holy!

There are several possible solutions.
You can have the generated code in the same file as your code. This is what Visual Studio does in the current version. The problems with it is that it messes up the file. It becomes harder to read your code because of the designer-generated code that's in between it.
You can have the generator create some class, and then you inherit from it. And you can have the generator create some class that inherits from you. Both methods have the disadvantage that you're creating two classes that describe usually just one entity, and where the base class makes no sense without the child class. So you're making a separation where there should not be one logically.

ASP.NET actually uses that last one with code-behind files (I'm not talking about Visual Studio now, just ASP.NET itself). You write a code-behind class, ASP.NET generates one from the aspx file that inherits from your class. This happens the first time a page is accessed by a browser.

Now anyone who has written aspx files with code-behind without using the VS.NET designer knows this has a very big problem. For every <SomeControl ID="SomeID" Runat="server"> in your aspx file, you need a Protected SomeID As SomeControl in your code-behind file. If you're using the designer, it makes sure your code-behind declarations and aspx controls keep in synch. But if you don't like the designer, and like me write aspx code by hand, it's up to you to keep those declarations correct.

The code-beside model (partial classes) fixes that. Now the ASP.NET runtime creates a partial class from the aspx file. Because these merge into one logical unit, any declarations that the ASP.NET runtime generates are automatically visible in your partial classes, so there's no need for repeat declarations.

For the WinForms designer, the advantage is that your own code file is less cluttered with designer-created code.

I can't offhand think of a situation where it'd be practical to write partial classes by hand, but there probably are some anyway.

Partial classes isn't just fluff. Like I said, it's a great feature when dealing with code generation.

In fact, I'm working on a code generation system myself, and I'm wishing I could use those partial classes. But since I'm targetting .Net 1.1, I can't do that.

For stuff like the ASP.NET runtime, the XAML compiler, etc. partial classes is a much needed, and from my developer point of view, much welcomed, feature.

For stuff like the Windows Forms designer, the need is less there, mainly because of #region, but it's still a cleaner separation of designer-generated code and hand-crafted code than what's done now, while avoiding the trouble associated with an inheritance based solution.

I don't think it'll be so useful for manual coding. Separating hand-crafted code over many files may lead to maintenance problems. And I think that if you have a class that's so big it warrants spreading over more than one file, you probably need to rethink your design.

Also, they've not added "everything they can think of" yet. Don't forget that VB.NET 2005 is also getting generics, unsigned types (way overdue) and operator overloading. Those are also much welcomed features.