4

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.

2

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.

  • 1
    I am not convinced what you describe is a viable approach for C# projects. First, as I have also described in my answer, the project files mentioned by the OP are not really IDE settings. But even without taking into account this structural difference, already the introduction of the linked article conflicts with how C# works: "Typically source should be considered as any files that are explicitly modified by the developer. Anything that is or can be consistently generated from the source files should be considered as output of the build ... – O. R. Mapper Oct 22 '17 at 13:31
  • 1
    ... process." - based upon this, C# project files are absolutely source files. C# project files indicate which binaries to build, which source files to include into which of these binaries, which files to include as resources with what IDs, which local DLLs in which versions to reference, which DLLs to pull from NuGet and reference in the appropriate version, which target frameworks (!) to build for, etc. Keeping all this information up to date manually in a CMakeLists.txt file seems like a major (not to mention error-prone) effort to me, on top of adding an additional 3rd party ... – O. R. Mapper Oct 22 '17 at 13:31
  • ... dependency (CMake) instead of using the built-in default tools of the development and target platform (MSBuild). – O. R. Mapper Oct 22 '17 at 13:31
  • 1
    @O.R.Mapper you’re not convinced that it’s not the right approach for C# because it’s not. The upvoters here have obviously not worked with the language. – RubberDuck Dec 16 '17 at 15:39
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.

  • It's good to know Visual Studio does not create the described problem as much any more. However, other IDEs may still cause some problems in this respect (if only by extensively reordering the contents of the project file, thereby making the result somewhat unsuitable for VCS). – O. R. Mapper Dec 16 '17 at 23:44
0

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.

  • You have this mistaken conception that the project formats are incompatible. In the past, this was true. However project formats have been forward compatible since 2013. – RubberDuck Dec 16 '17 at 15:40
  • Also, considering that VS has provided free community licenses since 2013, there’s no reason not to just use the latest version. Anyone who wants to contribute is free to download & install VS Community. Bonus: Multiple versions can be installed side by side. – RubberDuck Dec 16 '17 at 15:43
  • @RubberDuck: "project formats have been forward compatible since 2013" - that still leaves the issue that a project saved with a later version may be (inadvertently?) changed to a more recent format, doesn't it? "there’s no reason not to just use the latest version" - as far as I know, custom IDE addins that may be required in the development process of some projects are not automatically compatible across versions. Furthermore, some 3rd party IDEs used by parts or all of the core project team might not be compatible with the latest VS. ... – O. R. Mapper Dec 16 '17 at 16:00
  • 1) No. VS doesn’t do that post 2013. 2) IDE plug ins should never be required by a development process. OSS or otherwise... how would your CI server have access to those? 3) Not sure what you’re talking about. VS is quite capable of running side by side installs. At one company, I had 5 different versions installed at one point. Never an issue. – RubberDuck Dec 16 '17 at 16:06
  • ... "Multiple versions can be installed side by side." - that may be true in theory, but given that at this point, each VS version insists on requiring dozens of GB on C drive, while almost all current systems are sold with tiny SSDs as a C drive, that's a bit problematic in practice. – O. R. Mapper Dec 16 '17 at 16:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.