12 ms·
I was kinda looking at migrating my project over to .NET Core/.NET 5 lately... turns out that despite bringing over Windows Forms and WPF support, Microsoft ref
by ocdtrekkie 6y ago
I was kinda looking at migrating my project over to .NET Core/.NET 5 lately... turns out that despite bringing over Windows Forms and WPF support, Microsoft refuses to port System.Speech for text-to-speech and speech recognition.
Turns out the reason why is that since the Speech team moved under Azure, the Speech team considers System.Speech "replaced" by Azure's cloud-based speech services. Kinda takes any idea I had of moving to Microsoft's modern platform off the table for me, because local-only functionality is a must-have in my book. And there's no reason my Windows machine shouldn't be able to do the same local-based speech capability PCs have had for the past couple decades without the cloud.
- gameswithgo 6y agono third party libraries that fit the bill?
- ocdtrekkie 6y agoI investigated a little bit, but most of the speech libraries on NuGet are either wrappers for Google/Microsoft/Amazon/IBM cloud services, or are dependent on System.Speech anyways. It's plausible if I really wanted to, I could run a separate service/application from some non-.NET-based alternative, but the integration is likely to be a lot messier. Right now, I'm not sure .NET 5 offers a compelling reason to drop .NET Framework, which Microsoft will presumably continue to support for at least the next decade. Microsoft still lacks a cross-platform desktop UI framework, they have no project template in Visual Studio that would let you write a service that can run as a service on both Windows and Linux, and .NET 5 is missing lots of Windows integration functionality like System.Speech as well. I'd really like to make my project both run as a service, and run cross-platform, but there doesn't appear to be a good path to do either one with .NET 5 yet, and it'd likely take substantial rewriting just to get my project to .NET 5 on Windows.
- ripley12 6y ago> they have no project template in Visual Studio that would let you write a service that can run as a service on both Windows and Linux I have lots of complaints about the state of the .NET ecosystem, but thankfully this one is pretty easy IMO. Basically just use the `dotnet new worker` .NET Core template; it scaffolds a project using the ASP.NET Core generic host, which can easily (a NuGet package and 1 line of code) be adapted to run as either a Windows Service or a systemd service on Linux. https://www.hanselman.com/blog/dotnetNewWorkerWindowsServicesOrLinuxSystemdServicesInNETCore.aspx https://www.hanselman.com/blog/dotnetNewWorkerWindowsService... https://www.reillywood.com/blog/dotnet-linux https://www.reillywood.com/blog/dotnet-linux
- ocdtrekkie 6y agoIt might be somewhat simple, but their paid Visual Studio IDE demonstrates no way to get there, and it probably should. The only project types tagged as services are .NET Framework templates to make a Windows service. I have to apparently read blog posts about how to get there myself with .NET Core. Suffice to say, Microsoft's move to the open source/Linux mindset may have come at the cost of being similarly confusing to get started with. Note that your blogs happily tell me to add a single NuGet package for Windows or Linux, but doesn't bother to tell me how to assemble a project that will work on both.
- ripley12 6y agoSeems like you can just call both UseWindowsService() and UseSystemd(), they will no-op if called on the wrong platform. Personally I think I'd rather split Linux+Windows into thin OS-specific projects, but I haven't tried that. Agreed that a template or better documentation for this kind of multiplatform scenario would be nice.
- 737maxtw 6y ago> Note that your blogs happily tell me to add a single NuGet package for Windows or Linux, but doesn't bother to tell me how to assemble a project that will work on both. Well, the rest of the owl is fairly simple in this case. System.Runtime.InteropServices.RuntimeInformation.IsOSPlatform() can be used to query the OS type, and you specify which builder option (i.e. if islinux UseSystemd ) to use there. I'd type a proper example but on a cell phone. All of that said, YES you think they would document this better.
- ZeroClickOk 6y ago> Microsoft still lacks a cross-platform desktop UI framework Avalonia to the rescue: https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia
- ocdtrekkie 6y agoAnd if Microsoft wanted to bless Avalonia as such, great. In 2020, .NET shouldn't have like three Windows UI frameworks and zero officially recognized cross-platform ones, particularly if they want .NET Core to take off.
- tester756 6y ago>zero officially recognized cross-platform ones https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/ https://devblogs.microsoft.com/dotnet/introducing-net-multi-... >if they want .NET Core to take off. Personally I don't need crossplatform (desktop) GUI at all. Backend is enough for me.
- nullsense 6y agoSame. No use for desktop GUI apps in SaaS CRUD apps.
- aliswe 6y agoI believe x platform ui is planned for net 6, ie nov 2021
- csharptwdec19 6y ago> Microsoft refuses to port System.Speech for text-to-speech and speech recognition. I think it's more complicated than just 'porting'... Something tells me that System.Speech is a nice wrapper for a very windows specific API. Similar to how Microsoft isn't bringing over WCF Hosting (Because too many parts of it are dependent on Windows itself.) Now, ideally, it would be nice if Microsoft would expose the existing System.Speech source code, so that somebody could begin the efforts of making it into an OSS Project that could eventually become multiplatform.
- ocdtrekkie 6y agoWindows Forms and WPF are also both Windows API wrappers, and they've been brought over for when you are targeting Windows-based platforms. System.Speech is no longer available on Windows in .NET 5, even if you're using Windows Forms or WPF, which are Windows-only frameworks. In theory, if Microsoft was at least holding up compatibility for such things on Windows, I could move my target towards .NET Core/.NET 5, then gradually replace Windows-specific code with cross-platform code. But as per usual, I'm getting the impression it'd be easier to start over than migrate. I agree it'd be really nice if they open sourced the code necessary to look at porting System.Speech, but I imagine it'd be unpleasant as a business decision: It'd erode their ability to bill people for the Azure "replacement".
- CodesInChaos 6y agoBeing windows dependent shouldn't prevent offering System.Speech as a library that targets only windows.
- worble 6y ago.NET Core/Standard already has windows specific API's, and .NET 5 is going to make them safer to use going forward with static analysis[0], so I doubt the Windows specificness is the reason why. 0: https://devblogs.microsoft.com/dotnet/the-future-of-net-standard/#problem-3-net-standard-exposes-platform-specific-apis https://devblogs.microsoft.com/dotnet/the-future-of-net-stan...
- resoluteteeth 6y agoIsn't there a WinRT API that you can use from .net 5?
- ocdtrekkie 6y agoPlausible, though https://docs.microsoft.com/en-us/uwp/api/windows.media.speechsynthesis?view=winrt-19041 https://docs.microsoft.com/en-us/uwp/api/windows.media.speec... looks significantly simplified from https://docs.microsoft.com/en-us/dotnet/api/system.speech.synthesis?view=netframework-4.8 https://docs.microsoft.com/en-us/dotnet/api/system.speech.sy... I'm not confident all the same functionality I've tapped into can be replicated with this.
- pjmlp 6y agoAs WinRT fanboy, I must admit that with Project Reunion, everything UWP related in now in a chaotic state without any clear roadmap on how everything will move forward, just high level ideas. So I wouldn't bet in anything WinRT related for the time being.
- deleted 6y ago[deleted]
- jahewson 6y agoIt’s possible that that System.Speech is using technology and patents licensed to Microsoft for use in Windows but not something they can sub-license.
- winkeltripel 6y agoI consider this the most likely explanation.
- runevault 6y agoThey could treat it like the UI stuff and make it windows only but still in Core 5. But there are other things that aren't getting ported forward for various reasons like WCF.
- fomine3 6y agoI hope MS to release closed sourced windows-only library port even in such situation.