Versioning our DLLs

[Rod Widdowson]

Mostly Scott,

I happened upon an oddity yesterday in that messages.dll doesn't carry a version.  This dll is where the various translations (well
US English) for our messages go - the ones that end up in the event log.  So long as we are careful about numbering (always add to
the end of a series) the only side effect of being out of date is that the event log cannot print anything - but the event carry
text anyway so you know what's going on.  Plus of course absent a version the date is used.  So all in all I don't really care and I
don't think that we should.  Should we?

It did however make me realize what I knew already that all of our executables (DLLs and EXE files) has an associated resource (.rc)
file to carry the version and that someone has to go in there as part of a release and bump the values in the 36 files.

Do we think that there is any value in using a common header file and including it in the resource files?  It would save time and
risk during the release process.

Of course there are situations in which we might want to modify the version values per dll, but I don't think that they are common
or insuperable.

I currently have an example in that if we ship the IIS7 Native support in its own installer we will want to ship an updated ISAPI
(IIS6) dll so that we can ensure that both are not registered - so that would require that the ISAPI dll be revised.  But there is
nothing to say that we couldn't do that globally (set the global revision to 2.6.0.1) after all it's only the ISAPI dll we will be
shipping (plus the messages dll if that did carry a version).

The IIS7 dll will need its own revision (it's currently set to be 0.0.1.255) but that’s fine - we can align the resource before we
start shipping full versions with it (3.0).

Thoughts?

Rod