Many .NET developers are aware of the idea of partial Classes, as they have existed since .NET 2.0.  The primary purpose is to allow you the developer to share claim on a C# Class with Visual Studio’s automated code generators (mainly used by the many designers included in Visual Studio), without the automated code generator stomping all over your code additions every time it runs.  For instance, in a Windows Forms application, you get a code-behind Class where you can put your logic, properties, methods, and event handlers; it is a partial Class of the one Visual Studio’s Windows Form designer creates and manages for all the UI objects you dragged around in the designer.  A good summarization of this feature is given by Bart De Smet:

"In short, partial classes allow you to split the definition of a class across multiple files, or alternatively you could think about it as a code compilation unit separated over multiple files."

As another practical application of this feature, I have occasionally implemented a practice using partial Classes that I learned from a previous coworker.  Occasionally you find yourself with a Class that is inescapably large.  Perhaps it is a web service that has been in use for a while by customers or other groups within your company, and you can’t just deprecate the service very easily; so you just keep extending it and adding more web methods to it for additional, similar functionality.  Another potential situation could be that you began designing a simple application all in one file but it grew to be a little bigger than expected, but it doesn’t quite merit a whole major redesign into appropriate classes.  I know how this all sounds, but these scenarios aren’t exactly uncommon in real-world practice, where there are other factors in consideration.  I suppose many would resort to C# regions, but I’m not a fan of them as it really only gives the illusion that your code file is better grouped and somehow shorter.