Visual Studio manages the .NET Framework assembly references well on a project basis. It is automatic but also brings about confusions in some situations.
The .NET Framework 3.5 and 4.0 provide two profiles, regular or full (without suffix in names) and Client (with the Client Profile suffix in names).
Though the System.Windows.Forms in the two profiles of .NET Framework 3.5 has exactly the same Runtime Version (still v2.0.50727), they reside in different locations, the regular in the Windows Microsoft .NET Framework and the client in the Reference Assemblies of Program Files (x86).
An interesting point is that the v3.5 Client Profile has the consistent version number (v3.5) along with Profile and Client in its path.
For .NET Framework 4 and 4 Client Profile, however, they both reside in the .NET Framework Reference Assemblies of the Program Files (x86) directory.
Their names and their locations are consistent this time. For assemblies of regular profile, they are right under the v4.0 folder; for client profile, they are in the Client Profile sub folder. For a particular assembly such as the System.Windows.Forms, they still have the same Runtime Version (v4.0.30319) in the two locations and profiles, regular and client.
The Client Profile folder has 216 files and the v4.0 folder 466. Therefore, the full or regular profile of the .NET Framework 4.0 has 250 files, by doing a simple subtraction, about 20 percent more than the client profile.
Many people wonder what might be the exact benefits of using the Client Profile. Some said it is for the convenience of installation and loading; some said for performance purpose; some mentioned size efficient. None looked persuasive enough, to us. Maybe the benefits were just minor, or simply the overheads were more than size or performance gain. That could explain why no Client Profile anymore in newer .NET Framework versions such as 4.5 and 4.5.1.
It should be a good practice to always use regular or full profiles of .NET Framework to avoid troubles.