I am trying to get the file version using C#:
string file = #"C:\somefile.dll";
Console.WriteLine(FileVersionInfo.GetVersionInfo(file).FileVersion);
For most files this is fine, however for some i receive results that are different than the ones presented in the Windows file explorer.
See the attached image: the file version presented in windows is "0.0.0.0", however the one i get using FileVersion property is "000.000.000.000".
I've tried using different versions of the .NET (2, 3.5, 4) which give the same results.
Anyone else experienced this issue?
Thanks
Lior
It seems Windows Explorer are stripping leading 0s of the version parts.
Try creating an assembly with FileVersion 001.001.001.001, it will show as 1.1.1.1 in explorer. But your code would return the actual value (001.001.001.001).
EDIT:
Explorer will return 001.001.001.001 as ProductVersion, but only if AssemblyInformationalVersion isn't set, in which case it would return that as ProductVersion.
The reason is, in WIN32 API (and the file metadata), product versions are defined as string but file versions are defined as integer while in .NET, all of them are defined as integer.
If you use reflector and inspect FileVersionInfo class, you can see that they are loaded differently:
this.productVersion = GetFileVersionString(memIntPtr, string.Format(CultureInfo.InvariantCulture, format, new object[] { codepage, "ProductVersion" }))
But:
this.fileMajor = HIWORD(fixedFileInfo.dwFileVersionMS);
this.fileMinor = LOWORD(fixedFileInfo.dwFileVersionMS);
this.fileBuild = HIWORD(fixedFileInfo.dwFileVersionLS);
this.filePrivate = LOWORD(fixedFileInfo.dwFileVersionLS);
Related
I have a PoC to use some existing Java-codebase in some UWP-app using the most current Visual Studio Community 19 version 16.3.2 and the latest released IKVM 8.1.7195.0. The app builds and runs fine in Debug-mode, but fails to build already in Release-mode with the following error:
MCG0004:InternalAssert Assert Failed: ICE: trying to add a local var
with the same name, but different types. during
[_RegisterClipboardFormat] Ams.Oms.Poc
RegisterClipboardFormat is part of IKVM:
#DllImportAttribute.Annotation(value = "user32.dll", EntryPoint = "RegisterClipboardFormat")
private native static int _RegisterClipboardFormat(String format);
#cli.System.Security.SecuritySafeCriticalAttribute.Annotation
private static int RegisterClipboardFormat(String format)
{
return _RegisterClipboardFormat(format);
}
https://github.com/ikvm-revived/ikvm/blob/master/openjdk/sun/awt/IkvmDataTransferer.java#L95
What I'm wondering is which local variable the error message is referring to? Might be something added implicitly or might have to do with String in Java vs. string in C#? OTOH that file is clearly named .java.
Didn't find much about the error message in general, only the following two links seems to be more interesting:
Variables having same name but different type
Why doesn't C# allow me to use the same variable name in different scopes?
So I'm currently even unsure where the message comes from, Visual Studio/C# directly or IKVM during running code during building Release-mode. I strongly suspect the error is coming from Visual Studio/C#, though.
Searching for the function itself doesn't reveal much of help as well:
Sorry, AWT is not a supported part of IKVM.
https://sourceforge.net/p/ikvm/bugs/225/
Others seemed to have the same problem, because CN1 simply disabled that code entirely in their fork of IKVM:
//#DllImportAttribute.Annotation(value = "user32.dll", EntryPoint = "RegisterClipboardFormat")
//private native static int _RegisterClipboardFormat(String format);
#cli.System.Security.SecuritySafeCriticalAttribute.Annotation
private static int RegisterClipboardFormat(String format)
{
throw new Error("Not implemented");
//return _RegisterClipboardFormat(format);
}
https://github.com/ams-ts-ikvm/cn1-ikvm-uwp/blob/master/openjdk/sun/awt/IkvmDataTransferer.java#L95
Any ideas? Thanks!
There seems to be a workaround by not changing any code at all: The settings of the Release-build contain a checkbox if to use the .NET native toolbox for the build, which is enabled by default. By disabling that the build succeeds without any code change and is as fast as the Debug-build again. Before changing that, the Release-build took a lot longer as well.
Don't know what that means regarding actually calling native code, if that fails or not, because my app doesn't use those. I guess it would fail, depending on if it works in Debug or not. Additionally, I'm not sure if the Windows store accepts such a modified Release-build, but as UWP-apps aren't forced to use native code at all, I guess there's a good chance things are going to work.
I have to display build version automatically without entering manually in windows form application, I have tried something like [assembly: AssemblyVersion("1.0.*")]
in assemblyInfo.cs but its show like below,
{1.0.7145.41554} its looks awkward
I want show something like this [1.0.0.13] after published, but it always takes [1.0.0.1]
see the below image I want to show that version in view page actually
This is how I'm getting version; but it is returning [1.0.0.1]
//Get Version of the currently executing Assembly
var anm = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version;
ExistingVersion = String.Format("{0}", anm);
EMajor = anm.Major;
EMinor = anm.Minor;
EBuildNo = anm.Build;
ERevisionNo = anm.Revision;
lblVersionv.Text = String.Format("Current Version : {0}", anm);
How I can do that?
It is a bit convoluted but you can reach this info from your own code and then decide to display it how you like.
First step is the most critical, you need to get a Type from one of your own classes.
You can use your main form class for example
Type myApp = Type.GetType("your-full-qualified-class-name-here");
So suppose your namespace is "MyApplication" and your main form class is named "MyStartupForm" then you should replace the string above with "MyApplication.MyStartupForm" (be precise with upper/lowercase letters)
Now with the type you could get the the Version information with
Version v = myApp.Assembly.GetName().Version;
And finally the version variable will have all the info you need.
(Look at the property Build, Version, Revision, MinorRevision, MajorRevision)
Note also that the override for the ToString method will return to you a single string with all the information required
I solve this by adding below code
if (ApplicationDeployment.IsNetworkDeployed)
{
lblVersionv.Text = string.Format("Version : {0}",ApplicationDeployment.CurrentDeployment.CurrentVersion.ToString(4));
}
Our build process updates the forth digit (buildnumber or revision) of the version number on every build.
I'm using the following code to try and get the version so that it can be displayed on the splash screen and about page.
var version = Assembly.GetEntryAssembly().GetName().Version;
var programName = "Version: " + version;
How come the 4th digit in the version number is always zero, and what can I change to get it to property reflect the build number?
Any assembly has two metadatas: the assembly version and the file version. The assembly version I don't know exactly how to take it. It seems that there is an AssemblyVersionAttribute but when I try to search for it, a null reference is returned.
But the File version you can take using this code:
public static Version GetAssemblyVersion (Assembly asm)
{
var attribute = Attribute.GetCustomAttribute(asm, typeof(AssemblyFileVersionAttribute), true) as AssemblyFileVersionAttribute;
return new Version(attribute.Version);
}
Generally, I use to synchronize so that file version = assembly version every time so I can grab assembly version using this code. Third party libraries, from my experience I can tell that are following this pattern also.
I have a program that I have written and am trying to create an about box for. I recently updated my program's product version to 1.00.0003, and I want this to be reflected in the about window.
The default setup of the aboutBox shows a value of 1.0.0.0, which is the assembly version, not the product version. I have since been scouring the Internet to find how to get the product version to be shown. I have tried all of these:
{
Assembly assembly = Assembly.GetExecutingAssembly();
FileVersionInfo fileVersionInfo = FileVersionInfo.GetVersionInfo(assembly.Location);
string version = fileVersionInfo.ProductVersion;
Debug.WriteLine(version);
Debug.WriteLine(assembly.GetName().Version);
string v = VersionNumber;
Debug.WriteLine(v);
Debug.WriteLine( fileVersionInfo.FileVersion);
Debug.WriteLine(Application.ProductVersion);
Debug.WriteLine(AssemblyProductVersion);
Assembly assembly2 = Assembly.GetEntryAssembly();
FileVersionInfo fileVersionInfo2 = FileVersionInfo.GetVersionInfo(assembly.Location);
string version2 = fileVersionInfo2.ProductVersion;
Debug.WriteLine(version2);
Debug.WriteLine(assembly2.GetName().Version);
return version;
}
private string _ourVersion = "Version: v";
private string VersionNumber
{
get
{
System.Reflection.Assembly _assemblyInfo =
System.Reflection.Assembly.GetExecutingAssembly();
if (System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed)
_ourVersion += ApplicationDeployment.CurrentDeployment.CurrentVersion.ToString();
else
{
if (_assemblyInfo != null)
_ourVersion += _assemblyInfo.GetName().Version.ToString();
}
return _ourVersion;
}
}
private static string AssemblyProductVersion
{
get
{
object[] attributes = Assembly.GetExecutingAssembly()
.GetCustomAttributes(typeof(AssemblyInformationalVersionAttribute), false);
return attributes.Length == 0 ?
"" :
((AssemblyInformationalVersionAttribute)attributes[0]).InformationalVersion;
}
}
Every single one of these returns 1.0.0.0 (yes, I did look for their output in the console, not what was actually displayed), instead 1.00.0003 like I need. The product version is set in the General Information tab of the InstallShield setup. When it is installed, going to Programs and Features shows a Product Version of 1.00.0003, so I cannot figure out why this is so hard to programmatically retrieve this value. Any ideas?
Your product version should match the assembly version - have a look at How to make Product Version property match executable's version number automatically
The version 1.00.0003 you want to retrieve is the version of the installer of your product. To get this version programmatically you need to inspect the installer (MSI file), not the installed files. I'm not sure that is what you want to do but there is a answer to the question Checking ProductVersion of an MSI programatically that explains how to do that.
If you want your executable files to contain the same version number you need to store the version number in some way either using a .NET attribute like AssemblyFileVersion or a Windows VERSIONINFO resource.
InstallShield allows you to specify the product version on the command line. This allows you to store your product version in a single file and then use that as the source of both the product version embedded in your installer as well as AssemblyFileVersion of your assemblies.
If only the installer knows about this version information, the only place you could retrieve it from would be the registry.
Uninstall Registry Key:
The following installer properties give the values written under the registry key:
VersionMinor Derived from ProductVersion property
VersionMajor Derived from ProductVersion property
Version Derived from ProductVersion property
But I'd go with #devdigital's (implied) suggestion - you ought to have one of the assembly versions actually matching your installer version.
Application.ProductVersion is not showing the incremental version. can anybody help me how to perform this, using C# ?
You can have build and revision incremented for you but not major and minor.
Simply substitute
[assembly: AssemblyVersion("1.0.0.0")]
with
[assembly: AssemblyVersion("1.0.*")]
in the AssemblyInfo.cs
Have you tried grabbing the Assembly's version?
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version;
Perhaps this is what you are looking for.
Also check out this other SO post - I think this is what you are looking for.
Automatically update version number
Below is a second link to a .Net add-in that automatically increments the:
Major
Minor
Build
Revision
http://testdox.wordpress.com/versionupdater/
I have found that it works well to simply display the date of the last build using the following wherever a product version is needed:
System.IO.File.GetLastWriteTime(System.Reflection.Assembly.GetExecutingAssembly().Location).ToString("yyyy.MM.dd.HHMM")
Rather than attempting to get the version from something like the following:
System.Reflection.Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly();
object[] attributes = assembly.GetCustomAttributes(typeof(System.Reflection.AssemblyFileVersionAttribute), false);
object attribute = null;
if (attributes.Length > 0)
{
attribute = attributes[0] as System.Reflection.AssemblyFileVersionAttribute;
}