The auto updater will gladly install the latest version on Windows 10 1511, however the required .NET 4.7 is only available for 1607 and newer.
(Yes I know 1511 is end of life soon, we move slowly here...)
Then perhaps you need to make this clear in the update notes because currently it's not listed at all, or add the logic to the update to not prompt for the update if the base OS isn't even compatible. I just wasted my time updating, only to have uninstall it and go download and reinstall the previous version because our org is only on 1607. You can't expect users to update their OS just so they can use your app. Especially considering MS just made 1704 widely available last week. I'm sorry, this is seriously short-sighted and has caused me to question whether to keep using this app at all..
I'm sorry to hear that. Unfortunately we will not be able to provide a 4.2 build compiled against .NET 4.6.x. I suggest you keep on using 4.1 until you are running 1607 or later. You can find all previous version of Royal TS here:
I'm really sorry for the inconvenience. Please accept my apologies.
Unfortunately we also weren't aware that Microsoft did not support .NET 4.7 on Windows 10 1511. Since MS supports .NET 4.7 on Windows 7SP1 upwards, we really missed the fact that Windows 10 1511 was not supported. I'm not sure why MS doesn't support .NET 4.7 on there but we had to move to .NET 4.7 because a Windows update broke Royal TS on .NET 4.6 two months ago where the app crashed on startup without any reason and this affected a lot of users. After providing a beta build using .NET 4.7 those crashes magically went away. We ran .NET 4.7 based betas for more than two months and unfortunately it seemed that none of our beta users tried that on a Windows 10 1511 build.
As soon as we learned that .NET 4.7 is not supported on 1511 we updated our System Requirement page. In the next update notification message we will also state that this update will only work with .NET Framework 4.7 on Windows 10 1607 or later.
Again, I'm sorry for the inconvenience and I deeply regret that we missed that detail. I already contacted Microsoft to clarify, why .NET 4.7 is not supported on Windows 10 1511 while it is supported on Windows 7 SP1.
I got same problem and it is very amazing before (and ennoying after) to know that you don't alert customers they won't use the application anymore if they don't upgrade their Windows 10 version ....
I'm really amazed for your change management policies ....
Thank you for the very thorough reply. Carry on!
Would it be possible to prevent the installer for 4.2 from installing on 1511? A bunch of people at work that I turned on to RoyalTS had to uninstall and reinstall because there was no warning. They have not updated us at work yet.
I'm sorry you faced issues with the upgrade. Please accept my apologies but I want to mention that we put in a warning in the update notification to make users aware of the .NET framework issue:
This is really short sighted.
I used chocolatey to update - which is automated and never presents a user dialog - you are relying non-automated installs to handle this problem.
The real question is why is your development team taking a dependency on .NET 4.7 this early in it's release cycle - early adoption of .NET runtimes is a bad idea. Especially if your customers run other software that they discover is INCOMPATIBLE with .NET 4.7.
Yes I did read the thread - it is common for developers to underestimate the impact of requiring a new version of .NET and the sensitivities of other software and dependencies this invokes (as this thread also shows).
I work with this a bit with my day job, below are some resources that might help. If you could try to get to 4.6.2 to fix your problem - that could be a much better place to be in.
Do you know the specific KB ID of the offending update?
.NET Framework Compatibility Diagnostics - detailed, built-in, static code analysis of moving source code from it's current target framework version to a new target framework version.
we tried all 4.6.x versions - without success. We are not sure which KB/update was responsible. We were also not able to repro the issue on our side (same OS and patch level). It was quite a weird error and I've seen it myself on some customer machines remoting into them. We actually never found out what the cause was - all we know the app crashed hard (not a managed exception) before any of our code ran. While we were investigating the issue, we got more and more crash reports and when we built a beta release targeting .NET 4.7, the crashes were gone magically. Since we had no clue about the cause and couldn't really find any commonality (those were all different OS and patch levels), we only suspected a Windows update to be the cause of this because those crash reports were all coming in within a couple of days from all over the world.
Since targeting .NET 4.7 resolved the issue for all affected users, we decided to stick with it and extended the beta phase for 4.2. Since .NET 4.7 was running on Windows 7 SP1 and later, we missed the small detail that it was not able to run on Windows 10 pre-Anniversary Update. Who would think that MS didn't support that particular OS version when it supported Windows 7 SP1?! That was quite shocking. I even asked MS about their policy to not support these Win 10 builds and their response was something like: we know but these Win 10 builds are soon not supported anymore and therefore we didn't bother to test this...
I'm really sorry about the inconvenience but since you are a developer yourself, what would you have done when more and more users are quite upset that the app they paid for suddenly didn't work anymore and this was the only solution?
I would agree that MS is being short sighted in trying to push people forward on Windows 10 releases with sillyness like this.
You might want to try a procmon trace of a failing case next time you come across it. There is also a cool tool for comparing two procmon traces (of a failing and working system): http://www.nektra.com/products/spystudio-api-monitor/download/
I have also created a chocolatey package for it: https://chocolatey.org/packages/spystudio