Smart deployment of dll's in .net

views:

answers:

+3 Q:

Smart deployment of dll's in .net

We currently have an application that is roughly 22 megs total. Our current deployment methodology is deploying the application to each of our clients servers and using a small update program go and copy all of the files to the local pcs if a new version is available. The issue is that 22 megs is taking a bit more time than we would like to push updates. Especially since we do an update every 2 weeks. We are looking for a way to cut that time down.

Our initial thought was for the local pcs to only copy the dlls that have been changed since the last time we deployed. We are having some trouble with this as timestamps make it difficult to take accurate hashes of the file for comparisons. Versions numbers could possibly work ok, but we would have to find a way to only version a file if it's code has changed.

Just wondering if anybody has had success or recommendations for handling a similar process.

+1 A:

Timestamps have no effect on hashes, but updating the version number would certainly change the hash.

Steven Sudit 2010-07-26 13:51:39

If I open visual studio and open a new winforms application. I then compile and end up with WindowsFormsApplication1.exe. I then rename that to WindowsFormsApplication2.exe. I recompile without making any changes. Which creates a WindowsFormsApplication1.exe again. If I compare those files either by an MD5 or just with a diff tool like winmerge, they are different. Maybe it is not a timestamp but something is compilation dependant. THe project file is set for AssemblyVersion 1.0.0.0 and AssemblyFileVersion 1.0.0.0 so there is not version change based on time. Any thoughts?

2010-07-26 14:05:54

At this moment, I can't offer an explanation, but I can offer confirmation. I used a new console project, in release mode. The assembly and file version numbers did not change, but a few other bytes did.

Steven Sudit 2010-07-26 14:10:57

The compiled file contains a timestamp.

Will Dean 2010-07-28 09:47:29

@Will: Ugh, that's an anti-feature. Is there some way to set the timestamp after the build to some fixed value so that all identical builds are binary-equivalent?

Steven Sudit 2010-07-28 13:37:10

Anti-feature? Maybe, but then it gives an O(1) way to tell if a file *might* be different, whereas your hash is an expensive way to be sure that two files are the same, which is not the same test. The timestamp is part of the Windows Portable Executable format - see http://www.microsoft.com/whdc/system/platform/firmware/pecoff.mspx (or lots of other articles on the web) if you really want to poke around with it

Will Dean 2010-07-28 13:53:46

Another thought - bear in mind that MS tools use the timestamps to match-up PDB files and their associated binaries, so if you play games with timestamps you might come across this. Most debuggers can be told to ignore timestamp mismatches, though.

Will Dean 2010-07-28 13:54:55

@Will: A PE header has a checksum, and a .NET assembly with a strong-name has a signed hash, so that's not really the issue. But, sticking to the topic, the only time I'd want to standardize the timestamp is for official builds. Having said that, the document you linked would make me nervous about even that, since the delay-load directory table references the timestamp of early-bound DLL dependencies.

Steven Sudit 2010-07-28 14:25:43

See if ClickOnce deployment will meet your needs.

HappyCoder4U 2010-07-28 09:40:08

I'm looking into this as an option (if for no other reason I had always intended to) but at first glance it doesn't appear that it will meet our needs.

2010-08-04 14:13:04

+1 A:

We do a lot of pushing files internationally, to pieces of equipment we're working on remotely.

Our solution was to create a custom tool to do this (it actually does lots of other stuff), which does a sort of 'delta copy' - i.e. only pushes the parts of files which have changed.

That frees you from worrying about file timestamps, etc - the file you end up with at the far end is byte-for-byte identical to the near one, but if the only thing which as actually changed is an internal timestamp, then very little data will need to move across the wire.

We used an algorithm based roughly on the way rsync works ( http://samba.anu.edu.au/rsync/tech_report/ ), though we wrote it from scratch in C#.

However, in your situation, it might actually be that the effort of setting up rsync and a batchfile to invoke it with the right environment/options would be simpler. There is a Win32 version of rsync here: http://www.itefix.no/i2/node/10650 which I use successfully.

Will Dean 2010-07-28 09:53:35

That's very practical advice.

Steven Sudit 2010-07-28 13:37:53

This does sound like possibly the best option. I'm not a huge fan of having to hand roll things if possibl so maybe i will look into just deploying rsync. Thanks.

2010-08-02 12:40:12

Looks like this would work for us, I'm not in charge of the final decision but I would agree with Steve, this "very practical advice".

2010-08-04 14:11:23

ansaurus

tags:

views:

answers:

Smart deployment of dll's in .net

related questions