compiled exe is missing zlib1.dll

Forum for users of SQL Packager database archive utility

Moderator: David Atkinson

Postby adrianbanks » Tue Jun 05, 2007 2:27 pm

We have been having a possibly related problem (see post http://www.red-gate.com/MessageBoard/viewtopic.php?t=5016) and eventually found a solution to make the compiled output work correctly on a 64 bit machine.

Using CorFlags.exe from the .Net SDK (http://www.process64.com/SettingPlatformDependencyBitsInNet20.aspx), we've set the bit flags on the compiled exe to force it to always run as a 32 bit process. Our installer now works on both 32 and 64 bit hardware.

When viewing our fusion logs, we were also having the binding failure with the Zlib dll, but it still works correctly without it. The real problem was the 64 bit issue.
adrianbanks
 
Posts: 17
Joined: Thu Aug 04, 2005 5:46 pm

Postby Brian Donahue » Wed Jun 06, 2007 6:57 pm

Thanks Adrian,

I've noticed this on my own 32-bit system as well. Any time you run a package it seems to fail on one binding attempt and then proceed to work regardless.

What seems to be happening is that the compression library is extracted from the resources into a temporary file in %TMP%\\Red Gate, then the file is loaded into the AppDomain as an assembly. It's not clear exactly how .NET Framework is doing that, but if experience serves me right it probably puts the assembly in the %TMP%\\something.tmp folder.

So maybe logging the assembly bindings isn't really the way to go, because the assembly is being loaded from disk right into the AppDomain (AppDomain.CurrentDomain.Load).
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am

Postby adrianbanks » Thu Jun 07, 2007 3:54 pm

Having done further investigation, the problem definitely appears to be with the compression library.

With compression enabled, the packaged database (packaged on a 32 bit machine) fails on a 64 bit machine.

With compression disabled, the packaged database (packaged on a 32 bit machine) succeeds on a 64 bit machine.

Is there an issue with the compression dll on a 64 bit machine that would cause this problem?
adrianbanks
 
Posts: 17
Joined: Thu Aug 04, 2005 5:46 pm

Postby Brian Donahue » Thu Jun 07, 2007 4:22 pm

Have you got Visual Studio installed? What you may want to try is run the packager to create a package and output as a C# project. Then open the output project in Visual Studio, and change the target platform from 'any CPU' to specifically 'x86' and compile the project.

I'm sorry I am unable to reproduce the problem, on an x64 computer with 64-bit Windows, a package built on a 32-bit edition of Windows will run just fine.
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am

Postby adrianbanks » Fri Jun 08, 2007 10:53 am

I'm not actually using the packager, I'm using the SQL Toolkit API to generate the compiled packaged output from some of my own code. I am however using the (slightly modified) template solution that comes with the packager for the output.

What I'm trying to get to the bottom of is whether the standard packager output has an issue with 64 bit, or whether it is specific to the modified template solution I am using.

I've tried some tests with differing results:

Using the modified template solution as a base, I used my code to generate a C# .exe file. This will run fine on 32 or 64 bit with compression disabled, and on 64 bit with compression disabled, but crashes on 64 bit with compression enabled.

Using the modified template solution as a base (ie. replacing the one in C:\\Program Files\\Red Gate\\SQL Bundle 5\\SQL Packager Code Templates\\C#), I used the Red Gate SQL Packager version 5.2.0.49 to generate a C# .exe file. This will run fine on both 32 or 64 bit with compression disabled or enabled.

It seems that something in the way the PackagerEngine.Package() method compiles the output causes this issue.
adrianbanks
 
Posts: 17
Joined: Thu Aug 04, 2005 5:46 pm

Postby Brian Donahue » Fri Jun 08, 2007 2:09 pm

Can you try it with the 'factory' version of SQL Packager code template? If this still exists in your SQL Bundle 5 installation directory, all you'd need to do is change the first argument in the PackagerEngine constructor (TemplateFolder) to point at c:\\program files\\red gate\\sql bundle 5\\sql packager code templates\\c#.
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am

Postby adrianbanks » Fri Jun 08, 2007 2:36 pm

Ok. I did four runs. Each time, I used my custom code to create a package using the RedGate PackagerEngine class.

Using my 'custom' code template:

Compression disabled: works ok
Compression enabled: crashes

Using the 'factory' version of SQL Packager code template:

Compression disabled: works ok
Compression enabled: crashes


So it doesn't look like the template is the cause of the problem. I also tried making sure the RedGate.Compression.ZLib.dll was present in next to the packages with compression enabled to make sure it wasn't just a binding problem, but that made no difference.
adrianbanks
 
Posts: 17
Joined: Thu Aug 04, 2005 5:46 pm

Postby Brian Donahue » Fri Jun 08, 2007 2:47 pm

Hi,

I still think it would work if you changed the OutputType from Executable to Project, then manually compiled it with Visual Studio, after setting the platform target to x86 instead of Any CPU.

If that works, maybe we could find a way for packager to create its' executables this way.
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am

Postby adrianbanks » Fri Jun 08, 2007 4:15 pm

I've modified my code to make the PackagerEngine output a project instead of a compiled exe.

Compiling this project using VS2003, it fails with an error to do with loading resources. (Is the option to compile for x86 available in VS2003 - I thought this was a VS2005+ option only?)

Compiling this project using VS2005 for "any CPU", it fails with the usual error.

Compiling this project using VS2005 for "x86", it works.

Could it possibly be something to do with the fact the my application is running under .Net 2.0, creating the package project as a VS2003 project, which the PackagerEngine then compiles under .Net 1.1?
adrianbanks
 
Posts: 17
Joined: Thu Aug 04, 2005 5:46 pm

Postby Brian Donahue » Fri Jun 08, 2007 4:47 pm

Odd -- I thought the opposite would have been true. The resources should be produced in .NET 1.1 format and therefore incompatible with .NET 2.0. Maybe this is the root of the problem -- did you perhaps convert your SQL Packager code template to .NET 2.0? I think this breaks the code template.
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am

Postby adrianbanks » Fri Jun 08, 2007 4:49 pm

No. I have tried that to try and solve this problem, but the PackagerEngine won't compile it so I had to put it back to a VS2003 project.
adrianbanks
 
Posts: 17
Joined: Thu Aug 04, 2005 5:46 pm

Postby StevenE » Mon Jun 11, 2007 10:36 am

Sorry to change the track a bit but I tried using Corflags to set the app as 32 bit and the exe works correctly on x64 systems. This is an acceptable solution. (The exes are being used as part of an installer).

Regarding the current thread, I have not modified or changed the code templates, I am using the product 'out of the box'.

Many thanks for your suggestions

Steven Elliott
StevenE
 
Posts: 9
Joined: Mon Jun 04, 2007 10:36 am

Postby Brian Donahue » Tue Jun 12, 2007 1:15 pm

Thanks Steven!

I have noted this down in our internal documentation so we can use it if this issue comes up again. Thanks for letting us know what your solution was.
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am

Previous

Return to SQL Packager Previous Versions

Who is online

Users browsing this forum: No registered users and 0 guests