I would like to suggest that you change the way you version the builds. I notice that there are several bug fixes that have been rolled out all under the build 1.0.2005.1 and dated Nov 30th (from help about) even though I know I'm running a later build than the 30th. I can't remember which one though. I would recommend that you also put a build under the help about so that you would have

Version: 1.0.2005.1 Final Released On: 30th November (preferably updated to actual release date) Build: XXXXXX

this way we could determine if we are running the latest vesion with all the bug fixes

Chris

Angus wrote:

I would like to suggest that you change the way you version the builds. I notice that there are several bug fixes that have been rolled out all under the build 1.0.2005.1 and dated Nov 30th (from help about) even though I know I'm running a later build than the 30th. I can't remember which one though. I would recommend that you also put a build under the help about so that you would have

We don't do that, because the system consists of various parts. To avoid requiring the user to download a complete installer again for a bugfix in a runtime lib or template for example, we use one major version, 1.0.2005.1, and for each package a separate version.

The designer is currently November 30th build, though the runtime libs are on build 12162005. Also, the designer isn't used at runtime and vice versa, so if a bugfix is made for the runtime libs, it's not required to update the designer, and if the designer gets a bugfix, the runtime libs can stay the same.

In the past we had runtime upgrades (1.0.2004.1 for example) and the designer stayed on teh same version, but that's not going to happen anymore.

Version: 1.0.2005.1 Final Released On: 30th November (preferably updated to actual release date) Build: XXXXXX

this way we could determine if we are running the latest vesion with all the bug fixes

If there's no newer designer, you ARE running with the latest version, of the designer. Since several components aren't related to eachother, it's not necessary to bump their build when a given component gets a new build because of a bugfix, for example, the templates don't need a newer version if a driver of a given db gets a bugfix.

In the customer area you can browse our changelogs, per package and component. You should look at it this way: if you encounter a problem, check if you're using the latest version of that component causing the problem AND if a newer version is available. If you have a problem in the designer, upgrading the runtime libs won't have any effect and vice versa.

HOWEVER, I know what you mean, and we hope to address that in v2.0 with more / clearer / easier information about versions of the various components of the system. Though as the system itself is build in such a way that it doesn't rely on a version of some component, you can for example use 1.0.2004.1 templates with the 1.0.2005.1 designer, so the designer (or other place where version info is easily obtainable) can give a picture of the versions of the used components, but that doesn't have to be correct. For example, if you generate code and in your vs.net project you reference runtime libraries you build yourself, or you downloaded from the website because there was an update, you're actually using a different version, but teh designer can't determine that, because it's not related to the generated code you produced.

Also: if you DON'T run into a problem, don't fix it, because it's not broken. We release often, as we don't want to let our customers wait for a fix, but that also means that builds for components are released often, but that DOESN'T mean you should download all our builds. Just download the ones which fix a problem for you. We hop with the changelog browser/search application on our website that you can easily check if you need to upgrade or not.

HOWEVER, I know what you mean, and we hope to address that in v2.0 with more / clearer / easier information about versions of the various components of the system.

Thanks for the explanation. I see see what understand. How is this for a suggestion then???

Could you show through reflection on the help about screen, what versions of the assemblies are currently installed in the Solutions Design sub direcories.

Just a thought.

Keep up the great work

Chris

Jeff Attwood (sp.?) did a generic about box that shows all assemblies and their versions. I'm sure he wasn't the first one, but it's decent and in fact I converted the source to C# and am going to use it in a couple of production apps.

Angus wrote:

HOWEVER, I know what you mean, and we hope to address that in v2.0 with more / clearer / easier information about versions of the various components of the system.

Thanks for the explanation. I see see what understand. How is this for a suggestion then???

Could you show through reflection on the help about screen, what versions of the assemblies are currently installed in the Solutions Design sub direcories.

That's indeed what we're planning for v2.0.

We're still undecided if we'll go for version numbers in the strong name or not. We now use fileversion numbers for the build versions, to avoid breaking code (as a recompile against another third party lib for examle already bumps up the version in that respect, which causes the customer to recompile also), though that doesn't seem to be the way it should be done, however there's no clean solution for 'middle-man' assemblies like our runtimes (which reference other assemblies like the ado.net providers). So it will probably stay as it is now, and we'll add a class to the dlls which explains the version of the dll so it can be harvested by a tool.

Otis wrote:

We now use fileversion numbers for the build versions, to avoid breaking code...(snip)

I think that's the right way to go.

The assembly version should only be changed if there is an API change. (Of course there are possible exceptions to this.)

Although, do you know if a DLL is compiled with a reference to a SN assembly if probing has to match the full quartet of version numbers, or just the first three? I never tried it but thought that it only bound to the first three.

Isn't there also a way in the config to tell and app to use version 2.5.* of an assembly?

BOb

All .Net assemblies have a version number consisting of four parts: <major>.<minor>.<build>.<revision>. The full .Net Framework requires all four parts of the version number to match in order to satisfy a reference to a strong named assembly.

In contrast, the .Net Compact Framework allows the revision portion of the version number to “float” when resolving references to strong named assemblies

The default version binding behavior can be customized on the full .Net Framework by specifying “binding redirects” in XML configuration files

<?xml version="1.0" encoding="utf?8" ?>
 <configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
       <dependentAssembly>
         <assemblyIdentity name=" ReferencedFile"
                           publicKeyToken="99ab3ba45e0b54a8"
                           culture="en-us" />
         <bindingRedirect oldVersion="1.0.0.0"
                          newVersion="2.0.0.0"/>
       </dependentAssembly>
          <publisherPolicy apply="no">
      </assemblyBinding>
   </runtime>
</configuration>

pilotboba wrote:

Otis wrote:

We now use fileversion numbers for the build versions, to avoid breaking code...(snip)

I think that's the right way to go.

The assembly version should only be changed if there is an API change. (Of course there are possible exceptions to this.)

Although, do you know if a DLL is compiled with a reference to a SN assembly if probing has to match the full quartet of version numbers, or just the first three? I never tried it but thought that it only bound to the first three.

Isn't there also a way in the config to tell and app to use version 2.5.* of an assembly? BOb

No, it uses all 4 parts as walaa says, which is very unfortunate. You also can't say: use any latest revision. So if you have 1.0.2005.*, and you create a new revision, you effectively create a new strong name, which won't match the app's reference. So teh app's config file needs a redirect or a policy file has to be installed.

It's very unfortunate. Also, MS suggests you only need policy files for security reasons, so effectively never bump the version number. Which is what they indeed do: they don't bump the version number for fixes, they just increase the file version number, which isn't something related to .NET.

MS hasn't thought this through. For middle-man assemblies like our runtimes (which sit in the middle between a provider and an end-app) it's impossible to work with the current system, as by the book we should recompile and use a different build number (and strong name) if the reference of a .net provider changes, though that requires a recompile (and redeployment!) of all compiled apps out there using the runtime libs, while it's completely unnecessary. It was a good attempt to do something about versioning, but it didn't solve a single thing.

Recently I got flamed by two people in teh general .net newsgroup, one was Richard Grimes, which told me I was re-creating DLL hell by propagating people should use the assemblyfileversion attribute for version numbers for builds and keep the assembly version number the same for api version.

They couldn't understand the problems it creates, and rehashed what MS states (but does't do, MS does the same as we do: keep the assembly version the same and the file version changes). After I explained what happens if an end assembly changes (which a middle man assembly references), none of the two replied. How typical, as being confronted with the raw problem, every single person I've spoken to about this problem is without a solution.

It's a tough problem though. click-once doesn't work with assembly fileversion for example, so you need to bump assembly version numbers. But then again, assembly signing is something not a lot of people do, and the asp.net runtime developers even didn't consider it necessary to support strong named assemblies in the bin folder..