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.
great
ReplyDelete