This content has been marked as final. Show 4 replies
The SpecificVersion property is just a build directive for the Visual Studio compiler. It causes the latest version of an assembly that can be found to be loaded when you compile. It doesn't have any effect on your assemblies at runtime. Your assemblies will require the version of a dependency that was used to compile them. The exception to this is the presence of a policy assembly for the dependency to point your assembly to a newer version of the dependency. ESRI did not supply policy assemblies at version 10. I don't know if this is going to be the case for 10.1 but unless they do you will need to recompile against the newer version.
Many thanks Neil, I will try and get official word from ESRI through support. How does that affect service pack versions of the Dlls? Surly we can't ahve to compile against all service packs too?
I'm not exactly sure. We haven't made the upgrade to 10 yet as we are still waiting on clients. I've upgraded several of our apps for internal testing. They were compiled on a machine with ArcGIS Desktop 10 installed with no service packs. I've installed one of them on a machine w/ SP2 and it appears to run fine. My guess is that the build number is ignored when determining version (i.e. 22.214.171.1240 and 126.96.36.1990 are both version 1.0.0) but I haven't seen this documented by Microsoft anywhere.
Many thanks Neil, I have since been reading up on this. For everyone else here are a couple of links which back up what Neil was saying:
Situation Prior to 10:
At Version 10
Policy files removed
Due to the separation changes between ArcGIS Desktop and Engine the policy files
that were installed into the Global Assembly Cache are no longer installed. These
allowed customisations that targeted lower version of ArcGIS Desktop work with
newer versions; the policy files redirected calls to previous ArcObjects assemblies
to the newer versions. As a result of this change all existing .Net code must be
recompiled for this release.