-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[release/5.0] Backport System.Speech to compat pack #46729
Conversation
* Initial sources, with banners * Run the code formatter * Fix hang in XUnit due to failing to complete all AsyncOperation-s * Remove reflection over RegistryKey * Add ref and packaging * Add tests * Add sln * Fix CS1584 * Fix CA1823 * Fix CA1834 * Unnecessary suppressions * Fix SA1028 * Fix CA1507 * Fix CA1810 * Fix CA1825 * Fix CA1825 * Unnecessary suppressions * Fix CA1805 * Fix IDE0004 * Fix IDE0090 * Remove CAS * Remove tabs and dead code * Unnecessary suppressions * Fix SA1212 * Fix SA1121 * Disable SA1129 * Fix SA1206 * Fix SA1518 * Fix SA1617 * Fix SA1001 * Fix CS0618 * Remove unnecessary comments * Remove unnecessary whitespace * Remove low value xml doc comments * Unused usings * dead files * Remove CAS * More junk * Fix obvious original bug * Remove/insert newlines * Remove reference to old design document * Fix spacing * Fix typo name * Fix file casing * Remove dead code * Add to compat pack * Remove AppDomain etc * Fix casing of .NET * Remove low value XML docs * Remove code that relies on compiling assemblies * Fix inadvertently removed padding * Use EDI to preserve stack when rethrowing * Fix misaligned resource ID's to match sperror.h * Skip SpeechRecognitionEngine tests if no installed recognizers * Fix misformatted string bug * Logging for CI error * Fix NRE trying to map phonemes for voice for culture for which we do not have phoneme map * Fix 153 spelling errors in comments using `Visual Studio Spell Checker` * Remove extraneous file * Fix spacing * Fix project reference * Reorder properties in csproj * Change from netcoreapp2.0 to netcoreapp2.1 * Update src/libraries/System.Speech/pkg/System.Speech.pkgproj Co-authored-by: Jose Perez Rodriguez <joperezr@microsoft.com> * Add build error for targeting netcoreapp2.0 * Suppress new error during packaging testing * Update System.Speech.targets * Remove ref comments * Update pkgproj * Remove placeholder Co-authored-by: Jose Perez Rodriguez <joperezr@microsoft.com> Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
@ericstj apparently I didn't, unless it's something not run in CI. |
Running pkg/tests locally i do get a bunch of errors like
|
Oh, silly mistake, I didn't remove the 5.0.2. |
Did you add the package to
Double check the steps here: https://github.com/dotnet/runtime/blob/release/5.0/docs/project/library-servicing.md |
OK added to libraries-packages.proj. Checked library-servicing.md. Also found it didn't work on .NET Framework -- fixed public key to MicrosoftShared to fix that. Also tested net472->ns20, net472->net472, netcoreapp2.1->ns20, netcoreapp2.2->ns20, netcoreapp2.0 (build error), net50->ns2.0. Strangely something is updating packageIndex.json by itself to add lots of "5.0.2" entries. I'll see whether it's the build.. |
Yes, when I do diff --git a/src/libraries/pkg/baseline/packageIndex.json b/src/libraries/pkg/baseline/packageIndex.json
index cff6d7f372d..176476355a1 100644
--- a/src/libraries/pkg/baseline/packageIndex.json
+++ b/src/libraries/pkg/baseline/packageIndex.json
@@ -23,7 +23,8 @@
"Microsoft.Bcl.AsyncInterfaces": {
"StableVersions": [
"1.0.0",
- "5.0.0"
+ "5.0.0",
+ "5.0.2"
],
"BaselineVersion": "5.0.0",
"InboxOn": {},
@@ -137,7 +138,8 @@
"2.0.0",
"2.0.1",
"2.1.0",
- "5.0.0"
+ "5.0.0",
+ "5.0.2"
],
"BaselineVersion": "5.0.0",
"InboxOn": {},
@@ -170,7 +172,8 @@
"3.1.0",
"3.1.1",
"3.1.2",
- "5.0.0"
+ "5.0.0",
+ "5.0.2"
],
"InboxOn": {},
"AssemblyVersionInPackageVersion": {
@@ -199,7 +202,8 @@
"3.1.0",
"3.1.1",
"3.1.2",
- "5.0.0"
+ "5.0.0",
+ "5.0.2"
],
"InboxOn": {},
etc etc is that an issue? |
I've also noticed it happens whenever I try to build the 5.0 branch locally. |
Need to cherry pick #46841 |
Marking no merge until I can cherry pick #46841 shortly |
* Fix PKT * Fix SAPI errors * Disable test as appropriate * enable more tests to fail to get messages * reenable tests * Update src/libraries/System.Speech/tests/SpeechRecognizerTests.cs Co-authored-by: Stephen Toub <stoub@microsoft.com> Co-authored-by: Stephen Toub <stoub@microsoft.com>
@ericstj any other feedback? if you can approve, we can presumably merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I think @Anipik needs to merge this once he does branding and will need to address merge conflicts.
OK thanks! @Anipik I will be happy to validate this when we have product installer that includes it. |
This is being fixed here #46224 |
Backport System.Speech including its entry in the windows compat pack.
Original PR #45941
Customer Impact
The System.Speech assembly on .NET Framework does not work on .NET Core/.NET 5 because it uses private reflection. Many customers rely on generating speech from .NET code to make their apps or scripts accessible to them or their users. They have given us clear and extensive feedback on the impact this has on them, eg in the issue https://github.com/dotnet/wpf/issues/2935. In particular this means they cannot generate speech from Powershell scripts, as recent versions of Powershell depend on .NET Core.
This change backports the port of System.Speech that we have completed in master, so that we can ship it in an updated Windows Compatibility Pack and enable this speech functionality for our customers using .NET 2.1+.
Testing
Risk
The code forms its own library, not previously shipped, so it's highly unlikely that existing .NET Core users would be broken by shipping this library. If there was a break, it would presumably relate to a packaging issue (since it's included into the compatibility pack). We tested key scenarios around consuming the package.