Dave Burke : Freelance .NET Web Developer specializing in Online Communities

GSP Tip: ICSharp.SharpZipLib.dll 32x/64x Awareness

You'll have to admit, when I go with a bad post title I commit all the way.  I didn't know how else to describe the issue at hand without inferring Gallery Server Pro v2.3 was broken in some way, which it isn't.

If you may recall, last night I blogged about the cool multi-file download feature of Gallery Server Pro 2.3 now on DBVT.COM. I thought I should probably test it before clicking the "publish" button.  Boink!  Instead of receiving the nifty "Save ZIP to file" dialog box popup like I do on my office server, the browser spit out an XML parsing error, one of those with a smidget of HTML in the top left-hand corner and nothing else.


It worked fine here on 64-bit Windows 2008 Server, but was bombing on my Windows 2003 32x host.  (My VPS is in the process of being migrated over.)  I remoted into my host and looked at the application log where I found the culprit.



GSP uses the ICSharpCode.SharpZipLib.dll library, so I knew that was my boy.  I downloaded Roger Martin's Web 32-bit package and uploaded its SharpZipLib DLL to my site's bin directory.  Back in business.  "Publish It!"

Comments (2) | Post RSS RSS comment feed

Posted on 6/3/2009 2:15:16 PM by Dave Burke
Categories: Gallery Server Pro
Tags:

Related posts

Comments (2) -

6/3/2009 7:19:23 PM Permalink

Bizarre. I use the same SharpZipLib dll in both packages. I develop on x64 and first create the x64 deployment package. Then I copy the ZIP and replace the SQLite dll with the 32-bit version for the x86 version. Every other file - including the SharpZipLib dll - remains the same.

I can't argue with your success, but it doesn't make any sense.

Roger

Roger Martin United States |

6/3/2009 7:51:54 PM Permalink

Roger,

Thanks for visiting!  Using the GSP source as I always do, the SharpZipLib.DLL builds in TIS.GSP.Business.  There's no physical SharpZipLib.DLL in the /bin directory of my office server, so the GSP.Business.ZipUtility.cs and I suppose other classes build on 64-bits.  The presence of the 32-bit version SharpZipLib.DLL resolved it.

You're right.  It's the same DLL, but it was the SDK build factor that caused the issue.  As I tried to convey in the post, this is a weird occurrence yet something which might come up again, so I thought it might be helpful.

-Dave

daveburke United States |


Powered by BlogEngine.NET 2.0.0.36
Theme by Dave Burke