{"action":"opened","issue":{"url":"https://api.github.com/repos/dotnet/core-setup/issues/4453","repository_url":"https://api.github.com/repos/dotnet/core-setup","labels_url":"https://api.github.com/repos/dotnet/core-setup/issues/4453/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/core-setup/issues/4453/comments","events_url":"https://api.github.com/repos/dotnet/core-setup/issues/4453/events","html_url":"https://github.com/dotnet/core-setup/issues/4453","id":349845537,"node_id":"MDU6SXNzdWUzNDk4NDU1Mzc=","number":4453,"title":"Make Environment.Version return the actual runtime version","user":{"login":"steveharter","id":6986755,"node_id":"MDQ6VXNlcjY5ODY3NTU=","avatar_url":"https://avatars0.githubusercontent.com/u/6986755?v=4","gravatar_id":"","url":"https://api.github.com/users/steveharter","html_url":"https://github.com/steveharter","followers_url":"https://api.github.com/users/steveharter/followers","following_url":"https://api.github.com/users/steveharter/following{/other_user}","gists_url":"https://api.github.com/users/steveharter/gists{/gist_id}","starred_url":"https://api.github.com/users/steveharter/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/steveharter/subscriptions","organizations_url":"https://api.github.com/users/steveharter/orgs","repos_url":"https://api.github.com/users/steveharter/repos","events_url":"https://api.github.com/users/steveharter/events{/privacy}","received_events_url":"https://api.github.com/users/steveharter/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-08-12T21:28:43Z","updated_at":"2018-08-12T21:28:43Z","closed_at":null,"author_association":"MEMBER","body":"@davidfowl commented on [Mon Jul 16 2018](https://github.com/dotnet/corefx/issues/31099)\n\nToday on a .NET Core 2.1.0 project printing `Environment.Version` prints out `4.0.30319.42000` which is a hard coded constant in the runtime https://github.com/dotnet/coreclr/blob/ce0a2617d40bc217b8e0a2137e340afe585afcb1/src/System.Private.CoreLib/src/System/Environment.cs#L277. This should print out the *actual* runtime version based on the policy applied by the host (like 2.1.1 if that's what runtime version is actually being used).\r\n\r\nThis also needs to be used as the version logged into the event log when there's an unhandled exception reported by the runtime. Today is a bogus version which isn't very useful. \n\n---\n\n@weshaggard commented on [Mon Jul 23 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407190291)\n\nToday we don't have the \"marketing version\" (i.e. 2.1.1) embedded anywhere that we can consume so the best we could really do would be to return the file version of corelib. \n\n---\n\n@jkotas commented on [Mon Jul 23 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407194700)\n\nThe host knows this version - it can pass it to the runtime as key-value pair.\n\n---\n\n@weshaggard commented on [Mon Jul 23 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407197277)\n\n>The host knows this version - it can pass it to the runtime as key-value pair.\r\n\r\nI assume it only knows it for applications running on the shared framework correct? What should we return for standalone applications?\n\n---\n\n@jkotas commented on [Mon Jul 23 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407202854)\n\nAll applications have it in .deps.json file.\n\n---\n\n@weshaggard commented on [Mon Jul 23 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407205744)\n\nI assume you are referring to the package version for Microsoft.NETCore.App (or runtime.[rid].Microsoft.NETCore.App) then? If so yes that may work for now but that may not be in the deps file in the future but we could probably ensure some version remains for this purposes. \n\n---\n\n@abbotware commented on [Mon Jul 23 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407274807)\n\nI've been looking for away to get the RuntimeFrameworkVersion, so I tried all the API's that I could find (#31249) and none seemed to return anything useful - Any programmatic way to get the 'marketing version' would be good enough for me.  \r\n\r\n@weshaggard is there is a 1:1 mapping for 'corelib version' to 'marketing version' ?  If yes, then could a lookup table be constructed?\r\n\r\nRegarding versions returned from API calls, I am kinda curious though why the difference in System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription: `.NET Core 4.6.26614.01` and Environment.Version: `4.0.30319.42000` \r\n\r\nIf one of those could be used to map back to the RuntimeFrameworkVersion, then there is at least a workaround for now?\r\n\n\n---\n\n@davidfowl commented on [Tue Jul 24 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407287980)\n\nThe host needs to pass the value to the runtime, the property would then read an AppContext property  (or something similar) to get the actual version.\r\n\r\nThe host already does this for the deps file path in order to pass it to the DependencyModel API. https://github.com/dotnet/core-setup/blob/84fa44f892b42ad9235e4ecb756975d8c8f46f1f/src/corehost/cli/hostpolicy.cpp#L104\r\n\r\nWe just need to do this for the version as well.\n\n---\n\n@weshaggard commented on [Tue Jul 24 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407466415)\n\n>@weshaggard is there is a 1:1 mapping for 'corelib version' to 'marketing version' ? If yes, then could a lookup table be constructed?\r\n\r\nYes the corelib version is 1:1 with the marketing version but doesn't exactly match it. If you workaround this for now you can get the version of corelib the same way we do for FrameworkDescription https://github.com/dotnet/corefx/blob/master/src/System.Runtime.InteropServices.RuntimeInformation/src/System/Runtime/InteropServices/RuntimeInformation/RuntimeInformation.cs#L28. \r\n\r\n@davidfowl I agree the host can pass the value to the runtime it is just a matter of how it gets it in the various cases as well as what this API would do for custom hosts. We have to cover all the cases. \r\n\r\n\n\n---\n\n@davidfowl commented on [Tue Jul 24 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407471540)\n\n> We have to cover all the cases.\r\n\r\nSure, just make it a contract. We look at a specific AppContext variable which is controlled by the host. In absence of that, we show something that doesn't mean much to you (the CLR file version or something).\n\n---\n\n@steveharter commented on [Tue Jul 24 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407473652)\n\nTalked to @davidfowl a bit. I think the most straightforward way to do this is for the hostpolicy to add a couple AppContext\\AppDomain variables like \"FRAMEWORK_NAMES\" and \"FRAMEWORK_VERSIONS\". They would list each framework and found\\actual version (not requested version) separated by a delimiter.\r\n\r\nWe already do similar things with \"FX_DEPS_FILE\" that is picked up later by the CLI.\r\n\r\nThis information could we wrapped by a managed class in the future (Environment or otherwise).\r\n\n\n---\n\n@steveharter commented on [Tue Jul 24 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407475275)\n\nAdding a \"FRAMEWORK_NAMES\" and \"FRAMEWORK_VERSIONS\" would not work for standalone; we would need a mapping from deps.json version as explained earlier or some other mechanism depending on what info we want\n\n---\n\n@steveharter commented on [Tue Jul 24 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407475994)\n\nOverlaps a bit with https://github.com/dotnet/core-setup/issues/4112 for logging this information\n\n---\n\n@abbotware commented on [Tue Jul 24 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407489055)\n\n@steveharter does 'standalone' = 'self contained deployment' (SCD) ?   (In my case I am using an Ubuntu SNAP to deploy .Net Core + my App + Native libs on Linux)\n\n---\n\n@davidfowl commented on [Tue Jul 24 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407529983)\n\n@weshaggard @jkotas If we change this property to be useful does that count as a breaking change? Specifically because it would go backwards?\n\n---\n\n@weshaggard commented on [Tue Jul 24 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407541233)\n\n>@weshaggard @jkotas If we change this property to be useful does that count as a breaking change? Specifically because it would go backwards?\r\n\r\nEvery change is a breaking change :) however if we don't have any evidence that it will break people then we will assume it is not a breaking change. If enough folks get broken then we may change our mind about how we fix it. \n\n---\n\n@steveharter commented on [Tue Jul 24 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407562501)\n\n>> does 'standalone' = 'self contained deployment' (SCD) ? (In my case I am using an Ubuntu SNAP to deploy .Net Core + my App + Native libs on Linux)\r\n\r\nYes.\r\n\r\nFrom the host perspective, the easiest implementation for both self-contained and framework-dependent would be to simply add a \"FX_DEPS_FILES\" context variable, similar to existing \"FX_DEPS_FILE\", but lists the path to the app's deps.json, every framework deps.json and perhaps those specified by additional-deps as well. For self-contained, there would only be one deps.json.\r\n\r\nThen the managed layer would need to read each deps file and use a json parser (probably just use DependencyModel like [this](https://github.com/dotnet/cli/blob/master/src/Microsoft.DotNet.Cli.Utils/FrameworkDependencyFile.cs#L25)) to obtain the desired framework(s) by name and report back on the version.\r\n\r\nBesides being simpler for the host, an advantage would also allow the managed layer to report on any types of other dependencies, including non-frameworks, assembly versions, etc if those were useful for logging. \r\n\r\nThe disadvantage is that it creates a dependency on the deps.json for the managed layer, which can change over time.\r\n\r\nWhen we decide on a plan, I'll move this issue over to core-setup.\r\n\n\n---\n\n@jkotas commented on [Wed Jul 25 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407650734)\n\n> Then the managed layer would need to read each deps file and use a json parser (probably just use DependencyModel like this)\r\n\r\nI do not think we would want to create dependency from `Environment.Version` (very low-level API) to DepenendencyModel.\n\n---\n\n@davidfowl commented on [Wed Jul 25 2018](https://github.com/dotnet/corefx/issues/31099#issuecomment-407653441)\n\nI'd prefer we just set the version data direction in the host properties instead of using the deps file. Agree with @jkotas, we can't take a dependency in mscorlib on `deps.json`. It should be host agnostic.\n\n"}}
{"actor":{"display_login":"steveharter"}}