Edit Unix-related code with Visual Studio on Windows

[ezsilmar]

Hi, I'm trying to set up a dev environment for runtime libraries, specifically System.Net.Sockets, using Visual Studio Professional (2022, 17.11.0 Preview 5.0) on Windows.

After some struggles I was able to make the build and most of the unit tests work inside the IDE. My blocker now is that Visual Studio doesn't show some of .Unix files, in particular ones coming from /src/libraries/Common like SocketProtocolSupportPal.Unix.cs. It, however, shows .Unix files coming from /src/libraries/System.Net.Sockets like SocketAsyncEventArgs.Unix.cs.

Maybe you'd have an idea what I miss in the setup? Do you use some other workflow to develop unix-specific code at Microsoft?

[ezsilmar]

Just realized I could simply open the second VS instance targeting the .sln in /src/libraries/Common... Though I'm still curios why it shows the .Windows.cs link but not .Unix.cs

Btw Rider does show both of these files. However it has other issues like completely ignoring xUnit attributes from microsoft extensions and its code analysis doesn't like NET9.

[huoyaoyuan]

VS only shows: files under current directory, and files get included in current platform. It always loads the Windows platform only. Opening the csproj file, you can see conditions like Condition="'$(TargetPlatformIdentifier)' == 'windows'".

In some old VS versions, it can't show Windows code from Common either, because the target platform condition wasn't applied to shproj.

My blocker now is that Visual Studio doesn't show some of .Unix files

Why is it blocking you? It should be purely interop code.

Maybe you'd have an idea what I miss in the setup? Do you use some other workflow to develop unix-specific code at Microsoft?

The build configuration is very complex and very, very specialized for dotnet/runtime. Project-based IDE aren't well-prepared for the specialization. We do use folder-based editor (VSCode) when touching interop code.

[huoyaoyuan]

If you switch your target to some unix, and navigate to the symbol, you will open the file that not showing in solution explorer.
But this doesn't work for CoreLib. CoreLib isn't using the same OS targeting mechanism because it's special.

[ezsilmar]

Thanks for the answer @huoyaoyuan!

Why is it blocking you?

I'm sorry for this exaggeration, I guess I'm just too used to good IDE experience and was frustrated at the moment😅 Working on performance of dotnet apps in enterprise setting I often need to understand what a piece of code, which I've never seen before, is doing technically: how the data and execution flows, what system calls, sync primitives, data structures are used on the hot path, what was the "design intent" behind the code, etc. IDE helps tremendously here especially features like disassembly navigation, symbols and files discovery, find usages, etc.

When I dive into dotnet runtime I feel like I lose a big part of this UX. It's not that bad for libraries, it is significant for native part (I worked on eventpipes and createdump), and build scripts in /eng are pure magic. However, I always assumed that I just didn't put enough time into my setup and/or there are some internal or undocumented bits that make this experience inside Microsoft much better. Hence the original question, to not miss this if it exists.

Project-based IDE aren't well-prepared for the specialization.
We do use folder-based editor (VSCode) when touching interop code.

That's very interesting! It could be nice to have a documentation about project structure, suggested workflows, and IDE expectations for different parts of the runtime. Something like "note you can only run these tests from the CLI, don't even try to make them work in IDE", or "coreclr is very specific and VS won't work well with it".

[huoyaoyuan]

That's very interesting! It could be nice to have a documentation about project structure, suggested workflows, and IDE expectations for different parts of the runtime. Something like "note you can only run these tests from the CLI, don't even try to make them work in IDE", or "coreclr is very specific and VS won't work well with it".

In fact, Visual Studio support is evolving quickly. For example, recently #104561 just fixes building CoreLib inside Visual Studio.
We do intend to achieve good experience inside Visual Studio, but sometimes it's indeed complex and may involve changing VS itself.

Different team members are also using different toolchains, someones are even vim hackers. There's really no single standard.

It's not that bad for libraries, it is significant for native part (I worked on eventpipes and createdump), and build scripts in /eng are pure magic.

I recommend to take a try with the Open Folder experience. You can open src/coreclr in VS, and many things will be set up automatically. I also have some ideas about improving the doc, based on my experiences during several years.

The native building logic is still very complex for me. I rely on the root script to set things in place before debugging. It is indeed a specialized task to assemble managed and native stuffs together.