6 ms·

the highlights are great. 2 lowlights: - HttpClient/WebRequest ReadWriteTimeout is silently ignored which can result in infinitely hung sockets when doing sync

• ComputerGuru 6y ago
  The ReadWriteTimeout issue was insanely aggravating; MS was adamant it was not a bug but rather an internal implementation detail for the longest time. I'm really glad they changed their minds because it was a very unexpectedly petty stance they were taking in the GitHub issue.
  • mmd45 6y ago
    what makes you say they changed their mind? afaik it's same old story. it's really incomprehensible given that all they need to do is make a call on the underlying socket.
• ocdtrekkie 6y ago
  Refusing to support System.Speech is why my project will remain locked to .NET Framework. Apparently the Microsoft Speech team is part of Azure now, and has decided nobody needs local speech synthesis that doesn't require a subscription to a cloud service.
  • mwcampbell 6y ago
    IIUC, System.Speech was simply a .NET wrapper for the Microsoft Speech API (SAPI), which has been part of Windows for a long time. If you want to move to .NET Core, you can use SAPI via COM interop. Disclosure: I currently work at Microsoft on the Windows accessibility team. We don't own SAPI or System.Speech, but we consume SAPI in Narrator (via COM in C++).
    • mmd45 6y ago
      why doesn't MS just release the SAPI wrapper as a windows only nuget package since it already exists?
      • mwcampbell 6y ago
        One thing I've learned in my time on the accessibility team at MS is that even at a company as large as Microsoft, any given team has limited resources and only so many person-hours in a day. So every task has to have a business justification. There probably hasn't been enough demand for releasing System.Speech as a NuGet package to justify it. That's just my guess though; I haven't talked to the speech or .NET teams about this.
        • mmd45 6y ago
          i understand that, but i'll bet if they would dump the source to dotnet/unsupported/system.speech the community would do the work for them to get squared up with dotnet core. it doesn't take a lot of demand, just 1 or 2 developers who view it as a blocking requirement for netcore migration.
        • ocdtrekkie 6y ago
          https://www.microsoft.com/en-us/accessibility https://www.microsoft.com/en-us/accessibility "Microsoft is committed to revolutionizing access to technology for people living with disabilities—impacting employment and quality of life for more than a billion people in the world." "To enable transformative change accessibility needs to be a priority. That’s why we have begun to manage it like a business and developed our Accessibility Evolution Model to track our progress." I feel if these statements are true, Microsoft executives should require good maintenance of APIs heavily depended on by accessibility features, and should direct the appropriate teams to prioritize this issue. Because today, in pushing developers to move to a platform that doesn't support System.Speech, Microsoft is moving backwards.
    • ocdtrekkie 6y ago
      I recognize this. But so is WinForms and plenty of other Windows-specific APIs. System.Speech, being as you recognize, a crucial accessibility feature, and it should be considered extremely high priority, even if the usage percentage is low. Microsoft should prioritize fixing this over other tasks with .NET, if they value accessibility users. It'd be nice for a cross-platform local speech library to be available on .NET, and it'd be nice if the Speech team wasn't likely incentivized to push Azure, but at minimum, existing accessibility functionality should be understood to be crucial.
      • mwcampbell 6y ago
        > System.Speech, being as you recognize, a crucial accessibility feature I'm the first to push for prioritizing accessibility when needed. But there's a difference between an accessibility gap that prevents a person with a disability from completing some task, and a missing convenience wrapper for an API that a developer could pretty easily use through generic COM interop. So I don't think it's appropriate to play the accessibility card in this case.
        • ocdtrekkie 6y ago
          I mean, nearly all outstanding documentation and tutorials on how to implement speech in Windows is conveyed via those APIs. I know I don't have the skills to replace my System.Speech calls with generic COM interop, I'm willing to bet that would ring true for a lot of .NET developers relying on the .NET Framework today. At minimum, you're adding a "rewrite your accessibility code" cost to anyone moving from .NET Framework to .NET Core. How many businesses are going to do that, versus say, drop that feature, presumably due to "low usage"? Is Microsoft really serving the accessibility community here? Making it harder to add accessibility to software is going to negatively impact accessibility being available in software. And if it's just a convenience wrapper, it should be trivial for Microsoft to reimplement it: And it'd be far less wasteful for Microsoft to do it for everyone than expect everyone who uses it for accessibility features to reimplement it themselves.
          • mwcampbell 6y ago
  • Gibbon1 6y ago
    That really dumb because outside of VC companies with an obsession with spying on people and selling their data, no one wants the risk of uploading audio to the cloud.
• jackfoxy 6y ago
  System.Speech has sadly not been supported since the beginning of .NET (as in dotnet, not the framework) That pretty much means MS is deprecating it in favor of the Azure speech services...yeah, bummer.
• hackerfromthefu 6y ago
  Ouch! HttpClient/WebRequest ReadWriteTimeout never timing out is going to affect a lot of systems and result in production issues.