By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,943 Members | 1,875 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,943 IT Pros & Developers. It's quick & easy.

Displaying Version Number

P: n/a
I have been using this code to display the version number, and this has
worked well, but I am now changing from using the ClickOnce publishing to a
proper setup project, and this no longer works.

If System.Diagnostics.Debugger.IsAttached = False Then
Version.Text = "Version : " &
My.Application.Deployment.CurrentVersion.ToString( )
Else
Version.Text = "Debug Mode"
End If

Any suggestions?

TIA
Phil
Jun 27 '08 #1
Share this Question
Share on Google+
14 Replies


P: n/a
See for example My.Application.Info.Version.ToString

--
Patrice
"Phil" <N/Aa écrit dans le message de groupe de discussion :
w-******************************@posted.plusnet...
I have been using this code to display the version number, and this has
worked well, but I am now changing from using the ClickOnce publishing to
a
proper setup project, and this no longer works.

If System.Diagnostics.Debugger.IsAttached = False Then
Version.Text = "Version : " &
My.Application.Deployment.CurrentVersion.ToString( )
Else
Version.Text = "Debug Mode"
End If

Any suggestions?

TIA
Phil
Jun 27 '08 #2

P: n/a
See for example My.Application.Info.Version.ToString

That only gives the version of the individual assembly which is not the same
thing.
Jun 27 '08 #3

P: n/a
My understanding is that you don't use anymore clickonce so AFAIK you can't
have the deployment version if this is what you are after. (do you have an
error because deployment is nothing. You could also use the
IsNetworkDeployed property to see if this is click once installation).

A a side note .NET 3.5 SP1 (currently as a beta) seems to introduce new
capabilities for ClickOnce deployment but if you don't use ClickOnce anymore
you'll have to use the version of your app (you can also control this by
hand in an assemblyinfo file).

--
Patrice

"Phil" <N/Aa écrit dans le message de groupe de discussion :
3c******************************@posted.plusnet...
>See for example My.Application.Info.Version.ToString

That only gives the version of the individual assembly which is not the
same thing.
Jun 27 '08 #4

P: n/a

"Patrice" <http://www.chez.com/scribe/wrote in message
news:DC**********************************@microsof t.com...
My understanding is that you don't use anymore clickonce so AFAIK you
can't have the deployment version if this is what you are after. (do you
have an error because deployment is nothing.
Yes, that is exactly the issue. The deployment object is nothing because it
is only relevant for clickOnce deployment. I am looking for a way to get the
equivalent information from the setup project that I am now using instead of
the clickOnce deployment.
You could also use the IsNetworkDeployed property to see if this is click
once installation).
I have decided I need a little more flexibility than the click once system
allows, so am developing a setup project instead, so I can safely assume now
that it will not be a click once deployment.
>
A a side note .NET 3.5 SP1 (currently as a beta) seems to introduce new
capabilities for ClickOnce deployment
Something for the future perhaps.
but if you don't use ClickOnce anymore you'll have to use the version of
your app (you can also control this by hand in an assemblyinfo file).
My application though consists of a number of different assemblies, each of
which will have their own version number.
I guess it's the version number of the setup project that I want to display.
Is there any mechanism built-in to allow me access to this from within the
deployed assemblies? or will I need to somehow build this functionality into
the setup project myself?

Thanks for your assistance.
Phil.
Jun 27 '08 #5

P: n/a
On May 14, 2:29*pm, "Phil" <N/Awrote:
"Patrice" <http://www.chez.com/scribe/wrote in message

news:DC**********************************@microsof t.com...
My understanding is that you don't use anymore clickonce so AFAIK you
can't have the deployment version if this is what you are after. (do you
have an error because deployment is nothing.

Yes, that is exactly the issue. The deployment object is nothing because it
is only relevant for clickOnce deployment. I am looking for a way to get the
equivalent information from the setup project that I am now using instead of
the clickOnce deployment.
You could also use the IsNetworkDeployed property to see if this is click
once installation).

I have decided I need a little more flexibility than the click once system
allows, so am developing a setup project instead, so I can safely assume now
that it will not be a click once deployment.
A a side note .NET 3.5 SP1 (currently as a beta) seems to introduce new
capabilities for ClickOnce deployment

Something for the future perhaps.
but if you don't use ClickOnce anymore you'll have to use the version of
your app (you can also control this by hand in an assemblyinfo file).

My application though consists of a number of different assemblies, each of
which will have their own version number.
I guess it's the version number of the setup project that I want to display.
Is there any mechanism built-in to allow me access to this from within the
deployed assemblies? or will I need to somehow build this functionality into
the setup project myself?

Thanks for your assistance.
Phil.
Phil,
I'm not sure if it's your solution, but have you considered
System.Reflection namespace that provides GetExecutingAssembly method
to get info about current assembly:

System.Reflection.Assembly.GetExecutingAssembly()G etName().Version.ToString()

Thanks,

Onur Güzel
Jun 27 '08 #6

P: n/a
On May 14, 2:47*pm, kimiraikkonen <kimiraikkone...@gmail.comwrote:
On May 14, 2:29*pm, "Phil" <N/Awrote:


"Patrice" <http://www.chez.com/scribe/wrote in message
news:DC**********************************@microsof t.com...
My understanding is that you don't use anymore clickonce so AFAIK you
can't have the deployment version if this is what you are after. (do you
have an error because deployment is nothing.
Yes, that is exactly the issue. The deployment object is nothing becauseit
is only relevant for clickOnce deployment. I am looking for a way to getthe
equivalent information from the setup project that I am now using instead of
the clickOnce deployment.
You could also use the IsNetworkDeployed property to see if this is click
once installation).
I have decided I need a little more flexibility than the click once system
allows, so am developing a setup project instead, so I can safely assumenow
that it will not be a click once deployment.
A a side note .NET 3.5 SP1 (currently as a beta) seems to introduce new
capabilities for ClickOnce deployment
Something for the future perhaps.
but if you don't use ClickOnce anymore you'll have to use the version of
your app (you can also control this by hand in an assemblyinfo file).
My application though consists of a number of different assemblies, eachof
which will have their own version number.
I guess it's the version number of the setup project that I want to display.
Is there any mechanism built-in to allow me access to this from within the
deployed assemblies? or will I need to somehow build this functionality into
the setup project myself?
Thanks for your assistance.
Phil.

Phil,
I'm not sure if it's your solution, but have you considered
System.Reflection namespace that provides GetExecutingAssembly method
to get info about current assembly:

System.Reflection.Assembly.GetExecutingAssembly()G etName().Version.ToString*()

Thanks,

Onur Güzel- Hide quoted text -

- Show quoted text -
Correcting, missed the "dot" before GetName:

System.Reflection.Assembly.GetExecutingAssembly(). GetName().Version.ToString*
()

Thanks,

Onur
Jun 27 '08 #7

P: n/a
But you could deploy an update but just replacing the exe file for example.
IMO your best bet if you are not using clickonce (i.e. you have less control
on the publication/update process on the client machine) is to use the
version number fo the main assembly (as suggested earlier).

If needed you could even get the version number of each and every assembly
that compose your application...

--
Patrice

"Phil" <N/Aa écrit dans le message de groupe de discussion :
Be******************************@posted.plusnet...
>
"Patrice" <http://www.chez.com/scribe/wrote in message
news:DC**********************************@microsof t.com...
>My understanding is that you don't use anymore clickonce so AFAIK you
can't have the deployment version if this is what you are after. (do you
have an error because deployment is nothing.

Yes, that is exactly the issue. The deployment object is nothing because
it is only relevant for clickOnce deployment. I am looking for a way to
get the equivalent information from the setup project that I am now using
instead of the clickOnce deployment.
>You could also use the IsNetworkDeployed property to see if this is click
once installation).

I have decided I need a little more flexibility than the click once system
allows, so am developing a setup project instead, so I can safely assume
now that it will not be a click once deployment.
>>
A a side note .NET 3.5 SP1 (currently as a beta) seems to introduce new
capabilities for ClickOnce deployment

Something for the future perhaps.
>but if you don't use ClickOnce anymore you'll have to use the version of
your app (you can also control this by hand in an assemblyinfo file).

My application though consists of a number of different assemblies, each
of which will have their own version number.
I guess it's the version number of the setup project that I want to
display. Is there any mechanism built-in to allow me access to this from
within the deployed assemblies? or will I need to somehow build this
functionality into the setup project myself?

Thanks for your assistance.
Phil.
Jun 27 '08 #8

P: n/a
But you could deploy an update but just replacing the exe file for
example. IMO your best bet if you are not using clickonce (i.e. you have
less control on the publication/update process on the client machine) is
to use the version number fo the main assembly (as suggested earlier).

If needed you could even get the version number of each and every assembly
that compose your application...
True, and I do intend to provide something on an about page listing all the
individual assembly versions, but for the main splash screen I just want the
overall version of the system. There is a version number in the setup
project, I'm sure there must be a way of making this available to the
installed aplication.
Jun 27 '08 #9

P: n/a
I'm not sure if it's your solution, but have you considered
System.Reflection namespace that provides GetExecutingAssembly method
to get info about current assembly:
Thanks, but it's not the assembly version that I'm after. I want to display
the version of the setup project that was used to install the assembly.
For click-once deployed applications I can use:
My.Application.Deployment.CurrentVersion
I'm looking for the equivalent when a Setup Project has been used.
Jun 27 '08 #10

P: n/a
Hummm.. IMO it is a difficult strategy plus this is more or less
meaningless.

If we take things the other way round , what is the problem with using the
assembly version for your 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...

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), from the registry where it
would have been previously placed or perhaps using WMI from the installed
products database

In all cases this is IMO not reliable (what if an admin replaced your EXE
file by hand ?).

For now I see only benefits for using the version of the main EXE file and
only problems with using the setup program version...

Good luck.

--
Patrice

"Phil" <N/Aa écrit dans le message de groupe de discussion :
x4******************************@posted.plusnet...
>I'm not sure if it's your solution, but have you considered
System.Reflection namespace that provides GetExecutingAssembly method
to get info about current assembly:

Thanks, but it's not the assembly version that I'm after. I want to
display the version of the setup project that was used to install the
assembly.
For click-once deployed applications I can use:
My.Application.Deployment.CurrentVersion
I'm looking for the equivalent when a Setup Project has been used.
Jun 27 '08 #11

P: n/a
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 :-)
Jun 27 '08 #12

P: n/a
No problem, you are anyway best placed to see if reading something you
previously wrote to the registry fits your needs and as you said you'll
backup this with a detailed version report so being aware of this limitation
is really the key here...

--
Patrice

"Phil" <N/Aa écrit dans le message de groupe de discussion :
ib******************************@posted.plusnet...
>
>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 :-)
Jun 27 '08 #13

P: n/a
Hi Phil,

I think your current solution which add a registry value as the productcode
of MSI package is the reasonable approach. Since those application
assemblies may have different version, you need to use some other identity
number as product version. BTW, have you considered use a custom version
code(stored in a data file with your application assemblies) to provide
version number defined by yourself?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
Jun 27 '08 #14

P: n/a
Hi Phil,

Any progress on this or still need any other helps?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
>Content-Transfer-Encoding: 7bit
From: st*****@online.microsoft.com (Steven Cheng [MSFT])
Organization: Microsoft
Date: Thu, 15 May 2008 06:31:04 GMT
Subject: Re: Displaying Version Number
>
Hi Phil,

I think your current solution which add a registry value as the
productcode
>of MSI package is the reasonable approach. Since those application
assemblies may have different version, you need to use some other identity
number as product version. BTW, have you considered use a custom version
code(stored in a data file with your application assemblies) to provide
version number defined by yourself?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

================================================= =
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ault.aspx#noti
f
>ications.
Jun 27 '08 #15

This discussion thread is closed

Replies have been disabled for this discussion.