Question

I have a binary (let’s call it DllParent) that has a reference to another DLL (DllChild). When adding a reference, we have an option of setting the SpecificVersion property to true or false.

When looking at DllParent in Reflector (or similar tool), is there a way to find out whether the developer set the SpecificVersion property for DllChild to true or false?

Answer 1

The answer is no.

When you add a reference to a strongly named assembly to your project the Visual Studio stores the full strong name that includes version in your .csproj file.

Then during each build when MSBuild code tries to resolve assembly references, that is to find the actual assembly file that it can use during the build, if SpecificVersion is set to true then the version in the .dll would have to match the version specified in the project file.

This may present a problem that if you want to upgrade to a new version of the assembly you would need to go and change references in all your projects that use that assembly because otherwise the build would fail, so to simplify your life you can just set SpecificVersion to false.

In this case your build could still fail after upgrade if some method signatures have been changed. This would be bad but fixable if you get the error while compiling the project but if the same thing would be allowed to happen during runtime, for the end user this would present a serious problem.

So, .Net does not allow this to happen by enforcing strict matching of the exact version that was used during build time regardless of the value of SpecificVersion in your project file.

MSBuild just stores the version with the assembly reference in the binary .dll file and after that examining it with Reflector would only show you which version of the referenced assembly the MSBuild have actually used, not how it had resolved the project’s reference.

It is still possible for the developer of the referenced assembly to specify that a new version could safely be used instead of an old version but this is done through different mechanisms:

1. If the public interface have changed but in a way that is compatible with the old version (say adding a method is compatible but removing or changing parameters are not) then a policy file could be deployed along with the new version to tell .Net system that it is a safe substitution. (http://msdn.microsoft.com/en-us/library/dz32563a.aspx)

2. If the public interface is exactly the same and only the internal implementation of methods was changed then the developer of the referenced assembly can just keep the same AssemlyVersion value but change AssemblyFileVersion. In this case the file version that you can see in Windows Explorer would be updated but the strong name would stay the same. That’s what Microsoft does when it updates, say, System.dll

In both cases the referencing assembly (DllParent in your question) would still have the original version number inside.