I agree, there is some cost to doing the hashing, but MD5 should be fast enough. Doing a local file system copy is really fast, I don't think we should worry about that too much. Anyway, we have to do the copy to avoid locking issues when a new version is sent out, or more then one AppDomain using the dll is started up, or there is more then one version of a dll.
Regards, Dusty _____ From: Matt Valerio [mailto:[EMAIL PROTECTED] Sent: Friday, September 14, 2007 3:23 PM To: Anton Melser Cc: Dusty Candland - eonBusiness; [email protected] Subject: Re: [Alchemi-developers] ideas for a dll cache On 9/14/07, Anton Melser <[EMAIL PROTECTED] > wrote: > So, yes, Dusty's idea of implementing a hash of the assembly (esp. if it's > unsigned) is a good idea. How exactly would that work? I did think of that... but copying and md5 summing a dll costs... I suppose the problem is that I have no idea how much. I had developped an md5 summing solution for dvds at my last job, and it was hell slow but then again we aren't dealing with 4 gig dlls! Anyway, keep the ideas flowing, and when things seem sorted I will have a go. Cheers Anton Well, there is System.Security.Cryptography.MD5CryptoServiceProvider class. I believe we have a helper function in Alchemi.Core.Utils. Perhaps we should do some benchmarks? About the copying part....We may not even need to copy the DLLs if we just set the CodeBase of the AppDomain to the location of the AAC. I dunno, would that be a security risk? I do think that the separation of code between threads is necessary. Nevermind :) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Alchemi-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/alchemi-developers
