if not specified in HOCON, set AppVersion to executing assembly version #4618
Conversation
just so users don't have to manage application versions in two places -have Akka.Cluster.ClusterSettings automatically use the entry assembly's 'Major.Minor.Revision' version - that way if the developers are automatically bumping their entry executable's version, that is what will be reflected in HOCON. If the user takes the time to manually input their akka.cluster.app-version - that value will be used instead.
|
Looks like we have a compilation failure here after 35 minutes? That's weird... |
|
Looks like we timed out while compiling the multi-node test runner: |
|
looks like the hung build was a fluke - ran fine the second time |
|
Looks like there's an error with how the revision number gets used in this PR - but so far this feature is working very nicely. |
|
Not sure, but it might be better to hide this functionality behind some config switch. |
good point - I'll change the configuration around and to the following:
Does that seem like a reasonable compromise? |
AppVersion now derives its value from `Assembly.GetEntryAssembly()` or `Assembly.GetExecutingAssembly()` (in case the former is `null`) by default. The `akka.cluster.app-version` now defaults to `assembly-version` by default, which sets this behavior. To change that, simply use a different value.
| # app-version = "1.1-beta1" | ||
| # app-version = "1" | ||
| # app-version = "1.1" | ||
| app-version = assembly-version |
There was a problem hiding this comment.
Changed the default value here to assembly-version, which activates this assembly-scanning default behavior
| } | ||
|
|
||
| public static AppVersion Create(string version) | ||
| { | ||
| var v = new AppVersion(version); | ||
| // check to see if we're going to use the assembly-version | ||
| if (version.Equals(AssemblyVersionMarker, StringComparison.InvariantCultureIgnoreCase)) |
There was a problem hiding this comment.
Check to see if we're using assembly-version - if so, get the assembly data. If not, parse the version string as usual.
|
|
||
| // if the entryAssembly is null (which can happen when we're called from unmanaged code) | ||
| // then fall back to the executing assembly for the version number. | ||
| var targetAssembly = entryAssembly ?? Assembly.GetExecutingAssembly(); |
There was a problem hiding this comment.
Grab the EntryAssembly preferably. If this value is null, which can happen when called from unmanaged code (this happens when the XUnit test runner is executing from within visual studio, for instance) then fallback to the ExecutingAssembly version. Shouldn't happen in most Akka.NET applications, which tend to be launched as 100% managed processes.
just so users don't have to manage application versions in two places -have Akka.Cluster.ClusterSettings automatically use the entry assembly's 'Major.Minor.Revision' version - that way if the developers are automatically bumping their entry executable's version, that is what will be reflected in HOCON.
If the user takes the time to manually input their akka.cluster.app-version - that value will be used instead.
cc @zbynek001