Public Key Token DLL troubles in 4.1 downloads
Posted: Sun Mar 09, 2008 6:10 am
I just stumbled across this and wanted to understand if its intentional or an oversight...
There is a file VaultClientOperationsLib.dll that is provided in the Vault Client Library download for 4.1 (and prior versions too, of course) at http://download.sourcegear.com/Vault/4. ... _16216.zip
This file has been signed with a strong key to create a public key token for it (exact value doesn't matter).
In order to run Vault NAnt tasks, you (of course) need the Vault NAnt task download at http://download.sourcegear.com/Vault/4. ... _16216.zip.
It would seem that the proper course of action when trying to run Vault NAnt tasks would be to take the Nant.Vaulttasks.dll from the second download and combine that with the (several) DLLs from the first download. This is where I ran into my issue...
It seems that the VaultClientOperationsLib.dll that is in the Client Library download has been assigned a public token but that the Vault Nant Task DLL was apparently compiled against a build of this same DLL that has a NULL public key token. It took some time (and the judicious use of the Fusion! Viewer from the .NET SDK to inspect the detailed ass'y resolution failures) to figure this out, but its clear that the Nant.VaultTasks.dll was compiled against an unsigned build of the VaultClientOperationsLib.dll file. The versions are all just fine (4.1.0.16216) but of couse the Nant Tasks dll isn't going to accept the signed ass'y when its expecting the unsigned one~!
The 'fix' such as it is was to use the copy of the VaultClientOperationsLib.dll file (and the other files too) that were (thankfully) also distributed in the Vault NAnt task donwload ZIP file (an excellent real-world example of why everyone should always store all DLLs needed to compile their source code in the repository right alongside their actual code -- if you guys hadn't had this DLL in the Nant Task download, I never could have solved this as cleanly
). Not surprisingly, the instance of the VaultClientOperationsLib.dll library in THAT zip file is 'properly' unsigned and thus has its public key token = NULL so it all works fine.
In short, these two DON'T work together...
Nant.VaultTasks.dll (from Vault Nant Task download)
VaultClientOperationsLib.dll (from Vault Client Library download)
...whereas these two DO work together...
Nant.VaultTasks.dll (from Vault Nant Task download)
VaultClientOperationsLib.dll (from Vault Nant Task download)
Even tho I've solved the problem on my end, my question is...was this intentional or an oversight? Is there a compelling reason for the instance of VaultClientOperationsLib.dll shipped with the NAnt task lib to be unsigned whereas the instance (exact same version number) that shipped with the Client Library download WAS signed?
Just wondering if my 'fix' for this is somehow introducing a hidden problem that I just haven't stumbled across yet....
Please advise. Thanks in advance,
-Steve B.
There is a file VaultClientOperationsLib.dll that is provided in the Vault Client Library download for 4.1 (and prior versions too, of course) at http://download.sourcegear.com/Vault/4. ... _16216.zip
This file has been signed with a strong key to create a public key token for it (exact value doesn't matter).
In order to run Vault NAnt tasks, you (of course) need the Vault NAnt task download at http://download.sourcegear.com/Vault/4. ... _16216.zip.
It would seem that the proper course of action when trying to run Vault NAnt tasks would be to take the Nant.Vaulttasks.dll from the second download and combine that with the (several) DLLs from the first download. This is where I ran into my issue...
It seems that the VaultClientOperationsLib.dll that is in the Client Library download has been assigned a public token but that the Vault Nant Task DLL was apparently compiled against a build of this same DLL that has a NULL public key token. It took some time (and the judicious use of the Fusion! Viewer from the .NET SDK to inspect the detailed ass'y resolution failures) to figure this out, but its clear that the Nant.VaultTasks.dll was compiled against an unsigned build of the VaultClientOperationsLib.dll file. The versions are all just fine (4.1.0.16216) but of couse the Nant Tasks dll isn't going to accept the signed ass'y when its expecting the unsigned one~!
The 'fix' such as it is was to use the copy of the VaultClientOperationsLib.dll file (and the other files too) that were (thankfully) also distributed in the Vault NAnt task donwload ZIP file (an excellent real-world example of why everyone should always store all DLLs needed to compile their source code in the repository right alongside their actual code -- if you guys hadn't had this DLL in the Nant Task download, I never could have solved this as cleanly
). Not surprisingly, the instance of the VaultClientOperationsLib.dll library in THAT zip file is 'properly' unsigned and thus has its public key token = NULL so it all works fine.In short, these two DON'T work together...
Nant.VaultTasks.dll (from Vault Nant Task download)
VaultClientOperationsLib.dll (from Vault Client Library download)
...whereas these two DO work together...
Nant.VaultTasks.dll (from Vault Nant Task download)
VaultClientOperationsLib.dll (from Vault Nant Task download)
Even tho I've solved the problem on my end, my question is...was this intentional or an oversight? Is there a compelling reason for the instance of VaultClientOperationsLib.dll shipped with the NAnt task lib to be unsigned whereas the instance (exact same version number) that shipped with the Client Library download WAS signed?
Just wondering if my 'fix' for this is somehow introducing a hidden problem that I just haven't stumbled across yet....
Please advise. Thanks in advance,
-Steve B.