Kevin, you are basically correct. Here's the way it works.

In general, there is no such thing as you "must" run xyz setup. Anyone can reverse engineer setup disks and put files, registry settings, etc in the right place. It's simply easier to use prebuilt and pretested components.

For the develper in C# or your .NET application, open the project and look at project references. These are the .NET and other DLL's required to run your application. Some of these are stored in the global assembly cache (GAC) found on the existing computer, they can come from anywhere, but usually from an installer (MSI) downloaded as part of the .NET framework or installer from another source like SQL Client tools, visual studio, or 3rd party tool.

You can install an assembly anywhere on the target PC, but common assemblies usually go in the GAC.

Once you figure out the name of the assembly they used (for example Microsoft.Sqlserver.Smo) then you can determine the best way to deploy it.

Creating a msi installer in .NET is pretty simple and the setup wizard will detect these dependencies (like the .NET framework) and add them to the setup project for you. Some are included as merge modules as part of the Visual Studio package.

Determining dependencies of dependencies can be tricky and sometimes its easier to use a tested package to get the 1 or 2 items you actually need. You can make web searches of assemblies to find out where to get installer modules, etc.

To see what .NET assemblies are installed go to C:\windows\assembly to get the name and version. If this list does not match the assemblies needed by the appliction then the application will trigger an exception when they attempt to use an object that is not installed.

Note that developers can sometimes put a copy of the assembly in the application folder, in addition to having a different version in the GAC.

Cheers