I just upgraded to the July 24 build. A few questions/issues.

1. Is there a reason the installer doesn't upgrade from the previous install? I had to uninstall the previous install.

2. In Add/remove programs the support info shows as version 1.0.0.

3. Is there an Erratta of changes from build to build of the same version?

4. The designer reports version 2.0.0.0 July 24th. This is the same version as the original release. Is this only the designer version? (Also, the file is dated July 26th, why the difference?)

5. How are DLL's reved? For instance the SD.LLBLGen.Pro.DebugVisualizers.dll from the original release and July seem to have the same File and Assembly Version but they have different dates. Did this DLL change? How can I tell if a runtime DLL changed from release to release?

6. Are the designer and runtime DLL versions kept in sync?

7. Is there somwhere on your web site that lists the most recent release of each item designer / runtimes / templates, etc?

Thanks, BOb

pilotboba wrote:

I just upgraded to the July 24 build. A few questions/issues.

1. Is there a reason the installer doesn't upgrade from the previous install? I had to uninstall the previous install.

We use the vs.net deployment project msi builder, which is pretty simple. To avoid mismatches between files, dangling files etc. we use the uninstall first option. You don't need to download the installer every time though. If you want to upgrade the runtimes, just download the runtimes archive.

1. In Add/remove programs the support info shows as version 1.0.0.

Thanks, I'll change that.

1. Is there an Erratta of changes from build to build of the same version?

Yes, please check in the customer area -> Changelogs at the left. You can browse per element of the system the changes per build.

1. The designer reports version 2.0.0.0 July 24th. This is the same version as the original release. Is this only the designer version? (Also, the file is dated July 26th, why the difference?)

The designer consists of multiple dlls. The date reflected in the about box (in your case, July 24th) is the date the last change was made to the code of the complete DESIGNER. Designer consists of: - .exe - applicationcore assembly - generatorcore assembly - dbdrivercore assembly

Because vs.net sometimes changes form files which then could lead to a new build of the .exe, even though nothing has changed, the date can get out of sync with the .exe filedate, also because the automated buildsystem which builds and packs the designer and installer builds the .exe before the installer is packed.

1. How are DLL's reved? For instance the SD.LLBLGen.Pro.DebugVisualizers.dll from the original release and July seem to have the same File and Assembly Version but they have different dates. Did this DLL change? How can I tell if a runtime DLL changed from release to release?

You should focus on the file version. Revisions are done through the fileversion, not the assembly version. This because all dlls are strongly named and it would otherwise make xcopy deployment impossible. (long story, trust me, versioning through the fileversion is better, MS uses that too with fixes for .net)

The file date can be different, because that's the date the dll was build right before it was added to the installer, IF it had to be rebuild.

If there was a change in some element of the system (docs, code generator, runtime libs, designer, templates etc.), the automated build system will build that element from scratch and will use the new files in the installer. If there wasn't a change in the element, it will re-use the files from the previous installer.

It can be a fix is made for example 2 days before it's released. This can lead to the builddate (== fileversion date) being different than the filedate of the dll.

1. Are the designer and runtime DLL versions kept in sync?

Feature wise, yes: the designer should be useful to the runtimes of the same major/minor version. So 2.0 designer works with 2.0 runtime libs.

1. Is there somwhere on your web site that lists the most recent release of each item designer / runtimes / templates, etc?

See 3 above

Otis wrote:

You should focus on the file version. Revisions are done through the fileversion, not the assembly version.

Ok, so even though the dates are different, but the file versions are the same I can assume no change has been made? Although I'm a bit confused as to why your builder would rebuild the DLL if no changes were made.

Otis wrote:

This because all dlls are strongly named and it would otherwise make xcopy deployment impossible. (long story, trust me, versioning through the fileversion is better, MS uses that too with fixes for .net)

Been there, done that, ripped hair out, got the T-shirt! Totally agreed.

BOb

pilotboba wrote:

Otis wrote:

You should focus on the file version. Revisions are done through the fileversion, not the assembly version.

Ok, so even though the dates are different, but the file versions are the same I can assume no change has been made? Although I'm a bit confused as to why your builder would rebuild the DLL if no changes were made.

If I do a release on July 10th, and then fix a bug in the runtimes on July 11th, and release a new release on July 12th, the fileversion is july 11th, the dll itself is created on July 12th, as the build is made on july 12th.

Otis wrote:

This because all dlls are strongly named and it would otherwise make xcopy deployment impossible. (long story, trust me, versioning through the fileversion is better, MS uses that too with fixes for .net)

Been there, done that, ripped hair out, got the T-shirt! Totally agreed. BOb

Hehe

Otis wrote:

If I do a release on July 10th, and then fix a bug in the runtimes on July 11th, and release a new release on July 12th, the fileversion is july 11th, the dll itself is created on July 12th, as the build is made on july 12th.

Ok, understood. Now, let me ask a simple yes or no question.

Original 2.0.0.0 release contained file:

Name: SD.LLBLGen.Pro.DebugVisualizers.dll Assembly Version: 2.0.0.0 File Version: 2.0.0.60701 Date (modified): July 1, 2006

July 24th relase contained file:

Name: SD.LLBLGen.Pro.DebugVisualizers.dll Assembly Version: 2.0.0.0 File Version: 2.0.0.60701 Date (modified): July 26, 2006

The files above have same file name, assembly version and file version, but they have a different date. Was there a change to this file?

Thanks, BOb

No, and that's illustrated by the fileversion.

The dll modified date is changed, because it's rebuild using a full build of the complete runtime libs which have changed since july 1st