Red Gate forums :: View topic - compiled exe is missing zlib1.dll
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SQL Packager Previous Versions
SQL Packager Previous Versions forum

compiled exe is missing zlib1.dll

Search in SQL Packager Previous Versions forum
Post new topic   Reply to topic
Jump to:  
Go to page Previous  1, 2
Author Message
adrianbanks



Joined: 04 Aug 2005
Posts: 17

PostPosted: Tue Jun 05, 2007 2:27 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6581

PostPosted: Wed Jun 06, 2007 6:57 pm    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
adrianbanks



Joined: 04 Aug 2005
Posts: 17

PostPosted: Thu Jun 07, 2007 3:54 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6581

PostPosted: Thu Jun 07, 2007 4:22 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
adrianbanks



Joined: 04 Aug 2005
Posts: 17

PostPosted: Fri Jun 08, 2007 10:53 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6581

PostPosted: Fri Jun 08, 2007 2:09 pm    Post subject: Reply with quote

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#.
Back to top
View user's profile Send private message
adrianbanks



Joined: 04 Aug 2005
Posts: 17

PostPosted: Fri Jun 08, 2007 2:36 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6581

PostPosted: Fri Jun 08, 2007 2:47 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
adrianbanks



Joined: 04 Aug 2005
Posts: 17

PostPosted: Fri Jun 08, 2007 4:15 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6581

PostPosted: Fri Jun 08, 2007 4:47 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
adrianbanks



Joined: 04 Aug 2005
Posts: 17

PostPosted: Fri Jun 08, 2007 4:49 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
StevenE



Joined: 04 Jun 2007
Posts: 9

PostPosted: Mon Jun 11, 2007 10:36 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6581

PostPosted: Tue Jun 12, 2007 1:15 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Go to page Previous  1, 2
Page 2 of 2

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group