I am trying to integrate VB6 with Vault client v3.5.0.4741. On some computers it works while on others it does not. I have used the Visual Studio 2005 'fuslogvw' tool to monitor the assembly binding information - and the output is attached below.
Basically it falls over trying to locate 'VaultClientNetLib.XmlSerializers' - which it cannot find. The VaultGUIClient.exe is trying to bind to this.
On systems that do work I do see the VaultClientNetLib bind successfully and there is no attempt to bind to VaultClientNetLib.XmlSerializers at all.
I am hoping you can explain what is missing or corrupt on the sytems that do not work.
VaultClientNetLib.XmlSerializers
Moderator: SourceGear
VaultClientNetLib.XmlSerializers
- Attachments
-
- VaultClientNetLib.XmlSerializers.txt
- Output from fuslogvw.exe (fusion log viewer)
- (2 KiB) Downloaded 161 times
Alan Paterson
Can you give me the steps being done when attempting to bind a project?
Are your users performing an Open From Source Control the first time they access a project?
Also, how was Vault installed. Was it an upgrade or a fresh install?
I am not trying to bind aproject - what I showed you was .NET v2's output as it attempts to bind the requirements of VaultGUIClient.exe. It is your application that is being launched by VB6 when I go to the Cource Control menu and call 'Open Project from Source Control'. This launches VaultGUIClient - which fails to bind to the XmlSerializers as shown in the attachment.
So yes I guess you could say it is the first time they access a project through VB - although the files are actually all on the PC already.
It was originally a clean install of the client - but in attempting to fix the problem it has been ininstalled/reinstalled a few times - but always the same version. I did have .NET 1.1 and 2 on the PC at one time - and actually that worked. Then I removed 1.1 so as to only have v2.0.50727 - and now I get the problem. Though it is no problem to launch the Vault client as an exe from start menu. But as I said - that way I don't see any attempt by .NET to bind to the XmlSerializers.
Does that help???
Are your users performing an Open From Source Control the first time they access a project?
Also, how was Vault installed. Was it an upgrade or a fresh install?
I am not trying to bind aproject - what I showed you was .NET v2's output as it attempts to bind the requirements of VaultGUIClient.exe. It is your application that is being launched by VB6 when I go to the Cource Control menu and call 'Open Project from Source Control'. This launches VaultGUIClient - which fails to bind to the XmlSerializers as shown in the attachment.
So yes I guess you could say it is the first time they access a project through VB - although the files are actually all on the PC already.
It was originally a clean install of the client - but in attempting to fix the problem it has been ininstalled/reinstalled a few times - but always the same version. I did have .NET 1.1 and 2 on the PC at one time - and actually that worked. Then I removed 1.1 so as to only have v2.0.50727 - and now I get the problem. Though it is no problem to launch the Vault client as an exe from start menu. But as I said - that way I don't see any attempt by .NET to bind to the XmlSerializers.
Does that help???
Alan Paterson
It is very possible that your client is configured to use the 1.1 .NET framework, so removing that would confuse it. Also, I have found that if the Vault server and the client are using different .NET frameworks that weird things happen that are inconsistent..NET 1.1 and 2 on the PC at one time - and actually that worked.
If it works with both frameworks installed, is there anything preventing you from allowing both to be on your client?
Also, so that I have a little more information, can you go to a Vault client GUI on a machine that isn't having this trouble, and go to Help - Technical support and copy the information from there to me?
Also, is both the server and client installed on 32-bit systems?
Yes - server and client are both 32bit
Here is the Techniical Info....
Client Information
Vault Client Version: 3.5.0.4741
.Net Framework Version: 1.1.4322.2032
Operating System: Microsoft Windows XP Professional
Service Pack: 2.0
OS Version: 5.1.2600
Total Physical Memory: 3.5 GB
Time Zone: (GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London
Server Information
Vault Server Version: 3.5.0.4741
.Net Framework Version: 1.1.4322.2300
Operating System: Microsoft(R) Windows(R) Server 2003, Standard Edition
Service Pack: 1.0
OS Version: 5.2.3790
Timezone: (GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London
SQL Version: Microsoft SQL Server 2000 - 8.00.2039 (Intel X86)
May 3 2005 23:18:38
Copyright (c) 1988-2003 Microsoft Corporation
Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 1)
License Information
3 serial number(s):
1 of 3: 10 users, permanent
2 of 3: 1 users, permanent
3 of 3: 1 users, permanent
This system WORKS.
Doing the same on the system that does NOT work - everything is the same except the client is using .NET framework v2.0.50727
Regarding 1 or 2 frameworks installed - I was having some problems debugging my VB6 application that made no sense (I could run it but not debug it - because in debug mode its vb that needs to load everything not the usual calling process). That was when I started using the fusion log viewer to debug what was going on in my app - and discovered that it was using v2 to load most of my references but the one that vb needed to load was being loaded by v1.1 (although it was a v2 dll. So that put me on the trail of it not being good to have 1.1 and 2 on the same pc - and so I removed 1.1. That did indeed fix my problem - my v2 dll's got loaded by vb6 using the v2 fusion dll. BUT that broke your app. So I definitely want to just use v2.
Can I ask you a question? If I had a file VaultClientNetLib.XmlSerializers.dll of the correct version (3.5.0) on my PC then the fusion.dll would be able to load the code it needs. I am sure that this file would be generated by .NET when your developers build VaultClientNetLib.dll. Could you see if this file does exist? I could verify that that would solve my problem. The System.Xml namespace needs to load the serialization information for VaultClientNetLib and cannot find it. I think this could be the cause of the starnge behaviour between 1.1 and 2.0.
Anyway - it does look a bit like the problem arises with different .NET versions on client and server. That's not really acceptable (our clients do not need v1.1 for anything) and VaultClientNetLib.XmlSerializers.dll would solve that for me.
Thanks for your detective work!
Here is the Techniical Info....
Client Information
Vault Client Version: 3.5.0.4741
.Net Framework Version: 1.1.4322.2032
Operating System: Microsoft Windows XP Professional
Service Pack: 2.0
OS Version: 5.1.2600
Total Physical Memory: 3.5 GB
Time Zone: (GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London
Server Information
Vault Server Version: 3.5.0.4741
.Net Framework Version: 1.1.4322.2300
Operating System: Microsoft(R) Windows(R) Server 2003, Standard Edition
Service Pack: 1.0
OS Version: 5.2.3790
Timezone: (GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London
SQL Version: Microsoft SQL Server 2000 - 8.00.2039 (Intel X86)
May 3 2005 23:18:38
Copyright (c) 1988-2003 Microsoft Corporation
Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 1)
License Information
3 serial number(s):
1 of 3: 10 users, permanent
2 of 3: 1 users, permanent
3 of 3: 1 users, permanent
This system WORKS.
Doing the same on the system that does NOT work - everything is the same except the client is using .NET framework v2.0.50727
Regarding 1 or 2 frameworks installed - I was having some problems debugging my VB6 application that made no sense (I could run it but not debug it - because in debug mode its vb that needs to load everything not the usual calling process). That was when I started using the fusion log viewer to debug what was going on in my app - and discovered that it was using v2 to load most of my references but the one that vb needed to load was being loaded by v1.1 (although it was a v2 dll. So that put me on the trail of it not being good to have 1.1 and 2 on the same pc - and so I removed 1.1. That did indeed fix my problem - my v2 dll's got loaded by vb6 using the v2 fusion dll. BUT that broke your app. So I definitely want to just use v2.
Can I ask you a question? If I had a file VaultClientNetLib.XmlSerializers.dll of the correct version (3.5.0) on my PC then the fusion.dll would be able to load the code it needs. I am sure that this file would be generated by .NET when your developers build VaultClientNetLib.dll. Could you see if this file does exist? I could verify that that would solve my problem. The System.Xml namespace needs to load the serialization information for VaultClientNetLib and cannot find it. I think this could be the cause of the starnge behaviour between 1.1 and 2.0.
Anyway - it does look a bit like the problem arises with different .NET versions on client and server. That's not really acceptable (our clients do not need v1.1 for anything) and VaultClientNetLib.XmlSerializers.dll would solve that for me.
Thanks for your detective work!
Alan Paterson