mjs082969
asked on
Visual Basic .NET 2013: Version/Build Number Variable
I have been attempting to determine if there is a variable or object that can access that will provide the Version/Build number of my application. I have a command line application that generates a log file, and I would like to include this information there (so that I can be sure that the application being executed is the latest and greatest).
Thanks in Advance!
- Michael
Thanks in Advance!
- Michael
Randy Poole
You can use Application.ProductVersion
Actually that returns whats in the config. So use this instead:
Dim strMajorVersion, strMinorVersion, strBuildVersion, strRevisionVersion As String
strMajorVersion = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Major()
strMinorVersion = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Minor()
strBuildVersion = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Build()
strRevisionVersion = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Revision()
MsgBox("Version - " & strMajorVersion & "." & strMinorVersion & "." & strBuildVersion & "." & strRevisionVersion)
VB makes this a bit easier than C# does by way of the My namespace:
Dim majorVersion As Integer = My.Application.Info.Version.Major
Dim minorVersion As Integer = My.Application.Info.Version.Minor
Dim buildNumber As Integer = My.Application.Info.Version.Build
Dim majorRevision As Integer = My.Application.Info.Version.MajorRevision
Dim minorRevision As Integer = My.Application.Info.Version.MinorRevision
Randy, your first answer was OK.
The ProductVersion is not saved in the .config file. It is saved in the AssemblyInfo.vb file, that is usually not visible, but created from the information typed under Assembly Information, in the Application tab of the project's Properties window. When you compile the application, that information is recorded in the assemblies manifest. The .config file does not hold anything about the version, unless you use a custom version mechanism and record it in the Settings of the application or directly in the .config file.
You do not need to go through Reflection, or use My.Application. That are indirect routes to that information (sorry kaufmed, but My is simply a VB shortcut to framework classes, and it hides a lot of useful stuff). No need either to go through the Major, Minor and build properties to get the information unless you need to isolate the different parts.
The way I understand it, msj082969 simply wants to record the version number, and Application.ProductName returns a String, already in the right format for display or recording, that contains all these values in one call.
The ProductVersion is not saved in the .config file. It is saved in the AssemblyInfo.vb file, that is usually not visible, but created from the information typed under Assembly Information, in the Application tab of the project's Properties window. When you compile the application, that information is recorded in the assemblies manifest. The .config file does not hold anything about the version, unless you use a custom version mechanism and record it in the Settings of the application or directly in the .config file.
You do not need to go through Reflection, or use My.Application. That are indirect routes to that information (sorry kaufmed, but My is simply a VB shortcut to framework classes, and it hides a lot of useful stuff). No need either to go through the Major, Minor and build properties to get the information unless you need to isolate the different parts.
The way I understand it, msj082969 simply wants to record the version number, and Application.ProductName returns a String, already in the right format for display or recording, that contains all these values in one call.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
@kaufmed
You got me on that one. I did not read "command line application" as console, because most of my applications are Windows Applications that can be launched with parameters through a "command line". Such is the pain of speaking French. You miss these little nuances in your second language sometimes. You are probably right that this is a question about a console application.
As for the use of My, I always tell my students to skip that one, except for My.Settings and My.Resources. My might make things easier at first, but it hides too many good things to really be useful for serious development. I would rather lead any programmer to the "real" framework classes than telling them about My.
You got me on that one. I did not read "command line application" as console, because most of my applications are Windows Applications that can be launched with parameters through a "command line". Such is the pain of speaking French. You miss these little nuances in your second language sometimes. You are probably right that this is a question about a console application.
As for the use of My, I always tell my students to skip that one, except for My.Settings and My.Resources. My might make things easier at first, but it hides too many good things to really be useful for serious development. I would rather lead any programmer to the "real" framework classes than telling them about My.