Mixing
How to get .exe file version number from file path
I am using .Net 3.5/4.0 with code in C#.
I am trying to get a version number of an exe file on my C: drive.
For example path is: c:Programdemo.exe. If the version number of demo.exe is 1.0.
How can i use this path to grab version number?.
c#-4.0 version fileversioninfo
edited Jul 16 '18 at 14:45
Kiquenet
6,99727109191
asked Jul 5 '12 at 18:04
NoviceMeNoviceMe
69083783
add a comment |
I am using .Net 3.5/4.0 with code in C#.
I am trying to get a version number of an exe file on my C: drive.
For example path is: c:Programdemo.exe. If the version number of demo.exe is 1.0.
How can i use this path to grab version number?.
c#-4.0 version fileversioninfo
edited Jul 16 '18 at 14:45
Kiquenet
6,99727109191
asked Jul 5 '12 at 18:04
NoviceMeNoviceMe
69083783
add a comment |
I am using .Net 3.5/4.0 with code in C#.
I am trying to get a version number of an exe file on my C: drive.
For example path is: c:Programdemo.exe. If the version number of demo.exe is 1.0.
How can i use this path to grab version number?.
c#-4.0 version fileversioninfo
edited Jul 16 '18 at 14:45
Kiquenet
6,99727109191
asked Jul 5 '12 at 18:04
NoviceMeNoviceMe
69083783
I am using .Net 3.5/4.0 with code in C#.
I am trying to get a version number of an exe file on my C: drive.
For example path is: c:Programdemo.exe. If the version number of demo.exe is 1.0.
How can i use this path to grab version number?.
c#-4.0 version fileversioninfo
c#-4.0 version fileversioninfo
edited Jul 16 '18 at 14:45
Kiquenet
6,99727109191
asked Jul 5 '12 at 18:04
NoviceMeNoviceMe
69083783
edited Jul 16 '18 at 14:45
Kiquenet
6,99727109191
asked Jul 5 '12 at 18:04
NoviceMeNoviceMe
69083783
edited Jul 16 '18 at 14:45
Kiquenet
6,99727109191
edited Jul 16 '18 at 14:45
Kiquenet
6,99727109191
edited Jul 16 '18 at 14:45
Kiquenet
6,99727109191
6,99727109191
asked Jul 5 '12 at 18:04
NoviceMeNoviceMe
69083783
asked Jul 5 '12 at 18:04
NoviceMeNoviceMe
69083783
asked Jul 5 '12 at 18:04
NoviceMeNoviceMe
69083783
69083783
add a comment |
add a comment |
7 Answers
7
active
oldest
votes
You can use FileVersionInfo.ProductVersion to fetch this from a path.
var versionInfo = FileVersionInfo.GetVersionInfo(pathToExe);
string version = versionInfo.ProductVersion; // Will typically return "1.0.0" in your case
answered Jul 5 '12 at 18:07
Reed CopseyReed Copsey
466k579691272
5
".ProductVersion" is not a "version number of a file". This should be differentiated from the file version (".FileVersion"). See my extended example. Moreover both versions can consist of four parts, and normally you get these four, so "1.0.0" is untypical, "1.0.0.0" is canonical.
– Philm
Apr 27 '14 at 15:09
add a comment |
Updated and modernized 2018 (e.g. string interpolation of C#6):
The accepted answer is partly not correct (ProductVersion is not typically returning three-part version) and a bit misleading:
Here is a more complete answer. To get the main text not too lengthy I splitted it in a short(er) summary which may be "enough" for a lot of people. You are not obliged to read the detailed second part, so please no tl;dr :-)
Short summary:
There are different versions (assembly version, file version, product version) of each file, but normally you will have them all equal to not get "version hell" already on file level (it will come early enough).
The file version (which is visible in Explorer and used in setups/installations) is, what I would name the most important to bother.
To achieve this, simply comment out fileversion in AssemblyInfo.cs file as below. This assures that the three possible different versions of one file are the same!
[assembly: AssemblyVersion("1.1.2.")]
//[assembly: AssemblyFileVersion("1.1.2.")]
E.g. for Semantic versioning you want to get only 3 version parts out of possible 4 :
Having an automatic build counting for every Visual Studio build is useful. But this build counting is not always useful to tell your customers, internal or external. So for mentioning the file version to windows, in title dialogs, I would advice to show only three parts v1.2.3 (and of course with semantic versioning):
using System.Diagnostics;
...
var versInfo= FileVersionInfo.GetVersionInfo(pathToVersionedFile);
string fileVersionFull = versInfo.FileVersion; // No difference here for versinfo.ProductVersion if recommendation in AssemblyInfo.cs is followed
string fileVersionSemantic = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}";
string fileVersionFull2 = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}.{versInfo.FilePrivatePart}";
FileVersionFull2 is just showing how to handle all 4 parts, except the "V" it contains the same as FileVersionFull .
D e t a i l s:
First is a cheat sheet about how to get and set the three versions:
File version: [assembly: AssemblyFileVersion(..)] => System.Diagnostics.FileVersionInfo.FileVersion
Product version: [assembly: AssemblyInformationalVersion(..)] => System.Diagnostics.FileVersionInfo.ProductVersion
Assembly version: [assembly: AssemblyVersion(..)] => System.Reflection.Assembly.Version
Especially the defaulting may be confusing. Recommended SO link to understand details: FileVersionInfo and AssemblyInfo
EntryAssembly vs. ExecutingAssembly
For fully considering every case for getting the version of the running app, search elsewhere for more details, e.g. here:
Which is better for getting assembly location , GetAssembly().Location or GetExecutingAssembly().Location
Especially, there can be confusion, if EntryAssembly or ExecutingAssembly should be used. They both have advantages and caveats.
If you have the following code not in the same assembly as the .exe, e.g. in a helper assembly, things get more complicated. Usually you would use EntryAssembly then, to get the version of the .exe.
But: For unit tests in Visual Studio to test routines in a parallel .exe project, GetEntryAssembly() doesn´t work (my env: NUnit, VS2017). But GetExecutingAssembly() doesn´t crash at least, only during unit test you get the assembly version of the test project. Fine enough for me.There may be situations which are not as simple.
If wanted, you can omit the declaration as static making it really possible to get versions of several different assemblies in one program.
public static class AppInfo
{
public static string FullAssemblyName { get; }
..
static AppInfo()
{
Assembly thisAssembly = null;
try
{
thisAssembly = Assembly.GetEntryAssembly();
}
finally
{
if (thisAssembly is null)
thisAssembly = Assembly.GetExecutingAssembly();
}
FullAssemblyName = thisAssembly.Location;
var versInfo = FileVersionInfo.GetVersionInfo(FullAssemblyName);
..
}
}
Product version vs. file version:
ProductVersion of a file is shown in Windows Explorer too. I would recommend to maximally differentiate ProductVersion and FileVersion in the most "customer-visible" file (mostly the main .exe of application). But it could be of course a choice to differentiate for every file of the "main" app and let them all have them all the "marketing" ProductVersion which is seen by customer.
But experience shows that it is neither necessary nor cheap to try to synchronize technical versions and marketing versions too much. Confusion doesn´t decrease really, costs increase. So the solution described in the first part here should do it mostly.
History: Assembly version vs. file version:
One reason for having different versions is also that one .NET assembly can originally consist of several files (modules)- theoretically. This is not used by Visual Studio and very seldom used elsewhere. This maybe one historical reason of giving the possibility to differentiate these two versions.
Technically the assembly version is relevant for .NET related versioning as GAC and Side-by-side versions, the file version is more relevant for classic setups, e.g. overwriting during updates or for shared files.
answered Apr 27 '14 at 15:18
PhilmPhilm
2,3141820
add a comment |
In the accepted answer a reference is made to "pathToExe".
This path can be retrieved and used as follows:
var assembly = Assembly.GetExecutingAssembly();
var fvi = FileVersionInfo.GetVersionInfo(assembly.Location);
var version = fvi.FileVersion; // or fvi.ProductVersion
Hope this saves someone from doing some unnecessary extra steps.
edited Jan 11 '18 at 11:06
Ian H.
2,45321331
answered Jun 11 '14 at 16:04
SophtwareSophtware
98511534
2
This is only correct if you want to read version number of current running file. in most cases you need to read version of another file, for example during creation of directory list
– AaA
Mar 7 '18 at 3:00
add a comment |
Where Program is your class name:
Console.WriteLine("Version = " + typeof(Program).Assembly.GetName().Version.ToString()) ;
edited Jul 17 '14 at 13:57
Austin Moore
78731338
answered Jul 17 '14 at 13:52
RalfRalf
6911
Very useful, thanks!
– Mafii
Oct 28 '16 at 12:46
add a comment |
I'm not sure if this is what you are looking for, but:
http://www.daniweb.com/software-development/csharp/threads/276174/c-code-to-get-dll-version
It says
int i;
// Get the file version for the notepad.
FileVersionInfo.GetVersionInfo(Path.Combine(Environment.SystemDirectory, "notepad.exe"));
FileVersionInfo myFileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.SystemDirectory + "\notepad.exe");
// Print the file name and version number.
Console.WriteLine("File: " + myFileVersionInfo.FileDescription + 'n' + "Version number: " + myFileVersionInfo.FileVersion);
answered Jul 5 '12 at 18:08
DrakkainenDrakkainen
953723
msdn.microsoft.com/en-us/library/…
– IamBatman
Jun 30 '16 at 18:53
add a comment |
Use, it work:
using System.Reflection;
string v = AssemblyName.GetAssemblyName("Path/filename.exe").Version.ToString();
answered Jan 14 '14 at 1:24
phuc.nxphuc.nx
583
Works! (Why negative point?) this method gets AssemblyVersion, others above get AssemblyFileVersion
– Sergio Cabral
Sep 19 '16 at 13:18
add a comment |
//Example your file version is 1.0.0.0
//Solution 1
Dim fileVer As FileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.CurrentDirectory + "yourExe.exe")
yourLabel.Text = fileVer.FileVersion
//Solution 2
//Get File Version Number
yourLabel.Text = Application.ProductVersion
//Both solution will get output 1.0.0.0
answered Mar 20 '17 at 3:35
Tuan ZaidiTuan Zaidi
310111
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f11350008%2fhow-to-get-exe-file-version-number-from-file-path%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can use FileVersionInfo.ProductVersion to fetch this from a path.
var versionInfo = FileVersionInfo.GetVersionInfo(pathToExe);
string version = versionInfo.ProductVersion; // Will typically return "1.0.0" in your case
answered Jul 5 '12 at 18:07
Reed CopseyReed Copsey
466k579691272
5
".ProductVersion" is not a "version number of a file". This should be differentiated from the file version (".FileVersion"). See my extended example. Moreover both versions can consist of four parts, and normally you get these four, so "1.0.0" is untypical, "1.0.0.0" is canonical.
– Philm
Apr 27 '14 at 15:09
add a comment |
You can use FileVersionInfo.ProductVersion to fetch this from a path.
var versionInfo = FileVersionInfo.GetVersionInfo(pathToExe);
string version = versionInfo.ProductVersion; // Will typically return "1.0.0" in your case
answered Jul 5 '12 at 18:07
Reed CopseyReed Copsey
466k579691272
5
".ProductVersion" is not a "version number of a file". This should be differentiated from the file version (".FileVersion"). See my extended example. Moreover both versions can consist of four parts, and normally you get these four, so "1.0.0" is untypical, "1.0.0.0" is canonical.
– Philm
Apr 27 '14 at 15:09
add a comment |
You can use FileVersionInfo.ProductVersion to fetch this from a path.
var versionInfo = FileVersionInfo.GetVersionInfo(pathToExe);
string version = versionInfo.ProductVersion; // Will typically return "1.0.0" in your case
answered Jul 5 '12 at 18:07
Reed CopseyReed Copsey
466k579691272
You can use FileVersionInfo.ProductVersion to fetch this from a path.
var versionInfo = FileVersionInfo.GetVersionInfo(pathToExe);
string version = versionInfo.ProductVersion; // Will typically return "1.0.0" in your case
answered Jul 5 '12 at 18:07
Reed CopseyReed Copsey
466k579691272
answered Jul 5 '12 at 18:07
Reed CopseyReed Copsey
466k579691272
answered Jul 5 '12 at 18:07
Reed CopseyReed Copsey
466k579691272
answered Jul 5 '12 at 18:07
Reed CopseyReed Copsey
466k579691272
466k579691272
5
".ProductVersion" is not a "version number of a file". This should be differentiated from the file version (".FileVersion"). See my extended example. Moreover both versions can consist of four parts, and normally you get these four, so "1.0.0" is untypical, "1.0.0.0" is canonical.
– Philm
Apr 27 '14 at 15:09
add a comment |
5
".ProductVersion" is not a "version number of a file". This should be differentiated from the file version (".FileVersion"). See my extended example. Moreover both versions can consist of four parts, and normally you get these four, so "1.0.0" is untypical, "1.0.0.0" is canonical.
– Philm
Apr 27 '14 at 15:09
5
5
".ProductVersion" is not a "version number of a file". This should be differentiated from the file version (".FileVersion"). See my extended example. Moreover both versions can consist of four parts, and normally you get these four, so "1.0.0" is untypical, "1.0.0.0" is canonical.
– Philm
Apr 27 '14 at 15:09
".ProductVersion" is not a "version number of a file". This should be differentiated from the file version (".FileVersion"). See my extended example. Moreover both versions can consist of four parts, and normally you get these four, so "1.0.0" is untypical, "1.0.0.0" is canonical.
– Philm
Apr 27 '14 at 15:09
add a comment |
Updated and modernized 2018 (e.g. string interpolation of C#6):
The accepted answer is partly not correct (ProductVersion is not typically returning three-part version) and a bit misleading:
Here is a more complete answer. To get the main text not too lengthy I splitted it in a short(er) summary which may be "enough" for a lot of people. You are not obliged to read the detailed second part, so please no tl;dr :-)
Short summary:
There are different versions (assembly version, file version, product version) of each file, but normally you will have them all equal to not get "version hell" already on file level (it will come early enough).
The file version (which is visible in Explorer and used in setups/installations) is, what I would name the most important to bother.
To achieve this, simply comment out fileversion in AssemblyInfo.cs file as below. This assures that the three possible different versions of one file are the same!
[assembly: AssemblyVersion("1.1.2.")]
//[assembly: AssemblyFileVersion("1.1.2.")]
E.g. for Semantic versioning you want to get only 3 version parts out of possible 4 :
Having an automatic build counting for every Visual Studio build is useful. But this build counting is not always useful to tell your customers, internal or external. So for mentioning the file version to windows, in title dialogs, I would advice to show only three parts v1.2.3 (and of course with semantic versioning):
using System.Diagnostics;
...
var versInfo= FileVersionInfo.GetVersionInfo(pathToVersionedFile);
string fileVersionFull = versInfo.FileVersion; // No difference here for versinfo.ProductVersion if recommendation in AssemblyInfo.cs is followed
string fileVersionSemantic = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}";
string fileVersionFull2 = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}.{versInfo.FilePrivatePart}";
FileVersionFull2 is just showing how to handle all 4 parts, except the "V" it contains the same as FileVersionFull .
D e t a i l s:
First is a cheat sheet about how to get and set the three versions:
File version: [assembly: AssemblyFileVersion(..)] => System.Diagnostics.FileVersionInfo.FileVersion
Product version: [assembly: AssemblyInformationalVersion(..)] => System.Diagnostics.FileVersionInfo.ProductVersion
Assembly version: [assembly: AssemblyVersion(..)] => System.Reflection.Assembly.Version
Especially the defaulting may be confusing. Recommended SO link to understand details: FileVersionInfo and AssemblyInfo
EntryAssembly vs. ExecutingAssembly
For fully considering every case for getting the version of the running app, search elsewhere for more details, e.g. here:
Which is better for getting assembly location , GetAssembly().Location or GetExecutingAssembly().Location
Especially, there can be confusion, if EntryAssembly or ExecutingAssembly should be used. They both have advantages and caveats.
If you have the following code not in the same assembly as the .exe, e.g. in a helper assembly, things get more complicated. Usually you would use EntryAssembly then, to get the version of the .exe.
But: For unit tests in Visual Studio to test routines in a parallel .exe project, GetEntryAssembly() doesn´t work (my env: NUnit, VS2017). But GetExecutingAssembly() doesn´t crash at least, only during unit test you get the assembly version of the test project. Fine enough for me.There may be situations which are not as simple.
If wanted, you can omit the declaration as static making it really possible to get versions of several different assemblies in one program.
public static class AppInfo
{
public static string FullAssemblyName { get; }
..
static AppInfo()
{
Assembly thisAssembly = null;
try
{
thisAssembly = Assembly.GetEntryAssembly();
}
finally
{
if (thisAssembly is null)
thisAssembly = Assembly.GetExecutingAssembly();
}
FullAssemblyName = thisAssembly.Location;
var versInfo = FileVersionInfo.GetVersionInfo(FullAssemblyName);
..
}
}
Product version vs. file version:
ProductVersion of a file is shown in Windows Explorer too. I would recommend to maximally differentiate ProductVersion and FileVersion in the most "customer-visible" file (mostly the main .exe of application). But it could be of course a choice to differentiate for every file of the "main" app and let them all have them all the "marketing" ProductVersion which is seen by customer.
But experience shows that it is neither necessary nor cheap to try to synchronize technical versions and marketing versions too much. Confusion doesn´t decrease really, costs increase. So the solution described in the first part here should do it mostly.
History: Assembly version vs. file version:
One reason for having different versions is also that one .NET assembly can originally consist of several files (modules)- theoretically. This is not used by Visual Studio and very seldom used elsewhere. This maybe one historical reason of giving the possibility to differentiate these two versions.
Technically the assembly version is relevant for .NET related versioning as GAC and Side-by-side versions, the file version is more relevant for classic setups, e.g. overwriting during updates or for shared files.
answered Apr 27 '14 at 15:18
PhilmPhilm
2,3141820
add a comment |
Updated and modernized 2018 (e.g. string interpolation of C#6):
The accepted answer is partly not correct (ProductVersion is not typically returning three-part version) and a bit misleading:
Here is a more complete answer. To get the main text not too lengthy I splitted it in a short(er) summary which may be "enough" for a lot of people. You are not obliged to read the detailed second part, so please no tl;dr :-)
Short summary:
There are different versions (assembly version, file version, product version) of each file, but normally you will have them all equal to not get "version hell" already on file level (it will come early enough).
The file version (which is visible in Explorer and used in setups/installations) is, what I would name the most important to bother.
To achieve this, simply comment out fileversion in AssemblyInfo.cs file as below. This assures that the three possible different versions of one file are the same!
[assembly: AssemblyVersion("1.1.2.")]
//[assembly: AssemblyFileVersion("1.1.2.")]
E.g. for Semantic versioning you want to get only 3 version parts out of possible 4 :
Having an automatic build counting for every Visual Studio build is useful. But this build counting is not always useful to tell your customers, internal or external. So for mentioning the file version to windows, in title dialogs, I would advice to show only three parts v1.2.3 (and of course with semantic versioning):
using System.Diagnostics;
...
var versInfo= FileVersionInfo.GetVersionInfo(pathToVersionedFile);
string fileVersionFull = versInfo.FileVersion; // No difference here for versinfo.ProductVersion if recommendation in AssemblyInfo.cs is followed
string fileVersionSemantic = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}";
string fileVersionFull2 = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}.{versInfo.FilePrivatePart}";
FileVersionFull2 is just showing how to handle all 4 parts, except the "V" it contains the same as FileVersionFull .
D e t a i l s:
First is a cheat sheet about how to get and set the three versions:
File version: [assembly: AssemblyFileVersion(..)] => System.Diagnostics.FileVersionInfo.FileVersion
Product version: [assembly: AssemblyInformationalVersion(..)] => System.Diagnostics.FileVersionInfo.ProductVersion
Assembly version: [assembly: AssemblyVersion(..)] => System.Reflection.Assembly.Version
Especially the defaulting may be confusing. Recommended SO link to understand details: FileVersionInfo and AssemblyInfo
EntryAssembly vs. ExecutingAssembly
For fully considering every case for getting the version of the running app, search elsewhere for more details, e.g. here:
Which is better for getting assembly location , GetAssembly().Location or GetExecutingAssembly().Location
Especially, there can be confusion, if EntryAssembly or ExecutingAssembly should be used. They both have advantages and caveats.
If you have the following code not in the same assembly as the .exe, e.g. in a helper assembly, things get more complicated. Usually you would use EntryAssembly then, to get the version of the .exe.
But: For unit tests in Visual Studio to test routines in a parallel .exe project, GetEntryAssembly() doesn´t work (my env: NUnit, VS2017). But GetExecutingAssembly() doesn´t crash at least, only during unit test you get the assembly version of the test project. Fine enough for me.There may be situations which are not as simple.
If wanted, you can omit the declaration as static making it really possible to get versions of several different assemblies in one program.
public static class AppInfo
{
public static string FullAssemblyName { get; }
..
static AppInfo()
{
Assembly thisAssembly = null;
try
{
thisAssembly = Assembly.GetEntryAssembly();
}
finally
{
if (thisAssembly is null)
thisAssembly = Assembly.GetExecutingAssembly();
}
FullAssemblyName = thisAssembly.Location;
var versInfo = FileVersionInfo.GetVersionInfo(FullAssemblyName);
..
}
}
Product version vs. file version:
ProductVersion of a file is shown in Windows Explorer too. I would recommend to maximally differentiate ProductVersion and FileVersion in the most "customer-visible" file (mostly the main .exe of application). But it could be of course a choice to differentiate for every file of the "main" app and let them all have them all the "marketing" ProductVersion which is seen by customer.
But experience shows that it is neither necessary nor cheap to try to synchronize technical versions and marketing versions too much. Confusion doesn´t decrease really, costs increase. So the solution described in the first part here should do it mostly.
History: Assembly version vs. file version:
One reason for having different versions is also that one .NET assembly can originally consist of several files (modules)- theoretically. This is not used by Visual Studio and very seldom used elsewhere. This maybe one historical reason of giving the possibility to differentiate these two versions.
Technically the assembly version is relevant for .NET related versioning as GAC and Side-by-side versions, the file version is more relevant for classic setups, e.g. overwriting during updates or for shared files.
answered Apr 27 '14 at 15:18
PhilmPhilm
2,3141820
add a comment |
Updated and modernized 2018 (e.g. string interpolation of C#6):
The accepted answer is partly not correct (ProductVersion is not typically returning three-part version) and a bit misleading:
Here is a more complete answer. To get the main text not too lengthy I splitted it in a short(er) summary which may be "enough" for a lot of people. You are not obliged to read the detailed second part, so please no tl;dr :-)
Short summary:
There are different versions (assembly version, file version, product version) of each file, but normally you will have them all equal to not get "version hell" already on file level (it will come early enough).
The file version (which is visible in Explorer and used in setups/installations) is, what I would name the most important to bother.
To achieve this, simply comment out fileversion in AssemblyInfo.cs file as below. This assures that the three possible different versions of one file are the same!
[assembly: AssemblyVersion("1.1.2.")]
//[assembly: AssemblyFileVersion("1.1.2.")]
E.g. for Semantic versioning you want to get only 3 version parts out of possible 4 :
Having an automatic build counting for every Visual Studio build is useful. But this build counting is not always useful to tell your customers, internal or external. So for mentioning the file version to windows, in title dialogs, I would advice to show only three parts v1.2.3 (and of course with semantic versioning):
using System.Diagnostics;
...
var versInfo= FileVersionInfo.GetVersionInfo(pathToVersionedFile);
string fileVersionFull = versInfo.FileVersion; // No difference here for versinfo.ProductVersion if recommendation in AssemblyInfo.cs is followed
string fileVersionSemantic = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}";
string fileVersionFull2 = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}.{versInfo.FilePrivatePart}";
FileVersionFull2 is just showing how to handle all 4 parts, except the "V" it contains the same as FileVersionFull .
D e t a i l s:
First is a cheat sheet about how to get and set the three versions:
File version: [assembly: AssemblyFileVersion(..)] => System.Diagnostics.FileVersionInfo.FileVersion
Product version: [assembly: AssemblyInformationalVersion(..)] => System.Diagnostics.FileVersionInfo.ProductVersion
Assembly version: [assembly: AssemblyVersion(..)] => System.Reflection.Assembly.Version
Especially the defaulting may be confusing. Recommended SO link to understand details: FileVersionInfo and AssemblyInfo
EntryAssembly vs. ExecutingAssembly
For fully considering every case for getting the version of the running app, search elsewhere for more details, e.g. here:
Which is better for getting assembly location , GetAssembly().Location or GetExecutingAssembly().Location
Especially, there can be confusion, if EntryAssembly or ExecutingAssembly should be used. They both have advantages and caveats.
If you have the following code not in the same assembly as the .exe, e.g. in a helper assembly, things get more complicated. Usually you would use EntryAssembly then, to get the version of the .exe.
But: For unit tests in Visual Studio to test routines in a parallel .exe project, GetEntryAssembly() doesn´t work (my env: NUnit, VS2017). But GetExecutingAssembly() doesn´t crash at least, only during unit test you get the assembly version of the test project. Fine enough for me.There may be situations which are not as simple.
If wanted, you can omit the declaration as static making it really possible to get versions of several different assemblies in one program.
public static class AppInfo
{
public static string FullAssemblyName { get; }
..
static AppInfo()
{
Assembly thisAssembly = null;
try
{
thisAssembly = Assembly.GetEntryAssembly();
}
finally
{
if (thisAssembly is null)
thisAssembly = Assembly.GetExecutingAssembly();
}
FullAssemblyName = thisAssembly.Location;
var versInfo = FileVersionInfo.GetVersionInfo(FullAssemblyName);
..
}
}
Product version vs. file version:
ProductVersion of a file is shown in Windows Explorer too. I would recommend to maximally differentiate ProductVersion and FileVersion in the most "customer-visible" file (mostly the main .exe of application). But it could be of course a choice to differentiate for every file of the "main" app and let them all have them all the "marketing" ProductVersion which is seen by customer.
But experience shows that it is neither necessary nor cheap to try to synchronize technical versions and marketing versions too much. Confusion doesn´t decrease really, costs increase. So the solution described in the first part here should do it mostly.
History: Assembly version vs. file version:
One reason for having different versions is also that one .NET assembly can originally consist of several files (modules)- theoretically. This is not used by Visual Studio and very seldom used elsewhere. This maybe one historical reason of giving the possibility to differentiate these two versions.
Technically the assembly version is relevant for .NET related versioning as GAC and Side-by-side versions, the file version is more relevant for classic setups, e.g. overwriting during updates or for shared files.
answered Apr 27 '14 at 15:18
PhilmPhilm
2,3141820
Updated and modernized 2018 (e.g. string interpolation of C#6):
The accepted answer is partly not correct (ProductVersion is not typically returning three-part version) and a bit misleading:
Here is a more complete answer. To get the main text not too lengthy I splitted it in a short(er) summary which may be "enough" for a lot of people. You are not obliged to read the detailed second part, so please no tl;dr :-)
Short summary:
There are different versions (assembly version, file version, product version) of each file, but normally you will have them all equal to not get "version hell" already on file level (it will come early enough).
The file version (which is visible in Explorer and used in setups/installations) is, what I would name the most important to bother.
To achieve this, simply comment out fileversion in AssemblyInfo.cs file as below. This assures that the three possible different versions of one file are the same!
[assembly: AssemblyVersion("1.1.2.")]
//[assembly: AssemblyFileVersion("1.1.2.")]
E.g. for Semantic versioning you want to get only 3 version parts out of possible 4 :
Having an automatic build counting for every Visual Studio build is useful. But this build counting is not always useful to tell your customers, internal or external. So for mentioning the file version to windows, in title dialogs, I would advice to show only three parts v1.2.3 (and of course with semantic versioning):
using System.Diagnostics;
...
var versInfo= FileVersionInfo.GetVersionInfo(pathToVersionedFile);
string fileVersionFull = versInfo.FileVersion; // No difference here for versinfo.ProductVersion if recommendation in AssemblyInfo.cs is followed
string fileVersionSemantic = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}";
string fileVersionFull2 = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}.{versInfo.FilePrivatePart}";
FileVersionFull2 is just showing how to handle all 4 parts, except the "V" it contains the same as FileVersionFull .
D e t a i l s:
First is a cheat sheet about how to get and set the three versions:
File version: [assembly: AssemblyFileVersion(..)] => System.Diagnostics.FileVersionInfo.FileVersion
Product version: [assembly: AssemblyInformationalVersion(..)] => System.Diagnostics.FileVersionInfo.ProductVersion
Assembly version: [assembly: AssemblyVersion(..)] => System.Reflection.Assembly.Version
Especially the defaulting may be confusing. Recommended SO link to understand details: FileVersionInfo and AssemblyInfo
EntryAssembly vs. ExecutingAssembly
For fully considering every case for getting the version of the running app, search elsewhere for more details, e.g. here:
Which is better for getting assembly location , GetAssembly().Location or GetExecutingAssembly().Location
Especially, there can be confusion, if EntryAssembly or ExecutingAssembly should be used. They both have advantages and caveats.
If you have the following code not in the same assembly as the .exe, e.g. in a helper assembly, things get more complicated. Usually you would use EntryAssembly then, to get the version of the .exe.
But: For unit tests in Visual Studio to test routines in a parallel .exe project, GetEntryAssembly() doesn´t work (my env: NUnit, VS2017). But GetExecutingAssembly() doesn´t crash at least, only during unit test you get the assembly version of the test project. Fine enough for me.There may be situations which are not as simple.
If wanted, you can omit the declaration as static making it really possible to get versions of several different assemblies in one program.
public static class AppInfo
{
public static string FullAssemblyName { get; }
..
static AppInfo()
{
Assembly thisAssembly = null;
try
{
thisAssembly = Assembly.GetEntryAssembly();
}
finally
{
if (thisAssembly is null)
thisAssembly = Assembly.GetExecutingAssembly();
}
FullAssemblyName = thisAssembly.Location;
var versInfo = FileVersionInfo.GetVersionInfo(FullAssemblyName);
..
}
}
Product version vs. file version:
ProductVersion of a file is shown in Windows Explorer too. I would recommend to maximally differentiate ProductVersion and FileVersion in the most "customer-visible" file (mostly the main .exe of application). But it could be of course a choice to differentiate for every file of the "main" app and let them all have them all the "marketing" ProductVersion which is seen by customer.
But experience shows that it is neither necessary nor cheap to try to synchronize technical versions and marketing versions too much. Confusion doesn´t decrease really, costs increase. So the solution described in the first part here should do it mostly.
History: Assembly version vs. file version:
One reason for having different versions is also that one .NET assembly can originally consist of several files (modules)- theoretically. This is not used by Visual Studio and very seldom used elsewhere. This maybe one historical reason of giving the possibility to differentiate these two versions.
Technically the assembly version is relevant for .NET related versioning as GAC and Side-by-side versions, the file version is more relevant for classic setups, e.g. overwriting during updates or for shared files.
answered Apr 27 '14 at 15:18
PhilmPhilm
2,3141820
edited Nov 20 '18 at 20:12
answered Apr 27 '14 at 15:18
PhilmPhilm
2,3141820
answered Apr 27 '14 at 15:18
PhilmPhilm
2,3141820
answered Apr 27 '14 at 15:18
PhilmPhilm
2,3141820
2,3141820
add a comment |
add a comment |
In the accepted answer a reference is made to "pathToExe".
This path can be retrieved and used as follows:
var assembly = Assembly.GetExecutingAssembly();
var fvi = FileVersionInfo.GetVersionInfo(assembly.Location);
var version = fvi.FileVersion; // or fvi.ProductVersion
Hope this saves someone from doing some unnecessary extra steps.
edited Jan 11 '18 at 11:06
Ian H.
2,45321331
answered Jun 11 '14 at 16:04
SophtwareSophtware
98511534
2
This is only correct if you want to read version number of current running file. in most cases you need to read version of another file, for example during creation of directory list
– AaA
Mar 7 '18 at 3:00
add a comment |
In the accepted answer a reference is made to "pathToExe".
This path can be retrieved and used as follows:
var assembly = Assembly.GetExecutingAssembly();
var fvi = FileVersionInfo.GetVersionInfo(assembly.Location);
var version = fvi.FileVersion; // or fvi.ProductVersion
Hope this saves someone from doing some unnecessary extra steps.
edited Jan 11 '18 at 11:06
Ian H.
2,45321331
answered Jun 11 '14 at 16:04
SophtwareSophtware
98511534
2
This is only correct if you want to read version number of current running file. in most cases you need to read version of another file, for example during creation of directory list
– AaA
Mar 7 '18 at 3:00
add a comment |
In the accepted answer a reference is made to "pathToExe".
This path can be retrieved and used as follows:
var assembly = Assembly.GetExecutingAssembly();
var fvi = FileVersionInfo.GetVersionInfo(assembly.Location);
var version = fvi.FileVersion; // or fvi.ProductVersion
Hope this saves someone from doing some unnecessary extra steps.
edited Jan 11 '18 at 11:06
Ian H.
2,45321331
answered Jun 11 '14 at 16:04
SophtwareSophtware
98511534
In the accepted answer a reference is made to "pathToExe".
This path can be retrieved and used as follows:
var assembly = Assembly.GetExecutingAssembly();
var fvi = FileVersionInfo.GetVersionInfo(assembly.Location);
var version = fvi.FileVersion; // or fvi.ProductVersion
Hope this saves someone from doing some unnecessary extra steps.
edited Jan 11 '18 at 11:06
Ian H.
2,45321331
answered Jun 11 '14 at 16:04
SophtwareSophtware
98511534
edited Jan 11 '18 at 11:06
Ian H.
2,45321331
edited Jan 11 '18 at 11:06
Ian H.
2,45321331
edited Jan 11 '18 at 11:06
Ian H.
2,45321331
2,45321331
answered Jun 11 '14 at 16:04
SophtwareSophtware
98511534
answered Jun 11 '14 at 16:04
SophtwareSophtware
98511534
answered Jun 11 '14 at 16:04
SophtwareSophtware
98511534
98511534
2
This is only correct if you want to read version number of current running file. in most cases you need to read version of another file, for example during creation of directory list
– AaA
Mar 7 '18 at 3:00
add a comment |
2
This is only correct if you want to read version number of current running file. in most cases you need to read version of another file, for example during creation of directory list
– AaA
Mar 7 '18 at 3:00
2
2
This is only correct if you want to read version number of current running file. in most cases you need to read version of another file, for example during creation of directory list
– AaA
Mar 7 '18 at 3:00
This is only correct if you want to read version number of current running file. in most cases you need to read version of another file, for example during creation of directory list
– AaA
Mar 7 '18 at 3:00
add a comment |
Where Program is your class name:
Console.WriteLine("Version = " + typeof(Program).Assembly.GetName().Version.ToString()) ;
edited Jul 17 '14 at 13:57
Austin Moore
78731338
answered Jul 17 '14 at 13:52
RalfRalf
6911
Very useful, thanks!
– Mafii
Oct 28 '16 at 12:46
add a comment |
Where Program is your class name:
Console.WriteLine("Version = " + typeof(Program).Assembly.GetName().Version.ToString()) ;
edited Jul 17 '14 at 13:57
Austin Moore
78731338
answered Jul 17 '14 at 13:52
RalfRalf
6911
Very useful, thanks!
– Mafii
Oct 28 '16 at 12:46
add a comment |
Where Program is your class name:
Console.WriteLine("Version = " + typeof(Program).Assembly.GetName().Version.ToString()) ;
edited Jul 17 '14 at 13:57
Austin Moore
78731338
answered Jul 17 '14 at 13:52
RalfRalf
6911
Where Program is your class name:
Console.WriteLine("Version = " + typeof(Program).Assembly.GetName().Version.ToString()) ;
edited Jul 17 '14 at 13:57
Austin Moore
78731338
answered Jul 17 '14 at 13:52
RalfRalf
6911
edited Jul 17 '14 at 13:57
Austin Moore
78731338
edited Jul 17 '14 at 13:57
Austin Moore
78731338
edited Jul 17 '14 at 13:57
Austin Moore
78731338
78731338
answered Jul 17 '14 at 13:52
RalfRalf
6911
answered Jul 17 '14 at 13:52
RalfRalf
6911
answered Jul 17 '14 at 13:52
RalfRalf
6911
6911
Very useful, thanks!
– Mafii
Oct 28 '16 at 12:46
add a comment |
Very useful, thanks!
– Mafii
Oct 28 '16 at 12:46
Very useful, thanks!
– Mafii
Oct 28 '16 at 12:46
Very useful, thanks!
– Mafii
Oct 28 '16 at 12:46
add a comment |
I'm not sure if this is what you are looking for, but:
http://www.daniweb.com/software-development/csharp/threads/276174/c-code-to-get-dll-version
It says
int i;
// Get the file version for the notepad.
FileVersionInfo.GetVersionInfo(Path.Combine(Environment.SystemDirectory, "notepad.exe"));
FileVersionInfo myFileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.SystemDirectory + "\notepad.exe");
// Print the file name and version number.
Console.WriteLine("File: " + myFileVersionInfo.FileDescription + 'n' + "Version number: " + myFileVersionInfo.FileVersion);
answered Jul 5 '12 at 18:08
DrakkainenDrakkainen
953723
msdn.microsoft.com/en-us/library/…
– IamBatman
Jun 30 '16 at 18:53
add a comment |
I'm not sure if this is what you are looking for, but:
http://www.daniweb.com/software-development/csharp/threads/276174/c-code-to-get-dll-version
It says
int i;
// Get the file version for the notepad.
FileVersionInfo.GetVersionInfo(Path.Combine(Environment.SystemDirectory, "notepad.exe"));
FileVersionInfo myFileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.SystemDirectory + "\notepad.exe");
// Print the file name and version number.
Console.WriteLine("File: " + myFileVersionInfo.FileDescription + 'n' + "Version number: " + myFileVersionInfo.FileVersion);
answered Jul 5 '12 at 18:08
DrakkainenDrakkainen
953723
msdn.microsoft.com/en-us/library/…
– IamBatman
Jun 30 '16 at 18:53
add a comment |
I'm not sure if this is what you are looking for, but:
http://www.daniweb.com/software-development/csharp/threads/276174/c-code-to-get-dll-version
It says
int i;
// Get the file version for the notepad.
FileVersionInfo.GetVersionInfo(Path.Combine(Environment.SystemDirectory, "notepad.exe"));
FileVersionInfo myFileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.SystemDirectory + "\notepad.exe");
// Print the file name and version number.
Console.WriteLine("File: " + myFileVersionInfo.FileDescription + 'n' + "Version number: " + myFileVersionInfo.FileVersion);
answered Jul 5 '12 at 18:08
DrakkainenDrakkainen
953723
I'm not sure if this is what you are looking for, but:
http://www.daniweb.com/software-development/csharp/threads/276174/c-code-to-get-dll-version
It says
int i;
// Get the file version for the notepad.
FileVersionInfo.GetVersionInfo(Path.Combine(Environment.SystemDirectory, "notepad.exe"));
FileVersionInfo myFileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.SystemDirectory + "\notepad.exe");
// Print the file name and version number.
Console.WriteLine("File: " + myFileVersionInfo.FileDescription + 'n' + "Version number: " + myFileVersionInfo.FileVersion);
answered Jul 5 '12 at 18:08
DrakkainenDrakkainen
953723
answered Jul 5 '12 at 18:08
DrakkainenDrakkainen
953723
answered Jul 5 '12 at 18:08
DrakkainenDrakkainen
953723
answered Jul 5 '12 at 18:08
DrakkainenDrakkainen
953723
953723
msdn.microsoft.com/en-us/library/…
– IamBatman
Jun 30 '16 at 18:53
add a comment |
msdn.microsoft.com/en-us/library/…
– IamBatman
Jun 30 '16 at 18:53
msdn.microsoft.com/en-us/library/…
– IamBatman
Jun 30 '16 at 18:53
msdn.microsoft.com/en-us/library/…
– IamBatman
Jun 30 '16 at 18:53
add a comment |
Use, it work:
using System.Reflection;
string v = AssemblyName.GetAssemblyName("Path/filename.exe").Version.ToString();
answered Jan 14 '14 at 1:24
phuc.nxphuc.nx
583
Works! (Why negative point?) this method gets AssemblyVersion, others above get AssemblyFileVersion
– Sergio Cabral
Sep 19 '16 at 13:18
add a comment |
Use, it work:
using System.Reflection;
string v = AssemblyName.GetAssemblyName("Path/filename.exe").Version.ToString();
answered Jan 14 '14 at 1:24
phuc.nxphuc.nx
583
Works! (Why negative point?) this method gets AssemblyVersion, others above get AssemblyFileVersion
– Sergio Cabral
Sep 19 '16 at 13:18
add a comment |
Use, it work:
using System.Reflection;
string v = AssemblyName.GetAssemblyName("Path/filename.exe").Version.ToString();
answered Jan 14 '14 at 1:24
phuc.nxphuc.nx
583
Use, it work:
using System.Reflection;
string v = AssemblyName.GetAssemblyName("Path/filename.exe").Version.ToString();
answered Jan 14 '14 at 1:24
phuc.nxphuc.nx
583
answered Jan 14 '14 at 1:24
phuc.nxphuc.nx
583
answered Jan 14 '14 at 1:24
phuc.nxphuc.nx
583
answered Jan 14 '14 at 1:24
phuc.nxphuc.nx
583
583
Works! (Why negative point?) this method gets AssemblyVersion, others above get AssemblyFileVersion
– Sergio Cabral
Sep 19 '16 at 13:18
add a comment |
Works! (Why negative point?) this method gets AssemblyVersion, others above get AssemblyFileVersion
– Sergio Cabral
Sep 19 '16 at 13:18
Works! (Why negative point?) this method gets AssemblyVersion, others above get AssemblyFileVersion
– Sergio Cabral
Sep 19 '16 at 13:18
Works! (Why negative point?) this method gets AssemblyVersion, others above get AssemblyFileVersion
– Sergio Cabral
Sep 19 '16 at 13:18
add a comment |
//Example your file version is 1.0.0.0
//Solution 1
Dim fileVer As FileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.CurrentDirectory + "yourExe.exe")
yourLabel.Text = fileVer.FileVersion
//Solution 2
//Get File Version Number
yourLabel.Text = Application.ProductVersion
//Both solution will get output 1.0.0.0
answered Mar 20 '17 at 3:35
Tuan ZaidiTuan Zaidi
310111
add a comment |
//Example your file version is 1.0.0.0
//Solution 1
Dim fileVer As FileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.CurrentDirectory + "yourExe.exe")
yourLabel.Text = fileVer.FileVersion
//Solution 2
//Get File Version Number
yourLabel.Text = Application.ProductVersion
//Both solution will get output 1.0.0.0
answered Mar 20 '17 at 3:35
Tuan ZaidiTuan Zaidi
310111
add a comment |
//Example your file version is 1.0.0.0
//Solution 1
Dim fileVer As FileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.CurrentDirectory + "yourExe.exe")
yourLabel.Text = fileVer.FileVersion
//Solution 2
//Get File Version Number
yourLabel.Text = Application.ProductVersion
//Both solution will get output 1.0.0.0
answered Mar 20 '17 at 3:35
Tuan ZaidiTuan Zaidi
310111
//Example your file version is 1.0.0.0
//Solution 1
Dim fileVer As FileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.CurrentDirectory + "yourExe.exe")
yourLabel.Text = fileVer.FileVersion
//Solution 2
//Get File Version Number
yourLabel.Text = Application.ProductVersion
//Both solution will get output 1.0.0.0
answered Mar 20 '17 at 3:35
Tuan ZaidiTuan Zaidi
310111
edited Mar 20 '17 at 7:39
answered Mar 20 '17 at 3:35
Tuan ZaidiTuan Zaidi
310111
answered Mar 20 '17 at 3:35
Tuan ZaidiTuan Zaidi
310111
answered Mar 20 '17 at 3:35
Tuan ZaidiTuan Zaidi
310111
310111
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f11350008%2fhow-to-get-exe-file-version-number-from-file-path%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
