[zaphar]

I recently had to spend a lot of time with csproj files. They look and behave rather a lot like Ant/Maven. This is not a point in their favor.

Ant/Maven was loved and then subsequently hated by a lot of java developers. XML is an extremely verbose syntax to have to deal with.

But the real killer is one of lockin. Yes you can use msbuild to do things with them but the syntax is really designed not for a developer to read/edit them but for an IDE to serialize state to. Just because there is a command line runner doesn't mean the format is developer friendly. As long as you stay in VS you won't really notice. As soon as you leave though its no longer comfortable. csproj files are one thing I wish .Net had taken a different path from java in.

[MaulingMonkey]

> I recently had to spend a lot of time with csproj files. They look and behave rather a lot like Ant/Maven. This is not a point in their favor.

Perhaps not, but it's glorious compared to, say, .xcodeproj.

Combined with .props files (same format as .csproj), managing .vcxproj s (also the same format as .csproj), to manage a build matrix of ~5 platforms x ~7 build configurations x ~20 projects via a few hundred .props files hasn't been that bad.

> XML is an extremely verbose syntax to have to deal with.

Easy to parse, though, if you want to automate keeping it in sync with other formats.

> As long as you stay in VS you won't really notice. As soon as you leave though its no longer comfortable.

The longer I use them the more often I drop down to simply firing up a text editor to edit my .props files. Configuring through the IDE is a great way to add a whole bunch of state which you may or may not have meant to set, and can get quite unwieldy... whereas I can see everything at a glance that a single .props file configures by simply opening it up.

At this point I have our .vcxproj file lists almost entirely decoupled from the .props build settings. Fewer merges, and each .props file is quite easy to digest at a glance.

[ygra]

I've redone the build system at work completely half a year ago, as some .vcxproj files have gone through a few upgrade processes since VC++ 6 projects. Needless to say there was a lot of cruft in there. You can do a lot of nice things by offloading configuration into property sheets and including them as needed and this more or less cut down the project files to a list of dependencies and a list of files. It also doesn't help to have add-ins that insert custom build rules for every file where each change to some configuration property changes about 50 points in the project file.

I think it comes down to: Auto-generated build files are always horrible to read; write them yourself once you know what you're doing. It's probably a bit worse with MSBuild projects as Visual Studio uses them as its native project format, whereas no one else tries that with Makefiles (for good reason, I guess).

[Gmo]

FYI, next version will have a JSON-based project file (whether this is better or not is left as an exercise to the reader).

[yaur]

JSON vs. XML is largely irrelevant IMO. What is needed is something with as little extra crap as possible so that it is possible for a developer and/or diff tool figure out what is going on with the file.

[MichaelGG]

The only real relevant part is that this means no comments. So if you DO decide to do something neat in your build files, you can't note anything about it. Or easily remove pieces for testing.

But it's JSON which is so hip instead of XML which is so bloated. /s

[dkuntz2]

You could use YAML, which is also kinda hip, but still allows comments...

[zaphar]

Not really. When your build files are designed to be serialized IDE state no matter what the format you have limited your build system to what your IDE creators decided to express. This is not always what you need and that mismatch will only get more and more out of sync the longer your project lasts.

[ygra]

The current state is that the project files are MSBuild projects and Visual Studio itself supports only a subset of functionality (but leaves advanced things more or less alone). So the build system itself is quite a bit more capable of just what Visual Studio supports within the files and in many cases you can mix that quite freely.

[com2kid]

MSBuild files are actually far more powerful than what you just see from within Visual Studio! There is a bunch of cool stuff you can do with them (such as conditionals) that you do not have access to from within the VS IDE.

The .NET MicroFramework actually is an example of a project that uses MSBuild files for all sorts of crazy stuff, like supporting tons of different compilers (including GCC!).

Funny enough, it actually is possible to make VS support other compilers as well! (I've seen it done, honest!)

Editing them is no more painful than editing any other form of XML. (Err, not sure which way that is arguing!)