how to compare dll files

I have a post-build script after building my c# project that will place one of the dll files in a specific directory. This dll is saved in SVN. My question is, is there a way that when building my project, it knows that this dll has not changed and would know not to be copied over to the directory so the there will not be a modified copy for the SVN?开发者_开发知识库

Why are you putting dlls that you build into svn?

EDIT

You should figure out a better way to do this - like have an installer or an ftp server somewhere where developers can get your DLLs. It is a really bad idea to put your derived works into svn. Really bad.

The quick and easy way is to stat both files and compare their modification times -- only copy the file if the DLL in the destination directory is older than the one you're copying.

A more robust but slower way is to use any number of diff programs to compare the two DLLs byte-for-byte.

SVN should already take care of this for you. If there are really no differences between the files and you replace one with the other, SVN will not consider the file to be "modified," even if it has a new timestamp. SVN keeps around a base revision of the file and uses diff itself to see which files need to be committed. So you can just always copy the dll and SVN will take care of the rest.

Try to commit anyway and see if SVN agrees with your graphical interface.

If it tries to commit anyway, then whatever is building the file really is including some different information every time (maybe a time stamp or something). You may want to actually commit since that file is different. You can check your compile options to see if it is including some sort of time stamp, but if you can't find such an option, it will be hard to tell if the changes to the dll are meaningful or just some compiler meta-data.

Unless I'm misunderstanding your question, there's nothing you need to do. If the file isn't modified SVN knows this and won't commit.

Edit: You've clarified in answer to Tim that you're doing this to save other devs the trouble of building. This is the wrong way to do it. Source control should not be used to hold binaries that are output of the source. Instead you should:

1. get continuous integration working on your tree
2. send all output from 1. to a a common share
3. tell all devs to look on this share if they don't want to build something

It is OK to check in binaries into subversion. The reason for that is that the downstream user (QA or user) may not have the environment to build from source code. They are also not interested in building from source code.

The issue here is a building management issue - when you release that DLL, and how do you track back to the source if QA finds a problem with your DLL.

Timestamp is not a reliable method.

You need to have something in building management for this purpose. In my project, our building script locates the max revision number of the files involved (note that this is not the current revision number, as you should be able to build in the future but produce the same results). It then stamps this number to the DLL's version resource. After we are satisfied with the result, we release it by manually copying the binary into a folder in subversion and check in.

If QA finds a bug, we can always go back to the state that built the DLL (by looking up the version number) and find where the problem is.