Hummm.. IMO it is a difficult strategy
Not really. I think I've figured out a way to do it now.
I'm not sure if this is the best or simplest way, but it should do the job.
In the Setup Project I can add a registry entry, and set it's value to
[ProductVersion].
My application can then then read this value from the registry.
plus this is more or less meaningless.
It is obviously potentially useful information, otherwise why would they
provide a mechanism for getting this information for click-once deployed
applications?
>
If we take things the other way round , what is the problem with using the
assembly version for your main assembly ?
i) The main assembly may not necessarily change between different released
versions of the system as a whole.
ii) The main assembly may get re-built numerous times during development,
and so the version numbers can start getting big.
iii) There may not be one single 'main' assembly.
>
Your main code have a version number and IMO this is what matters (you can
control this number if
needed by adding an "Assembly Info" file check this in "add new items").
Remember that ClickOnce allows to deploy under a well defined and
controlled process while a setup program could be erased and is not really
part of your application so my personal preference would be really to
avoid using the setup program version to as the version of my main EXE
file...
I have been using clickonce during development of my current system. It is
very useful for producing a quick and simple install for a simple solution,
but it has a number of drawbacks, relating to installing addition files,
multiple executables, etc... It tends to hide files away in some obscurely
named hidden system folders where it's difficult to find it. It requires
separate re-installation for different users on the same machine, etc... The
Setup Project deployment, seems overall much more flexible, and once the
system goes out to customers the web deployment is not so desirable, as
we'll likely distribute the system via CD anyway.
The deployment version number is extremely useful, as it means the user can
look at one version number, and compare this against the latest version, to
see if they are up-to-date, without having to check individual version
numbers on all the different assemblies (of course they can do that too if
necessary).
>
If you still want to go this route :
- the setup program doesn't run when your application runs. So it's left
you with reading this value from the (EXE file),
Except that each exe file has a different number and these may or may not
change between releases.
from the registry
That's the aproach I have been exploring
where it would have been previously placed or perhaps using WMI from the
installed products database
That sounds interesting. I might look into that.
>
In all cases this is IMO not reliable (what if an admin replaced your EXE
file by hand ?).
The assembly version numbers would come in useful here. I haven't said I
shan't be using those as well.
>
For now I see only benefits for using the version of the main EXE file and
only problems with using the setup program version...
I plan to use both, and don't see any problems. I can use whichever is
appropriate in the circumstances. For the version number displayed on the
splash screen the setup version number is more appropriate for this system.
I didn't plan on getting into a debate about this, I just hoped someone
could explain how I could get at this information.
>
Good luck.
Thanks :-)
