As already mentioned, VS.NET 2002 and 2003 cannot handle multifile assemblies.  In fact, with the notable exception of Visual C++ with Managed Extensions, you cannot even specify a project to compile as a module.  Because of this, you will have to maintain build scripts like the ones in the demo (only more complex) and ensure that the files, references, and other project settings are the same in the build scripts as they are in the VS.NET project file.

Also, as of v7.1 (2003), Visual C# does not support Intellisense for code that is in modules, that is, not in the main assembly file with the assembly manifest.  Thus, if you use option one above and reference that assembly in a C# project in VS.NET, absolutely none of the types in that assembly will show up in Intellisense.  If you use option two above, only those types in the main assembly project (in our case, CSLibrary) will be visible in Intellisense.  As I see it, this is a very grave reason not to use multifile assemblies for code libraries unless you can architect it in such a way that all public types will be in the main assembly.  Note that this limitation does not apply to VB.NET--all types are visible in Intellisense regardless of which method you use.

I presume that you can understand now why I recommend against using multifile assemblies unless you really need them.  Both of these limitations can make creating and using them more of a problem than a solution for most.  The biggest niche for them will be internet deployment, but that is not too common today.  Hopefully the Visual Studio.NET teams will enhance their products to better support them in the future, but in the meantime, beware.