Closed marcosnz closed 9 years ago
Based on your description here, does the website ever try to parse the key value directly itself? I can imagine the scenario where a user runs an outdated version of the client, but the website has been updated with new code that has the ability to interpret the client-provided key and try looking up the name itself right then. Does this happen this way or could this be added too?
The website doesn't try to parse the key. I thought the likelihood of someone using an outdated client wasn't worth the extra effort. Hmm... I was thinking that it would be a duplication but actually if we always sent the release key to the website rather than the version then the logic could all reside on the server. I'll take a crack at that...
@binki I have moved the translation logic to the website (and hopefully improved it a little). @shanselman is this a move you're happy with?
@marcosnz Nice. One small thing I noticed with this change is that, since the new client does not specify realversion
, the JavaScript does not flip the text to show “We found .NET!”. See https://github.com/marcosnz/SmallestDotNet/blob/ce846c63bb7841d922be7c5265e8d20b995ec446/SmallestDotNet/Default.aspx#L152 , probably can just swap in 'releaseKey'
there.
@binki Nice catch. Fixed.
@shanselman thanks for merging the pull request. Looks like the exe at https://github.com/downloads/shanselman/SmallestDotNet/CheckForDotNet45.exe hasn't been updated though? Still returning a version rather than a release key...
This commit has the .Net Application checker return the releaseKey from the registry if it's not a known key tied to a .Net version. The website then uses this information to tell the user that it can't find the exact version and suggests they log an issue with the given release key. This is in response to issue #41: Handle unknown releases better.