Kevin,

>I've built about a dozen classes in C# that I'm using in a Winforms app. A couple of them are composite classes, so I have some dependencies.
>
>Am I correct that there are two ways to implement them in an app - either to build dependencies/references in my project/solution, or to use the GAC?

You are correct. The dependencies/references will exist in your project whether the DLL is part of the GAC or not. It's merely a matter of whether they are pointing to the GAC or pointing to a private copy of the DLL.
>
>Up until now, I've always done the former, because someone advised me against using the GAC. It's a bit of a pain, because I have to move compiled DLLs into my run-time folder structure to do run-time testing.

This should not be necessary if you are using VS.NET to develop your projects. The IDE will grab a copy of the DLL and place it into a folder in your project when you create the reference. When you build the solution, the IDE will update your local copy of the DLL if it sees a newer version number on the original DLL. Or, if you specify a version # in the reference, it will leave your local copy alone (side-by-side versioning).

> Are there big pros-cons one way or another?

For Winforms, there isn't much difference between installing the DLL into the GAC or using a project-specific copy, unless the size of the DLL prohibits having multiple copies or if you are using SHARED (static in C#?) classes. With side-by-side versioning, you won't break existing apps by installing the DLL into the GAC. Of course, classes with static members require that the class be in a centralized location by definition.

The big issue with the GAC is in Web Applications, where you may not have administrative control of the server.