Visual Studio manages the .NET Framework assembly references well on a project basis. It is automatic but also brings about confusions in some situations.
It is easy to understand that when the Target
Framework of a Visual Studio project is upgraded to a newer version, e.g. from
3.0 to 4.5, all old references will be replaced automatically with new versions
if available, and when downgrading similar happens. We always added or removed references through
the Visual Studio Reference Manager in the past and things behaved well for
.NET Framework assemblies. However, inconsistencies
happened to us occasionally for custom (library) assemblies. Some projects had been upgraded to reference
to new library DLLs, but many others did not. The inconsistency caused serious problems
(loading or running) especially for those strong named assemblies. It was time-consuming and error-prone to
inspect references one by one and projects one by one manually using the Properties
and Reference Manager UIs. That was the
initial idea of developing the Reference Tweaker to help.
Some readers may have already tried the Reference
Tweaker of the Visual Smarter. The full
name of the widget should be Multiple-Project Reference Tweaker actually, as it
works with multiple projects instead of a single one. Currently, it supports removing and adding
references from and to multiple projects of the current solution. In terms of replacing references, we
recommend removing first and adding next.
Through using the Reference Tweaker, we corrected
many reference inconsistencies in many projects and solutions. However, we wondered what would happen if
some .NET Framework assemblies with versions different from the Target .NET
Framework of some projects of concern (or simply they did not target to the
same .NET Framework) were brought in, so did an experiment.
As can be seen, the .NET Framework of the project was target at 4.5. The assemblies automatically referenced in by
the Visual Studio wizard resided at the v4.5 location in the Program Files root
directory. The .NET assemblies were
going to be added by the Reference Tweaker came from the Framework 4.0 in the
Windows directory. People might wonder
why we did not use the same versions of .NET assemblies as specified by the
Target Framework (4.5 here) of the project of concern. The fact was there were no higher versions
(e.g. 4.5 or 4.5.1) at the same location in the Windows root.
Luckily enough, Visual Studio automatically
adjusted the versions of the .NET Assembly references to the same as specified
by the Target Framework.
Things went well so far. In terms of why still some looking
inconsistencies among the assembly Folder Name, assembly Version, and Runtime
Version, we found it was as designed through some research. That will be discussed next. Please stay tuned.
