Skip to content
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.

Sign up for GitHub

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

Jump to bottom

The test is failing on 2 platforms with this change #1913

Closed
hamarb123 opened this issue Jan 19, 2020 · 5 comments
Closed

The test is failing on 2 platforms with this change #1913

hamarb123 opened this issue Jan 19, 2020 · 5 comments
Labels
untriaged New issue has not been triaged by the area owner

Comments

@hamarb123
Copy link
Contributor

hamarb123 commented Jan 19, 2020 •
edited
Loading

Please read PR #1853 and issue #1740 first, thanks.

It seems like the test is failing on 2 platforms: Windows_NT netfx x86 Release, and Windows_NT x64.
I imagine the reasoning behind the netfx failure is because it must still have the old code, but can anyone tell me what the other one is, its error messages don't make sense to me.
Also, what should I do to fix the netfx platform?

Originally posted by @hamarb123 in #1853 (comment)

https://github.com/dotnet/runtime/pull/1853/checks?check_run_id=395012296
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Jan 19, 2020
@Gnbrkm41
Copy link
Contributor

The EventPipe failures appear to be the same as #1892.

Unless the fix can be made in .NET Framework as well, I believe that you should conditionally compile with #if NETFRAMEWORK to use different test data for .NET Framework.

@hamarb123
Copy link
Contributor Author

@Gnbrkm41, do you know where the .NET Framework equivalent of this is? Is it this, should I PR there too?

@Gnbrkm41
Copy link
Contributor

.NET Framework sources are read-only, so it would be the folks at MS that would make the fix.

@hamarb123
Copy link
Contributor Author

@Gnbrkm41, so I should just make it conditional and then they can change it later for netfx if they want?

@Gnbrkm41
Copy link
Contributor

That's my understanding of it, yes.

@hamarb123 hamarb123 mentioned this issue Jan 20, 2020
Merged
stephentoub pushed a commit that referenced this issue Jan 23, 2020
@hamarb123 @stephentoub
U+0085 not recognised as a newline character in CSharpCodeGenerator.cs (
4c79f98 
#1740) (#1853)

* Fix for issue #1740

U+0085 not recognised as a newline character in CSharpCodeGenerator.cs

Fix $1740

* Fix for issue #1740

U+0085 not recognised as a newline character in CSharpCodeGenerator.cs

* Fix for issue #1740

U+0085 not recognised as a newline character in CSharpCodeGenerator.cs
This change fixes a previous test that incorrectly causes the character to be forced out of being in unicode format.

* Stop the changes from #1740 on the .Net Framework as per #1913

Read #1913 for why, view PR #1853 and #1740 also.
@ghost ghost locked as resolved and limited conversation to collaborators Dec 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
untriaged New issue has not been triaged by the area owner
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@hamarb123 @Gnbrkm41 @Dotnet-GitSync-Bot