.NET - Hangi Specific Version Değerini Seçmeliyim ?

Aynı dll'in birkaç farklı versiyonunu kullandığınızı varsayarak cevaplayacağız. Visual Studio'da Referans olarak eklediğiniz bir dll'in özelliklerinde SpecificVersion'ı (varsayılan halinde de olduğu gibi) true yaparsanız, projeniz o dll'in özellikle o versiyonuna referans verecektir.

İlerleyen zamanlarda size o dll'in aynı isimli ama farklı bir versiyonu verilirse ; yenisini projede kullanabilmek için önceden referans gösterdiğiniz dll'i silmeli ve yeni dll'i Add Reference yaparak referans olarak eklemelisiniz.

Diğer seçeneğiniz ise Visual Studio'da projenize referans olarak eklediğiniz dll'in özelliklerinde SpecificVersion'ı false olarak seçmek. Böylece projenize birkaç aynı isimde dll atsanız bile, proje en güncel versiyon olan dll'i bulup kullanacaktır. Tabi unutmamak lazım ki bu build sürenizi arttırabilir, çünkü artık projeniz siz pathini vermiş olsanız bile , o dll'in en son versiyonunu bulmak için farklı yerlerde dll'inizi avlama :D arayışına girecek.
-----------------------------------------------------------------------------------------------------------

This answer is going to be based on the assumption that you are versioning your dlls. If you set SpecificVersion to true (which is the default when adding a reference), then the project will reference to that dll with a particular version (say for instance 1.0.0.0).

If, at a later time, you're given a new dll (say 1.0.1.0), then you will have to remove the old dll reference and add the new reference. This is because the project is specifically looking for 1.0.0.0 when you have a new version 1.0.1.0.

The alternative to this is to set the SpecificVersion to false, which tells the project to find the latest available dll and use that one. The problem with this is that the project is now required to "hunt" in various places for the dll you've referenced, which can increase your build time. It will do this even though it knows the path of the dll you've referenced. I'm not sure if this is a bug or if this is done by design. It might be checking to see if there are any newer dlls besides the one you've referenced (perhaps in the GAC or elsewhere). 
----------------------------------------------------------------------------------------------------------

It's a compile-time property!

 One of the most important things to know is that "Specific Version" is a property that takes effect at compile-time and not at runtime.

What is it all about?

 When a project is built, the project's assembly references need to be resolved in order to find the physical assemblies that the build system should use. If the "Specific Version" check is performed (see section "When is "Specific Version" checked?"), it affects the outcome of the assembly resolution process:
 * The build system locates a physical assembly that it can potentially use
 * The build system compares the physical assembly's version to the assembly version stored in the .csproj file for the assembly reference
 * If the two assembly versions are exactly the same, the resolution process succeeds and the physical assembly found is used for the build
 * If the two assembly versions do not match, the physical assembly is discarded and the resolution process continues by locating the next potential assembly
 * If no more potential physical assemblies can be located, the resolution process fails. This results in a compiler warning (warning MSB3245) that tells you that the reference could not be resolved.
 * Interestingly enough, the build then continues! If the code has no actual references to the assembly, the build succeeds (with the previously mentioned warning). If the code has references, the build fails with an error that looks as if the code were using unknown types or namespaces. The only indication why the build really failed is the warning MSB3245. Order in which assemblies are resolved

The order in which the assembly resolution process locates potential assemblies: 

1. The assembly referenced by the element in the .csproj file 
2. The project output path 
3. The GAC 

 Note that if several versions of the assembly exist in the GAC, the resolution process first attempts to resolve to the assembly with the highest version. This is important only if the "Specific Version" check is not made. 

When is "Specific Version" checked? 

 Visual Studio bases its decision whether to perform the "Specific Version" check on two pieces of information found in the .csproj file: 
 The presence or absence of the element, and its value (if it is present) 
The presence or absence of version information in the assembly reference. 
This is how a typical assembly reference with version information looks like (line break added by me for better readability): 

<Reference Include="Foo, Version=1.2.3.4, Culture=neutral,
                         processorArchitecture=MSIL">
  <SpecificVersion>True</SpecificVersion>
  <HintPath>..\..\Bar\Foo.dll</HintPath>
</Reference>

And this is how the assembly reference looks like without version information: 

<Reference Include="Foo">
[...]

The following table shows when the "Specific Version" check is performed, and when it is not: 

                            |     Version information
                            |  Present       Not present
----------------------------+------------------------------
<SpecificVersion>           |
- Present, has value True   |    Yes (1)        Yes (check always fails) (2)
- Present, has value False  |    No  (3)        No (4) 
- Not present               |    Yes (5)        No (6)

    
 The surprising thing here is that no check is performed if both and version information are absent (case 6). I would have expected the check to be performed and to always fail (same as case 2) because in my understanding the absence of implies the default value "True". This may be a quirk of Visual Studio 2010 where I did my tests. 

 When you examine the properties of an assembly reference in the Visual Studio UI (select the reference and hit F4), the value you see for the "Specific Version" property tells you whether or not Visual Studio is going to perform the "Specific Version" check. In case 6 the UI will show "True", although the element is not present in the .csproj file. 

Side-effects on "Copy local" 

 If the "Copy Local" property is set to "True" but the assembly resolution process fails because of the "Specific Version" check, no assembly is copied. 

Reference material 

 What you need to know about referenced assemblies in VS2005 (blogs.msdn.com article) What's New in .NET 2.0 for Assemblies and Versioning? (codemag.com article which reproduces the above MSDN article, down to the wording, but contains a few screenshots and additional information about assembly versioning)