Commit e56a8c8
authored
[build] Always use 4-tuple versions (#901)
Context: 2d5431f
Commit 3e6a623 inadvertently "broke the world" by causing the
version of `Java.Interop.dll` to change to 0.1.2.0, which was
backward-compatible -- older assemblies would work with newer code --
but not [forward compatible][0]: you couldn't build an assembly
against the latest version of Xamarin.Android and use it with older
versions of Xamarin.Android, as 0.1.0.0 couldn't satisfy 0.1.2.0.
This was doubly unfortunate, as `Java.Interop.dll` hadn't changed.
This was fixed in commit 2d5431f, by "simply" resetting the
`$(Version)` MSBuild property of `Java.Interop.dll` & co. back to
0.1.0.0.
*However*, commit 2d5431f introduced it's own (smaller) breakage:
the `[assembly: AssemblyFileVersion]` value was wrong.
This didn't break anything, but does makes for a rather "odd"
experience when looking at the Java.Interop.dll Properties panel
within Windows Explorer:

The **File version** value is shown as 0.0.0.0.
The File version value is shown as 0.0.0.0 because the value is
actually *invalid*; it's a "5-tuple", with the generated
`AssemblyInfo.g.cs` containing:
[assembly: System.Reflection.AssemblyFileVersionAttribute("0.1.0.0.0")]
This "5-tuple" doesn't result in a compilation error, but does cause
the file version information to not be set at all.
Commit 2d5431f encountered a similar scenario with
`[assembly: AssemblyVersion]`, which resulted in a CS7034 error:
error CS7034: The specified version string does not conform to the required format - major[.minor[.build[.revision]]]
Commit 2d5431f fixed the CS7034 by removing a `.0` from
`AssemblyInfo.g.cs.in` for `[assembly: AssemblyVersion]`, but
neglected to remove the `.0` from the similarly structured
`[assembly: AssemblyFileVersion]` line.
Fix the File version value in the Java.Interop.dll Properties dialog
by doing two things:
1. Update `AssemblyInfo.g.cs.in` so that
`[assembly: AssemblyFileVersion]` doesn't append `.0`, thus
ensuring that `Java.Interop.dll` has a "4-tuple" value.
2. Update the `GenerateVersionInfo` target in `VersionInfo.targets`
so that the default replacement for `@VERSION@` is a 4-tuple.
This ensures that we consistently use 4-tuple Version values, and
fixes the Java.Interop.dll Properties dialog to show the correct
value for the File version property.
[0]: https://en.wikipedia.org/wiki/Forward_compatibility1 parent 79744f6 commit e56a8c8
2 files changed
+2
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
14 | 14 | | |
15 | 15 | | |
16 | 16 | | |
17 | | - | |
| 17 | + | |
18 | 18 | | |
19 | 19 | | |
20 | 20 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
16 | 16 | | |
17 | 17 | | |
18 | 18 | | |
19 | | - | |
| 19 | + | |
20 | 20 | | |
21 | 21 | | |
22 | 22 | | |
| |||
0 commit comments