C# Interactive is broken in VS16.8 preview5

[yyjdelete]

Version Used:
VS16.8 preview5

🔗 Also reported at AB#1231577

Steps to Reproduce:

1. Open C# Interactive;
2. Output any non-ascii string like ("测试");
3. #reset core(#reset 32 or #reset 64 works well)

Expected Behavior:

1. non-ascii string should be supported;
2. Switch to core runtime without error;

This only happen on one of my PC, not sure what's the difference between them, and FUSLOGVW.exe show nothing for this
See #48874 (comment) instead if not reproducable in your PC for extra steps;

Actual Behavior:

1. Encoding not work
   

2. Failed to load System.IO.Pipelines, Version=4.0.2.1

> #reset core
Resetting execution engine.
Failed to launch 'c:\program files (x86)\microsoft visual studio\2019\preview\common7\ide\commonextensions\microsoft\managedlanguages\vbcsharp\languageservices\InteractiveHost\Core\InteractiveHost64.exe' process (exit code: 1) with output: 
System.IO.FileNotFoundException: Could not load file or assembly 'System.IO.Pipelines, Version=4.0.2.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. ϵͳ�Ҳ���ָ�����ļ���
File name: 'System.IO.Pipelines, Version=4.0.2.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
   at StreamJsonRpc.JsonMessageFormatter..ctor(Encoding encoding)
   at StreamJsonRpc.JsonMessageFormatter..ctor()
   at Microsoft.CodeAnalysis.Interactive.InteractiveHost.CreateRpc(Stream stream, Object incomingCallTarget)
   at Microsoft.CodeAnalysis.Interactive.InteractiveHost.Service.RunServerAsync(String pipeName, Int32 clientProcessId, Func`2 invokeOnMainThread)
   at Microsoft.CodeAnalysis.Interactive.InteractiveHostEntryPoint.Main(String[] args)

Not sure if the 2 error is related.

[huoyaoyuan]

Note: I can reproduce it when system codepage is 936. Cannot reproduce if it's 65001.
FYI: dotnet/runtime#43295 (comment)

[yyjdelete]

For the FileNotFoundException, ensure dotnet-sdk-5.0.100-rc.2.20479.15 is installed(already bundled in VS16.8 preview5), and any runtime or sdk of dotnet-5.0.100-rc.1 is completed removed.

Double check and make sure Not exists C:\Program Files\dotnet\host\fxr\5.0.0-rc.1.20451.14\hostfxr.dll and C:\Program Files\dotnet\shared\Microsoft.NETCore.App\5.0.0-rc.1.20451.14

For some unknown reason, when install dotnet-sdk-5.0.100-rc.1.20452.10 and then install 5.0.0-rc2.20489.15 (x64) from Visual Studio(update VS), uninstall dotnet-sdk-5.0.100-rc.1.20452.10 will actual remove nothing from disk

Seems System.IO.Pipelines used to be a part of Microsoft.NETCore.App 5.0.0 rc1, but removed in rc2.

[ufcpp]

I have the same problem in CP 932.

[ahdung]

Any news? 16.8.1 still here

[GF-Huang]

#49491

[tmat]

Fixed by #48874.

[GF-Huang]

Issue still exits in VS2019 16.8.3

[huoyaoyuan]

The milestone of fixing PR is 16.9, later than 16.9P2.
It's expected that it's still not fixed in 16.9P2.

[ahdung]

So why not 16.8.x? This is an ugly quality issue.

[CyrusNajmabadi]

So why not 16.8.x?

Because it does not meet the 16.8.x bar. THe fix will be released in 16.9.

[GF-Huang]

https://github.com/dotnet/sdk/issues/15342

[GF-Huang]

Why still no fixed? When to release 16.9???

[GF-Huang]

A bug during a few months no fixing.

[huoyaoyuan]

16.8 released at 2020-11-20. 16.9P3 released at 2020-1-20. This has already been fixed a month a go.
The fix has been released with 16.9P3.

During the new year season, product releasing is slowed down. 16.8 and 16.9 will have at least 2.5 months of interval.

[GF-Huang]

Why not publish a 16.8.5? Now it's like driving a car with square wheels on the highway.

[ahdung]

@GF-Huang 理解你，越新版还越垃圾确实让人想骂，关键解决起来还慢悠悠的。感觉自win7/vs2010时代后，微软不再把质量看得重要。

[huoyaoyuan]

@CyrusNajmabadi I have some words to say here.
This bug should be considered more critical. The timeframe of 16.8.4 can get it fixed. Although 16.8 isn't a service baseline, it is current release and should get fix quickly. I know the fix policy may not be decided by roslyn team, please get the feedback to the right person. Thanks!

[CyrusNajmabadi]

The big is not critical (if you feel otherwise, please provide an explanation demonstrateing why it meets that classification). It was fixed and the fix has gone into the next release as is our standard practice for normal bugs like this.

Barring some sort of disastrous behaviour in 16.8, there is virtually no chance this will be backordered to that release. The bar is simply too high.

[CyrusNajmabadi]

Why not publish a 16.8.

Because it did not meet the 16.8.x bar. So it went into 16.9, like all the other bugs at it's severity/criticality level.

[CyrusNajmabadi]

I know the fix policy may not be decided by roslyn team,

In this case, we decided the policy. This does not meet our bug bar fort balding back porting to the 16.8.x line. Sorry!

[huoyaoyuan]

Because it did not meet the 16.8.x bar.

Is it because 16.8 is not a service baseline?

Generally, I want you to consider encoding issues with higher priority. While "switch to English" is always a workaround, it may not be acceptable for everyone. Changing system codepage to 65001 also has too large impact range.

[CyrusNajmabadi]

Is it because 16.8 is not a service baseline?

Because the backporting bar is much higher. Any sort of backporting needs to have enormous justification as to why it's necessary. For example, data loss or crashes affecting a large segment of users. That's not the case here. While the bug is unfortunate, it can be fixed in an upcoming release using the standard updating process.

Generally, I want you to consider encoding issues with higher priority.

An encoding issue woudl have to be as impactful as full on crashing or data loss in order for this to be considered. I think that's going to be a very challenging argument to make, especially as it has not met that bar for the last 20+ years for the product. The costs to do servicing are extremely high, needing an enormous amount of process and testing involved. Given that there is no crash or data loss, and the fix is already made and available in teh 16.9.x line, i don't see any way this would be approved for servicing.

[CyrusNajmabadi]

Cursing isn't ok here. If you want to report a bug, you can do so by opening another issue. Thanks.

[GF-Huang]

Great, 16.8.5 released. Still not fixed.

[huoyaoyuan]

It won't be fixed in 16.8.x as explained.
When it was fixed, the master branch is 16.9.x. Backport requires more engineering works.

[CyrusNajmabadi]

@GF-Huang Fix was made in: #49721

You can see in that PR that it made it into the 16.9 train:

[GF-Huang]

Look at this good thing, another garbage from microsoft. https://github.com/dotnet/core/issues/6264

[GF-Huang]

Why does Microsoft always make some garbled problems?

[huoyaoyuan]

For compatibility, the default encoding used is not Unicode. Encoding will get wrong if it's forgotten anywhere, especially in legacy C++ codebase.

[GF-Huang]

每次更新修了旧 BUG 却引入新 BUG，#53673， 操他妈的微软。

[CyrusNajmabadi]

@GF-Huang Please abide by the https://dotnetfoundation.org/about/code-of-conduct

[GF-Huang]

I seriously doubt whether the code submitted has been unit tested. No one notices this issue and releases a new version?

[ahdung]

@GF-Huang 哈哈暴躁老哥，建议开个新issue反馈好了，小问题不至于

[GF-Huang]

@GF-Huang 哈哈暴躁老哥，建议开个新issue反馈好了，小问题不至于

这不是小 BUG 大 BUG 的问题，是工作态度问题，每个版本改了旧 BUG 产生新 BUG，现在微软招聘都是走后门的？招的都是什么人？就这水平还这么高薪？

[CyrusNajmabadi]

@GF-Huang please keep things civil.

[huoyaoyuan]

@GF-Huang You are reporting issues that doesn't applies for their ways using VS.

For example, they don't use in language other than English. And your new issue is unstable to reproduce - it doesn't reproduce for me and another person.

[GF-Huang]

Yeah, Chinese is damn, fucking China.

[CyrusNajmabadi]

@GF-Huang Please keep things civil.