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.