open-dotnet/.github

.github's Issues

.NET download site only lists compatibility with Visual Studio

https://dotnet.microsoft.com/download/dotnet only shows the compatibility of each SDK with Visual Studio. For a lot of people it would probably be helpful to know what the compatibility of those SDKs with other IDEs (OmniSharp, Rider) is.

Disable telemetry/tracking

overview

The Microsoft distribution of the .NET platform contains telemetry/tracking within the SDK and within the Visual Studio Code tooling.

https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry

related issues

• dotnet/vscode-csharp#4069
• #20

additional material

• https://dotnet.microsoft.com/platform/telemetry

discussions

There are lots of limits as to what data can be collected about the actual build as even command line parameters can give away information or secrets or PII - tannergooding

Should now we actully maintain a branch of dotnet ?

The New dotnet's OS support is keep dropping and the core team is removing the old OS code from their repositories. and that cause many probem for the company who use dotnet to build their software.
The OS support list is not grow anymore , it's always add 1 OS and drop 2 more maybe. and that is not happened in other language/platform.

Why

overview

The why is rapidly developing as a result of informed discussions with people in the community and Microsoft employees. Please come join the discord channel (#48). A formal blog post and mission statement is to come but to in the spirit of starting discussions here are some napkin thoughts...

1. Ownership. Fundamentally reshapes how the community thinks about their programming languages, stewardship and ownership. Right now people bitch at Microsoft. Microsoft has transformed dramatically (not enough) but the way the community thinks has not.

2. Trust. Microsoft has squandered such amazing goodwill. The original PR was "inadvertently" rushed and locked before anyone could comment on it. Deleting the entire source tree isn't something you accidentally do! Hot Reload is back, but these events doesn't instill confidence in that it won't happen again. From the outside the it appears as if Scott Hunter had to step in to be the fall guy for someone else's decision which involved removing GA+LTS features from the SDK that had Go Live approval.

3. Unity. Reunify key .NET tooling #13 and improve tooling #20

4. Growth. Introduces .NET to a demographic of developers who avoid .NET because Microsoft. If .NET wasn't associated specifically and only with Microsoft it may have wider adoption.

5. Innovation. Remove friction for community to conduct experiments (such as #23 and #25) without approval of Microsoft and try out ideas without restraint from other programming language ecosystems.

6. Personal Development. Build a community of toolchain wonks and engage engineers from Microsoft in the old school CH9 format from time-to-time for mentoring: “hey, The community wants to build dotnet from source. Can you walk us through the codebase and explain what the community needs to know?”

7. A gift to the next person or company that comes along. Removing all friction for those that come after us.

discussions

Collective ownership and the ability to change / improve anything in the .NET tooling and developer experience ala to Own Your Own Future when it comes to your toolchain is a central northstar. - ani

wat it do - ani

What's the purpose of forking the dotnet repositories? Is it to create a fork of the ecosystem, or to push back into the mainline repos? There's no issue with Microsoft not accepting contributions when they're offered, so I don't understand how forking will help? - Yair Halberstadt

Love the premise and energy though. The effort feels analogous to bootstrapping an OpenJDK for .NET. Very exciting 🙂 - Mpdreamz

I'd like to understand the reasoning for forking everything myself. I've seen various complaints, particularly around the debugger. But that doesn't to me explain why the world needs to be forked rather than just driving projects around the relevant "missing" bits, as it were. [For example] It would probably be more helpful if you could draw a parallel between what it [dune] provides vs what MSBuild does not- tannergooding

Hi @🏴☠ Geoff, big energy here! I can see lot's of words describing big things. I'd love to see an issue describing how you're going to maintain .NET itself. Or I guess, this fork of .NET. What resources are there, etc. - patrickk

Generation of consumable artifacts

overview

Once the build infrastructure is in place (#33) produce artifacts that can be installed.

related

• https://github.com/dotnet/installer/tree/main/src/SourceBuild
• https://github.com/dotnet/source-build
• https://github.com/dotnet/arcade

related issues

• #33

The .NET platform independent of Visual Studio

discussions

I think both .net as a platform and both C# and F# as languages only stand to benefit from making .net independent from Visual Studio and providing good open-source (not just free) console-first tooling available to the community. skleanthous

People will use VS if it's a good product. VS 2022 is great! It addresses real issues people have had for years! Granted, it took stuff going sidewise to get there, but still! Build a great IDE, and people will come. Hobbling dotnet doesn't help, it only pisses everyone off. Moves like removing Hot Reload not only hurt CLI or VSCode, but VS and VS Mac as well. It makes it harder for DevDiv to collaborate from the foundation on to the topic of the stack. - @drasticactions

recommended reading

• https://dusted.codes/can-we-trust-microsoft-with-open-source
• https://www.theverge.com/2021/10/22/22740701/microsoft-dotnet-hot-reload-removal-decision-open-source
• http://pastebin.com/RF6015kv

Build infrastructure

overview

The .NET project is a very large project and requires considerable amounts of compute to be able to run integration tests. Through https://fosshost.org/ (I'll ask em shortly) the project could potentially have access to large amounts of AArch64, M1 ARM and X86 compute infrastructure at no cost.

Rust/Golang has a better 1st class experience in VSCode than C#

overview

If we look outside of the .NET ecosystem you will see that other programming languages that are not developed by Microsoft have better support for Microsoft Visual Studio Code than C# which is developed by Microsoft.

next steps

Comment here if you feel the same but please be constructive:

• cite specific concrete comparisons/observations
• share insights and personal experiences from other ecosystems
• does lack polish of C# in VSCode inhibit your desire to use the .NET platform?

Create GitHub issues for the problems if they don't exist upstream at https://github.com/OmniSharp/omnisharp-vscode and link them back in here.

additional materials

• https://github.com/OmniSharp/omnisharp-vscode

Roadmap

overview

We are in the early days of forming a community and consensus of what should (could) be worked on. Please come join the discussions at https://aka.ms/dotnet-discord (in #opendotnet). Collective ownership and the ability to change / improve anything in the .NET tooling and developer experience ala to Own Your Own Future when it comes to your toolchain is a potential central northstar.

See also #47

The pinned items on top of the GitHub repository are a suggested starting position and if you desire to help out then starting to obtaining domain knowledge needed to achieve tasks such as #45 helps so much.

discussions

From Ani:

I think that the central Truism to focus around is, "What is getting in the way of writing production-scale .NET apps using solely open-source tools". Like, having a forked build of every .NET package seems like it is a V2 Thing
So toward that end, I would say your list is, in order of priority:

1. Build an open source debugger for dotnet.
2. Improve omnisharp/C# in vscode experience
   ....
3. Maybe replace NuGet?

tbh I'd put that last one low on my list, because like, what you really want out of this initiative is the ability to change / improve anything about your tooling and developer experience - to Own Your Own Future when it comes to your toolchain, and NuGet from a developer perspective is really just like a fancy S3 bucket. Yeah, it's owned by someone else but like who cares

From Yair Halberstadt

Can I make a suggestion?

At the moment I feel like you're doing a lot of things and are very vague about your plans for all of them. At the moment you have a lot of community interest and attention, but that going to wane soon. You're very excited about this project, and that's great but if you want to keep it going for the long term you have to focus all this passion and attention to something concrete.

So I would advise picking one thing, and doing it really well. If that works you can branch out from there. So for example pick one of these, and focus almost entirely on it:

1. Have a community built version of the dotnet sdk with key differentiator (e.g. telemitry disabled), and automatically in sync with core dotnet.
2. Improve omnisharp/C# in vscode experience.
3. Build an open source debugger for dotnet.
4. Experiments with replacing MSBuild
5. Experiments with replacing Nuget

But pick one and stick to it, and for now don't even mention any of the others - they're just a distraction. Or simply act as a Community advocacy organization for dotnet, where you don't build anything at all, but act as whistleblowers for things you feel MS is doing wrong, and provide assistance to people trying to change things in dotnet, or simply help drive forward community contributers.

Fork synchronisation

overview

Unfortunately, GitHub does not have a great way of automatically keeping forks in sync. Through external tooling such as https://github.com/google/copybara and https://github.com/marketplace/actions/fork-sync it would be possible to track upstream development at github.com/dotnet/*@main and continuously integrate changes.

other issues

• #33

open-dotnet should not only rely on Github, it is very dangerous.

The current open-dot.net point to github orgnization page, it is works for now .
But think for more deeply.
Github is a Microsoft sub company, it can do anything to protect Microsoft benefit.
Just like to take down open-dotnet .
So i suggest, do not rely on Github. we may take open-dotnet as a real open source foundation project.
Like join into Apache Foundation or CNCF foundation.

Like groovy lang, it is now Apache project, still growing well, more or less.

dotnet can be good , if we not only rely on microsoft.

Unify the .NET platform debugger story

overview

What use is an open-source programming language that can only be debugged with proprietary software? This is not a problem for languages that .NET competes against in mindshare (Golang/Rust). Why did dnSpy, MonoDevelop, Linqpad, JetBrains & Samsung have to reinvent the wheel? It's 2021 and the .NET platform is fractured at a foundational level.

https://github.com/OmniSharp/omnisharp-vscode/wiki/Microsoft-.NET-Core-Debugger-licensing-and-Microsoft-Visual-Studio-Code

options

• The now archived+retired project dnSpy has a powerful .NET debugger and is one of the most advanced as it supports the impressive stuff , like tuple element names and async stepping. Unfortunately it is released under GPLv3 license whereas the rest of the platform is released under MIT. Maybe the author would consider relicensing this component?
• Samsung has a debugger that provides GDB/MI and VSCode Debug Adapterprotocol and allows to debug .NET apps under .NET Core runtime. It is released under MIT.
• Jetbrains could do the community a solid and open-source their debugger.
• Microsoft could do the community a solid and open-source their debugger.
• MonoDevelop has a .NET debugger (which needs work)

discussions

More people should be pissed off about the debugger situation - @directhex

relevant issues

• dotnet/core#505

additional material

• https://docs.microsoft.com/en-us/dotnet/core/diagnostics/sos-debugging-extension

Instantly make and keep fixes to .NET dependencies from an IDE (everything, including the runtime itself)

overview

Why can't consumers of open-source libraries instantly from their tooling make and keep fixes to open-source dependencies. Being able to patch is a vital band-aid for those of us living on the bleeding edge or anyone who consumes open-source software (ie the entire .NET ecosystem)

In the JavaScript ecosystem there exists patch-package:

https://www.npmjs.com/package/patch-package

# fix a bug in one of your dependencies
vim node_modules/some-package/brokenFile.js

# run patch-package to create a .patch file
npx patch-package some-package

# commit the patch file to share the fix with your team
git add patches/some-package+3.14.15.patch
git commit -m "fix brokenFile.js in some-package"

Patches created by patch-package are automatically and gracefully applied when you use npm or yarn. No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working. No more harassing open-source maintainers to merge pull-requests or support legacy scenarios. By providing the correct tooling consumers of open-source software are empowered to make changes and are in more control of their software supply chain.

In the nix ecosystem this is achieved using Overlays which can pull from git, a tarball, local filesystem, etc.

self: super:
{
  sl = super.sl.overrideAttrs (old: {
    src = super.fetchFromGitHub {
      owner = "open-dotnet";
      repo = "roslyn";
      rev = "923e7d7ebc5c1f009755bdeb789ac25658ccce03";
      # If you don't know the hash, the first time, set:
      # sha256 = "0000000000000000000000000000000000000000000000000000";
      # then nix will fail the build with such an error message:
      # hash mismatch in fixed-output derivation '/nix/store/m1ga09c0z1a6n7rj8ky3s31dpgalsn0n-source':
      # wanted: sha256:0000000000000000000000000000000000000000000000000000
      # got:    sha256:173gxk0ymiw94glyjzjizp8bv8g72gwkjhacigd1an09jshdrjb4
      sha256 = "173gxk0ymiw94glyjzjizp8bv8g72gwkjhacigd1an09jshdrjb4";
    };
  });
}

additional reading

• https://www.npmjs.com/package/patch-package
• https://nixos.wiki/wiki/Overlays
• https://cachix.org
• https://nixbuild.net
• https://docs.microsoft.com/en-us/dotnet/core/rid-catalog

considerations

• .NET RIDs and topics of cross-platform compilation

related issues

• Fody/PropertyChanged#270

Driving a .NET build with something other than MSBuild

overview

Assume that Visual Studio in it's current formation is not constraining you in innovation and the community could draw a line on the topic of backcompat (ie optimise for cloud native/azure scenarios)

Topics of:

• source binary substitution
• hermetic, reproducible, correct, incremental and caching
• observations of cool things other programming languages are doing and conversations about bringing them to .NET
• backcompat considerations
• tooling considerations

options

• bazel
• cmake+ninja
• domino/buildxl
• something new (w/inspiration from https://opam.ocaml.org/packages/dune/)

additional material

• https://cachix.org
• https://nixbuild.net
• https://nixos.wiki/wiki/Overlays
• https://opam.ocaml.org/packages/dune/

related issues

• #25

discussions

As @jaredpar mentions, one key-part is the integration in VS, and so I would prefer that we fix msbuild on several issues that are fixable - xoofx

I know that it's a bad idea (because it would be a huge amount of work, and doesn't provide much incremental value) but I can't stop thinking about driving a .NET build with Bazel - agocke

sure would be nice to have a build system that you can trust. I still compulsively git clean with MSBuild because I know left over files can wreak havoc. With BuildXL no need to clean, it will be correct by construction. Hermetic, reproducible, correct, incremental, caching. - KirillOsenkov

We generate C# client libraries with Bazel, but I haven't looked into the infrastructure much to be honest. (It was all done before I had to start messing with the scripts.) - jonskeet

For @IonideProject we support a plugin based project metadata model, and there's a community member working on parsing bazel files specifically to enable them to use VS Code. Pretty inspiring stuff - chethusk

What we need is a Build/Project Server Protocol, similar to LSP + a MSBuild server (out-of-process, full state of projects, live sync with disk changes...), so that VS could interact with or actually any other build/prj systems - xoof

I would add: I like what SwiftPM has done for dependencies and targets. But it also shows that a replacement is measured in years, even with best intentions and staffing. - migueldeicaza

Disagree. Project generation is a failed approach. It’s not “can we do it” it’s “it breaks the basically rythym of VS”. Can’t round trip with generation. - @jaredpar

You have no idea how long I have DREAMED of just including C# code inside larger C/C++ CMake projects. Imagine how much easier it would be to build native components and the managed code wrappers to go with it. We would have probably got first-class C# support in FreeRDP by now - awakecoding

There's also notably a lot more to a build system than just what the CLI experience offers. Things like what they provide out of the box and the integration with IDEs and project systems is very important as well. Out of all of the ones I've used, MSBuild despite its downsides/flaws, is one of the better ones out there. Partially because it is so well-integrated into all the IDEs/project systems that support it (not just MSFT ones) and because it provides so many things that medium to large projects need out of the box. 800 csproj projects exist. 3-6000 projects exist. 80 csprojs is a medium sized project. Roslyn alone is 200+ you can have small projects that are improperly managed as much as big projects. Medium sized projects typically need things like flowing and copying dependencies, managing where artifacts are published, etc These are all things that MSBuild gives you for "free" (because it has the infrastructure and manages it all for you) but other systems are notably missing or have fairly poor experiences around themIt's also very easy in MSBuild to customize and modify this and to integrate it with other build steps, tasks, targets, etc Notably, if you've ever tried to work with CMake; many of these things only recently became possible or are still quite difficult to do/manage. It also has problems where you move folders, update tooling, or do just about anything else and the entire world has to be rebuilt and its not just automatic, etc - tannergooding and 333fred.

It would probably be more helpful if you could draw a parallel between what [new things] provide vs what MSBuild does not - tannergooding

Community

social media

• https://twitter.com/opendotnet

maintainer and community chatroom

• #opendotnet SIG in https://aka.ms/dotnet-discord

GitHub organisation structure

For organization sake it might be best to run this under 2 organizations e.g

• open-dotnet
  • open-dotnet-community

So that community gets access to discussions etcetera but secure coding and deployment practices can be adhered on the open-dotnet repository producing binaries.

Originally posted by @Mpdreamz in #34 (comment)

Hello!

❤️

Joining .NET Foundation

Any plans to join the .NET Foundation https://dotnetfoundation.org/member/become-a-member

Consider giving ownership to someone who wants to take this forward

I believe there is sufficient room to do a lot of good here. Is there a way to transfer ownership of this organisation so this does not die.

Contributor Agreement

overview

Implement CLA Assistant as a GitHub Actions robot for all forks and repositories and store signatures in a centralised repository. By using the same CLA as used by the .NET foundation ideas/work can be incorporated back upstream.

see also

• https://github.com/open-dotnet/cla
• https://github.com/ghuntley/ghuntley/blob/trunk/.github/workflows/cla.yml

related issues

• #7

Rust does not have 'only one debugger'

Hi, just wanted to point out that the organization profile README makes a statement that I feel is incorrect. It says "Did you know Rust only has one debugger?". This is not true.

Depending on how you look at things, Rust either has no official debugger, or many. You can debug Rust with GDB, LLDB, WinDBG and I believe even using the debugger in Visual Studio (whatever that thing is actually called) might also work if you compile Rust using an MSVC target. (in which case it should emit PDB debug info) I don't use Windows or Visual Studio so I can't really confirm that.

So rather than having its own debugger infrastructure, Rust just uses existing technology for native code like DWARF or PDB in the case of MSVC. The focus has been on getting Rust support into other projects like GDB and LLDB. Whenever you set up Rust using rustup, you get rust-gdb and rust-lldb, which are versions of both GDB and LLDB that have additional python scripts shipped with them for pretty-printing certain types of symbols (e.g. Rust enums).