How does one structure a C# OSS project to be accessible to wide ranging group of developers?

Question

I'm looking at figuring out how to deal with C# projects in open source sanely.

Visual Studio is both backwards and forwards incompatible, so everybody in the project has to use the same version, if somebody uses a newer version, it breaks support in the project file for everybody else on older versions. The project file generally has to be included in the repository under (a)GPL, because it almost always includes build info, settings, etc., so it counts as a build script or configuration file.

Are there other viable IDEs that can manage building and installer bundling and the whole nine yards?

Is there a way to make Visual Studio less of a pain and more compatible with older/newer versions of Visual Studio as well as other operating systems?

Is there is a way to decouple the build chain from Visual Studio to make it easier for developers in other toolkits or older versions of Visual Studio to develop and build and even package test installers?

In general, I'm looking to reduce how dependent a few C# projects I have management over are on certain development workflows. In my mind, an open source project should be accessible to anybody able to write code. How they write it, what program they write it in, should not be relevant, but C# and the Microsoft way seems to be running counter to this.

Answer 1

One approach is NOT to commit any IDE settings and setting files, and use for instance with Cmake to generate these and setup a Ci for building with Cmake (to keep things in check and avoid drift of your Cmake config).

See also this article:

CMake produces Visual Studio solutions seamlessly. This post will map CMake commands to the Visual Studio IDE with an example which makes learning much easier. It is primarily intended for a C++ developer using Visual Studio. Most references here is based on Visual Studio 2010 but will apply equally well to other versions.

Answer 2

Visual Studio is both backwards and forwards incompatible, so everybody in the project has to use the same version, if somebody uses a newer version, it breaks support in the project file for everybody else on older versions.

This hasn’t been true since 2015. Since then the project format has been forward compatible. You can open a 2013 csproj in 2015 (but not a 2015 in 2013).

The only important matter is that you must set the language version for the project. When left to default, it will take the latest version of the lang for the editor you’re currently working in. This means that if the maintainers are using 2013 for dev, contributors using 2015 can accidentally introduce language features from newer versions that won’t compile in older versions. It’s best to be explicit about which C# Lang version the project uses.

As for other editors, there is JetBrain’s Rider IDE. It supports the same csproj format as VS. In reality though, people can use what ever editor they like. They just have to download the appropriate version of the MSBuild Tools and compile from the command line.

Answer 3

The only useful approach for this I could find is to agree on a specific version for the "core team" of developers, and require anyone else to stick to that version.

Note that this does not imply that everyone has to use the same VS version, but that the project files committed to the repo need to be in a specific file format version.

That is, a developer who uses a different VS version can create copies of the project files in their local working copy, convert these to the file format version compatible with their IDE and work with them. Before committing their changes, they only have to copy their changes to the project file copies to the project files in the common format version. Unless they have significantly restructured projects, that should be rather easy to do manually in the Xml sources of the project files, as it is usually just a matter of adding a few file references.

Still, I would like to comment on a part of your premise:

Is there is a way to decouple the build chain from Visual Studio to make it easier for devs in other toolkits or older versions of Visual Studio to dev and build and even package test installers?

In a way, this is already done. In general, the notion of a "Visual Studio project format" is a mistaken one - VS does not have any proprietary project format for C# projects (in the sense that it's reserved and internal to VS). Visual Studio uses MSBuild files for projects, with MSBuild being the default build system for .NET. And this brings us back to your question: The "build chain" is already decoupled from VS, in that the tool chain is a separate thing known as "MS Build Tools", which can be downloaded independently of Visual Studio.