You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Version.txt should use file version from assembly custom attributes not FileVersionInfo #4505
The changes made in issue #3132 have introduced a bug due to relying on a physical location for the assembly. If the Microsoft.ML.Core assembly is loaded from memory the assembly.location will be empty. Using FileVersionInfo.GetVersionInfo relies on a physical path - so an argument exception is thrown inside System.IO.Path since the supplied path is empty.
Instead of using FileVersionInfo.GetVersionInfo the assembly custom attributes should be used, for example: var productVersion = assembly.CustomAttributes.FirstOrDefault(a => a.AttributeType == typeof(AssemblyFileVersionAttribute)).ConstructorArguments.First();
This will return the same product string version as the FileVersionInfo.GetVersionInfo does.
thanks @r0ss88 . This seems like a good find but in what scenarios can we be loading this assembly from memory and it will not be present on disk?
Happy to contribute. In my scenario I am working with a system where assemblies can be loaded from disk or stored in a database. Though in this case they are loaded from disk the assembly is read as bytes then loaded - hence location is blank.
@codemzs FileVersionInfo is not correct either way. This should be using the AssemblyInformationalVersion attribute (when present). If you use GitVersioning to generate the assembly attributes, it will produce an internal static class that you can reference directly for any information you need. Other version generation tools may do something similar. Otherwise, an approach like I used for ANTLR's code generator can be used:
Activity
Remove reliance on getting product version for model.zip/version.txt …
codemzs commentedon Nov 30, 2019
thanks @r0ss88 . This seems like a good find but in what scenarios can we be loading this assembly from memory and it will not be present on disk?
r0ss88 commentedon Dec 2, 2019
Happy to contribute. In my scenario I am working with a system where assemblies can be loaded from disk or stored in a database. Though in this case they are loaded from disk the assembly is read as bytes then loaded - hence location is blank.
r0ss88 commentedon Jan 2, 2020
@codemzs happy new year, any update?
sharwell commentedon Jan 2, 2020
@codemzs FileVersionInfo is not correct either way. This should be using the AssemblyInformationalVersion attribute (when present). If you use GitVersioning to generate the assembly attributes, it will produce an internal static class that you can reference directly for any information you need. Other version generation tools may do something similar. Otherwise, an approach like I used for ANTLR's code generator can be used:
https://github.com/tunnelvisionlabs/antlr4cs/blob/12f3271157c2df1984eac7009d71c929fd070f20/runtime/CSharp/Antlr4.Tool/AntlrTool.cs#L39-L45
Fixes dotnet#4505 Remove reliance on getting product version for mode…