[com2kid]

Some really good criticisms, but I do wonder how long ago this developer left .NET.

.NET is now heavily async based. WPF may have started it years ago, but async has been a keyword in the language for quite awhile! (I haven't used a proper lock in ages. Event queues are where it is at! Or pick your favorite paradigm, heck the framework comes with thread pools built in that it'll juggle for you!)

In regards to .csproj and .sln files, they serve the same purpose as make files. .csproj files (and .*proj files in general) are incredibly powerful, you do not even need to use Visual Studio with them. They interact with MSBuild to do some insanely extensible things.

That said, merging .sln files is horrible, the bloody file format has an element that is a count of project element nodes in that same solution file, if two people try to check in a new project to a solution at the same time, the project count field gets corrupted and life gets seriously un-fun. :( The SLN file has a number of other issues as well, ugh! But .csproj files are pretty nifty, no worse than any other makefile replacement.

As for Visual Studio, I run it just fine on my Ultrabook! Huge project, it works well. Not perfect, but good enough. VS2013 fixed some very blatent threading bugs that VS2012 had in its UI (oops!) and things are generally snappier now.

Oh and VS support for git has been around for awhile. :) TFS also has really good git support, it has been improving with every version and it is now at a really good place.

All in all though, some very good points of criticism! No programming language ecosystem is perfect! (Disclaimer: I m mostly use .NET for client apps, I haven't done server .NET stuff since 2.0!)

[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!)

[duncanawoods]

Agreed - I see VS2013 running very well in a VM even.

For me, VS is the strongest pull of the .Net platform after C# the language. It doesn't take me long in another IDE/language to sigh and wish for something to work as well as VS.

However, I am one of the few that would never use resharper. There are no refactoring features in the world that make a good trade for laggy typing.

[jeroen]

I run Win7 + VS2013 development environments in VMWare Fusion on my 17" MBP (4 core 2.4GHz i7, 16GB RAM and SSD). Running two at the same time is just a bit too slow for comfort, but one runs perfectly fine.

A good SSD is a big improvement, especially when compiling.

[MartinCron]

Hmm... Unless your computer is very old or poorly configured, there's no reason for ReSharper to cause laggy typing. Maybe you should give it another shot?

[sebcat]

I'm from a Linux/FreeBSD background. I'm currently doing work on a Windows platform.

> Oh and VS support for git has been around for awhile. :) TFS also has really good git support, it has been improving with every version and it is now at a really good place.

Git in visual studio does not work well. I'm using the built-in stuff in VS2013. If you want to do anything except the standard stuff (add, commit, pull, push without fancy options), it's horrible. There's no UI support for anything, and no CLI. I find myself resorting to msysgit a lot, and it has it's own problems. And the other devs laugh at me for it ("You're running bash, on Windows? Huehuehue"), only to experience the same problems as I do.

The .NET "async" model is not good for I/O bound problems, which is what I work on. Want I/O multiplexing? Well, you can have IOCP, but most people end up with one thread per connection anyway because I/O multiplexing is not an option in most parts of the library eco-system. Want to make an HTTP request? Have it done in a worker thread, because your HTTP library is blocking. I know things are changing, and I know there's other ways to go about this, but the author's claim that the concurrency model offered by .NET is inferior to others is a very valid one. I've done work in Java previously and it's basically the same problem. I've also experienced problems with lock contention, corner-case deadlocks, &c. Now these are problems related to the codebase, not the language itself, but threads as a concurrency primitive tends to cause programmers to make mistakes more often than other concurrency models in my experience.

And no, make files and .sln files are just not the same. They're both a part of the build system, but that's about it. I'm not even going to argue a point here, because it just fills me with rage to think about that god-forsaken fragile, XML setup that is .sln.

[MichaelGG]

Perhaps you know less about the build system than you think. SLN is NOT XML, it's some strange line-based format, that essentially lists projects. From there the whateverproj files are XML and valid MSBuild files.

Git works fine in VS. Use Git Extensions.

[sebcat]

> Git works fine in VS. Use Git Extensions. I don't know, but I think Git Extensions is superseded by the built-in Git support in VS2013. And it's very limiting if you want to do anything except the basic add, commit, pull, push stuff.

[MichaelGG]

Superseded? How so? It's a third party plugin, just keep using it. The VS native stuff from MS is very immature but "ok" for simple TFS-like workflows.

[SideburnsOfDoom]

> Git in visual studio does not work well. I'm using the built-in stuff in VS2013. ... I find myself resorting to msysgit a lot

You can use the git cli if you like, you can use TortoiseGit or GitExtensions. They all interoperate really well. That's the strong point of a popular open-source system. I never saw the reason why the source control system has to be integrated into the IDE before it's usable. They all operate on files and file systems, not on compilers. Why is it hard to do the commit in a different window to the coding?

> want to make an HTTP request? Have it done in a worker thread, because your HTTP library is blocking.

I'm having great results with .Net 4.5 and "var response = await httpClient.GetAsync(url)" The HttpClient and async/await came out in August last year. Is that kind of code what you mean when you say "Have it done in a worker thread, because your HTTP library is blocking" or are you using a prior version?

[com2kid]

> And no, make files and .sln files are just not the same. They're both a part of the build system, but that's about it. I'm not even going to argue a point here, because it just fills me with rage to think about that god-forsaken fragile, XML setup that is .sln.

SLN files are not really part of the MSBuild system at all, nor are they XML. They seem to exist solely for the IDE's benefit!

Indeed I've used plenty of projects that use MSBuild but no SLN files.

[sebcat]

My mistake, I was confusing .vbproj/.csproj-files with .sln files.

[jonathanoliver]

I wrote that article at the end of January 2014. Technically I'm still using .NET because I've got a mountain of code that still runs on Windows. Bit by bit, I'm killing it off in favor of other languages.

[yaur]

.NET has always had a relatively easy asynchronous model. The async/await keywords made it a whole lot easier but BeginXXX/EndXXX were not that bad, although if you are truly IO bound burning a few extra CPU cycles is not that important.

[taternuts]

> As for Visual Studio, I run it just fine on my Ultrabook! Huge project, it works well. Not perfect, but good enough. VS2013 fixed some very blatent threading bugs that VS2012 had in its UI (oops!) and things are generally snappier now.

VS and VS+ReSharper are two different beasts. ReSharper can bring a VS instance to a crawl even on a powerful machine if you don't tweak it for better performance.