Issue Details (XML | Word | Printable)

Key: CORE-3901
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Neil Pickles
Votes: 0
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Unresolved references to Microsoft.VC80.CRT with GDS32.dll from v2.1.5.18496 x86 windows installer package

Created: 07/Aug/12 06:51 AM   Updated: 08/Aug/12 06:33 AM
Component/s: API / Client Library
Affects Version/s: 2.1.5
Fix Version/s: None

File Attachments: 1. File Firebird-2.1.5.18496_0_Win32.exe (6.53 MB)
2. File gds32.dll (440 kB)

Image Attachments:

1. error 1.png
(10 kB)

2. error 2.png
(87 kB)

3. error 3.png
(8 kB)
Environment: MS Windows XP/SP3 x86


 Description  « Hide
Our application requires GDS32.dll. We don't have Firebird installed on all machines, just the ones with databases on. Usually we only need to put the relevant GDS32.dll into our application folder on all machines and up to v2.1.4.18393 this all works absolutely fine whether Firebird is installed on the terminal or not.

Where we do have Firebird installed it is running SuperServer with all default options set (not that I think this makes any difference to this issue).

Now, with the latest update v2.1.5.18496, if we just copy the v2.1.5 GDS32.dll from the Firebird server into our application folder, when we try to launch our application on a terminal without Firebird installed we are getting SideBySide system errors recorded in the Windows event log and our application fails to launch.

I have attached screenshots of the system errors to this ticket and the text of the three errors are as follows:-

Error 1:-
Source: SideBySide, EventID: 32, Description: Dependant Assembly Microsoft.VC80.CRT could not be found and Last Error was The referenced assembly is not installed on your system.

Error 2:-
Source: SideBySide, EventID: 59, Description: Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference error message: The referenced assembly is not installed on your system.

Error 3:-
Source SideBySide, EventID: 59 , Description: Generate Activation Context failed for c:\progra~1\csy\vector7\gds32.dll. Reference error message: The operation completed successfully.

If we drop in the v2.1.4.18393 version of GDS32.dll everything works fine with no other changes so it would seem to be an issue with the v2.1.5 GDS32.dll itself.


 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 07/Aug/12 07:10 AM
What exact version(s) of msvcr80.dll do you have at terminal and where it is located ?

Neil Pickles added a comment - 07/Aug/12 07:42 AM
msvcr80.dll is located in 7 different places on this particular terminal and there seems to be 4 different versions of it.

The three that I believe are important to this issue, are in these locations:-

"C:\Windows\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd" which contain v8.0.50727.42

"C:\Windows\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.1433_x-ww_5cf844d2" which contains v8.0.50727.1433

"C:\Windows\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_e6967989" which contains v8.0.50727.4053

In other "C:\Program Files" subfolders we also have v8.0.50727.762 and v8.0.50727.4053.

Vlad Khorsun added a comment - 07/Aug/12 08:00 AM
At my machine fbclient.dll from 2.1.5 package (http://sourceforge.net/projects/firebird/files/firebird-win32/2.1.5-Release/Firebird-2.1.5.18496-0_Win32.zip) resolved to use 8.0.50727.4053 version of msvcr80.dll, which is located at correct SxS folder.
So, it should work for you too, i'd said.
Probably, this utility could help you http://www.dependencywalker.com/

Neil Pickles added a comment - 07/Aug/12 08:18 AM
I'll check it with Dependencywalker to see what version it is using but that isn't really a solution. We have thousands of customer terminals in the field and can't afford to break them by rolling out an update to use the newer version of Firebird v2.1.

My concern is that it all works okay when using the v2.1.4 GDS32.dll and simply by upgrading to use the v2.1.5 GDS32.dll it breaks without any other changes being made.

Vlad Khorsun added a comment - 07/Aug/12 08:29 AM
1. So far i see it more as support question, not a bug in Firebird
2. Nobody forced you to upgrade clients from 2.1.4 to 2.1.5, unless 2.1.5 fixed some fbclient's bug which is affects your application

Paul Reeves added a comment - 07/Aug/12 08:54 AM - edited

In fact all versions of Fb 2.1 are compiled against MSVCR80 v.8.0.50727.42 which is the one that shipped with the original release of VS2005. We never got around to upgrading to SP1 which uses v8.0.50727.762

But I suspect the problem is a screw up in your deployment. Two reasons. We don't actually ship gds32.dll - it is generated by instclient, either manually or by the binary installer during installation. And the binary installer also takes care of deploying the assemblies correctly. The idea of just 'dropping' a copy of gds32 onto the client is, sadly, 'deprecated' - you really should use the installer. There is even a scriptable option.

Fortunately MS have seen the error of their ways and since VS2010 things will get back to what we might consider 'normal' with Firebird 3.0.

Neil Pickles added a comment - 07/Aug/12 09:16 AM
Having now checked it with DependencyWalker, the v2.1.4 version resolves currectly to use the 4053 version of msvcr80.dll but the specific v2.1.5 version of GDS32.DLL fails to resolve properly with the following error.

Error: The Side-by-Side configuration information for "c:\program files\csy\vector7\GDS32.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Error: At least one required implicit or forwarded dependency was not found.

I have attached a copy of the specific v2.1.5 GDS32.dll if this can help diagnose the issue. Maybe it is just a corrupted file. Could this be influenced by the machine where the GDS32.dll file was created originally? I understand that this is a renamed, modified version of fbclient.dll, could a path get messed up during the creation process for GDS32.dll ? The attached GDS32.dll was created by the binary installer.

Having seen Paul Reeves comments, what actually does instclient do to fbclient.dll to make gds32.dll ?

Vlad Khorsun added a comment - 07/Aug/12 12:30 PM
This is the manifest extracted from attached gds32.dll

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.6195" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>


This is the manifest extracted from fbclient.dll from zip package (http://sourceforge.net/projects/firebird/files/firebird-win32/2.1.5-Release/Firebird-2.1.5.18496-0_Win32.zip)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

You see the difference.

PS manifests extacted using mt.exe utility from VS2005:

  mt -inputresource:gds32.dll;#2 -out:m.txt

Paul Reeves added a comment - 07/Aug/12 02:01 PM
I generated a 32-bit gds32.dll and checked it with mt. The manifest is the same as the one for fbclient.dll

I also did an install into W7 and checked the manifest. Again it is the same. So, still no idea how this has happened.

instclient, btw, doesn't do anything other than patch the version info to make it look like an InterBase 6.0 client library. If you don't need this backwards compatibility you would be well advised to update your applications to load fbclient.

IAC, it is likely that we will drop support for gds32 in Firebird 3.0.

Vlad Khorsun added a comment - 07/Aug/12 04:52 PM
Neil,

any chance you've used gds32.dll not from official installation package ? Snaphot or custom build, for example ?

Neil Pickles added a comment - 07/Aug/12 05:19 PM
I did download the RC for v2.1.5 and had a play with it using installation defaults but as soon as the proper v2.1.5 was released I downloaded that and upgraded using installation defaults again.

The GDS32.dll I attached earlier would have come from that installation, on a Windows 7 32 bit if that makes any difference though from Paul's comments I don't think it does.

I'll have a dig around on the machine where it originated and see if I can find anything.

Neil Pickles added a comment - 07/Aug/12 09:40 PM
On the Windows 7, 32 bit laptop where the problematic v2.1.5 gds32.dll originated.

I have tried reinstalling Firebird v2.1.4 using the Windows 32 bit exe installer and installation defaults and the checked the manifest within gds32.dll using the mt command you used and it is correct as per your previous comment where it references version="8.0.50608.0".

If I reinstall v2.1.5 using the attached installer, again using installation defaults and then check the manifest within gds32.dll I again get the same issue reproduced as before where if references version="8.0.50727.6195" instead.

So the problem appears to be something to do with this v2.1.5 installation package doing something different to the v2.1.4 one.

Any ideas ?

Paul Reeves added a comment - 08/Aug/12 06:33 AM
Well, this is a mystery. I've got both the 2.14. and 2.1.5 build trees used to prepare the final releases. They are in a dedicated VM that has been used for the entire 2.1 release cycle. Visual Studio hasn't changed. And the build/packaging process hasn't changed.

The packaging process builds the redistributable runtimes into an msi using the official dll's from the msvc redist directory. That is where the v8.0.50608.0 comes from. And the mt.exe generates the same manifest that accompanies the redistributables.

The only solution I can think of is to just rename fbclient to gds32. As long as you are not using IBX Delphi components you won't notice any difference.