3

When I checkout files from tfs the modified date of the files get set to "now" (checkout date and time).

This behaviour, however, is not wanted from me for files that belong to purchased 3rd party controls from other software vendors. If I distribute these files to customers then I can't reliably check which version of the file is installed if there is a problem.

I know that tfs 2010 will have an option where you can select the desired strategy, but until then I need a different workaround. anyone else had this problem? how did you solve, or get around it. any advice is welcome, thanks!

10 Rep
  • 2,217
  • 7
  • 19
  • 33
Sonic Superfly
  • 103
  • 1
  • 6
  • 3
    In what form are your third party controls supplied? If in DLL form then isn't the DLL version number a better indicator of the controls version than the file date? – ChrisBD Dec 21 '11 at 16:39
  • Right, but since there is always more than one file involved and its also not always a DLL, it can be kinda tricky to distinguish. Also it seems a little strange that two customers could have the exact same binary file, but with two different dates. Especially when i redistribute files that were not built by my company i should not mess with the date. Anyways - threre´s a lot of reasons for why i would not like to change the date and was just wondering how others handle this. – Sonic Superfly Dec 22 '11 at 09:53

1 Answers1

0

One possible work around is to look at wrapping all third party files and controls within a class library and embedding any binary files within either that project resources or assembly file, you can then extract them as required when the program runs (example here).

As your project is under version control you will know exactly which file is in use by the version number of your project.

ChrisBD
  • 9,104
  • 3
  • 22
  • 35