Hi Tom,

If you have to use a different version of ICSharpZipLib in your app to what Studio uses, the rules of assembly resolution in .NET allow you to manage such conflicts in various ways (see this MSDN article and associated pages: http://msdn.microsoft.com/en-us/library/yx7xezcf).

Of the possible ways you could use to handle your assembly resolution problem, I'd first try placing your updated version of ICSharpZipLib in a new subdirectory in the Studio installation folder, then adding a "dependentAssembly" node to your App.Config file and use a "codeBase" node inside that node to point the .NET loader to your alternative DLL location. This should work and means that you wouldn't need to rename any files.

If that failed to work, or if you fancy a solution that is entirely in-code, the slightly more complex way would be to handle the AssemblyResolve event for your application's AppDomain using your own custom logic to accomplish the same thing as I described above.

Does that help?

Hello Robert,

thanks a lot for getting back to me!

In the end of the day I want to keep the install process as simple as possible and I found that using Studio's own Ziplib version instead of deploying my own is much easier than anything else from renaming to changing build configurations.

Kind regards,

Tom

Hello Robert,

thanks a lot for getting back to me!

In the end of the day I want to keep the install process as simple as possible and I found that using Studio's own Ziplib version instead of deploying my own is much easier than anything else from renaming to changing build configurations.

Kind regards,

Tom

Ah, ok.

My concern was that you were relying on functionality in the more recent version that isn't there in the older one. The ability to re-target your app to the older version of the DLL should have been something I asked about first :)

Hi Robert,

fortunately, I use only the very basic functions of the library, so this was not a problem.

Regards,

Tom