[7.0.100-rc.2.22417.1] private field name changed from virtualListSize to _virtualListSize for ListView

.NET version

7.0.100-rc.2.22417.1

Did it work in .NET Framework?

Yes

Did it work in any of the earlier releases of .NET Core or .NET 5+?

Verify Scenarios: 1). Windows10 RS5 x64+dotnet-sdk-7.0.100-rc.2.22417.1: Fail 2). Windows10 RS5 x64+dotnet-sdk-7.0.100-rc.1.22408.5: Fail 3). Windows10 RS5 x64+dotnet-sdk-6.0.303-win-x64: Pass

Issue description

Application Name: mRemoteNG OS: Windows 10 RS5 CPU: X64 .NET Build Number: dotnet-sdk-7.0.100-rc.2.22417.1

App checking at : https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1600006/

Github Link: GitHub - mRemoteNG/mRemoteNG: mRemoteNG is the next generation of mRemote, open source, tabbed, multi-protocol, remote connections manager.

ObjectListView Source Code : Downloads — ObjectListView 2.9.1 documentation (sourceforge.net)

We are onboarding mRemoteNG, when we run it against .net7, connections list on the left side does not load. After debugging, we found the root cause is related to a NuGet package that app uses : NuGet Gallery | ObjectListView 2.7.1.5

In ObjectListView package, it gets the field info with this code :

var virtualListSizeFieldInfo = typeof(ListView).GetField("virtualListSize", BindingFlags.NonPublic | BindingFlags.Instance);

Above code returns null in .net7 because field name changed to _virtualListSize, it works like this :

var virtualListSizeFieldInfo = typeof(ListView).GetField("_virtualListSize", BindingFlags.NonPublic | BindingFlags.Instance);

Steps to reproduce

The machine only has 7.0 installed. And DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX=2 is set.

1. Launch application from “mRemoteNG.exe”.
2. Click “Ask me again later”.
3. Maximize the window.
4. Click “Password protect”.

Expected Result: Click “Password protect” successfully.

Actual Result: Password protect button doesn’t show because Connection list doesn’t load.

@dotnet-actwx-bot @dotnet/compat

[PriyaPurkayastha]

Thanks @RussKie and @merriemcgaw. I had a chat with @marklio last evening about this issue.

1. We were wondering if this change was related to naming conventions/formatting or some sort of code refactoring. Ideally, we would want changes to fields for formatting to be done early on in the release (which is the case for this change given that it was made in Preview 3) as compared to late in the release during RC timeframe simply due to the risk introduced.
2. Mark also found out that ObjectListView package seems to be quite old and last updated 6yrs ago. Additionally, it doesn’t target a Core-compatible TFM. Package download numbers are 22.5K total downloads, so it is not hugely popular. We haven’t found any other apps in the compat lab broken by this change since Preview 3. Given the above reasons, we should be OK closing this issue as Won’t Fix.

@Junjun-zhao please let Mark and me offline why we think this app is important for us to onboard in the lab.

We are seeing a class of issues like these where customers take a dependency on private reflection (even if it is forbidden) and changes increasingly have more impact as our product matures. For the next release, I will try to put together some principles related to this along with trying to find out if teams can proactively look for private reflection usage and assess impact.

[merriemcgaw]

Thanks @PriyaPurkayastha, @marklio - I agree that as our product matures and more and more people are migrating their applications we should absolutely be mindful of these sorts of changes. I will make sure that we don’t make more changes like this in the RC timeframes. But this one we’ll do as Won’t Fix.