5 ms·

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 asy

by com2kid 12y ago

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 12y ago
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.
- Gmo 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        You could use YAML, which is also kinda hip, but still allows comments...
  - zaphar 12y ago
    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 12y ago
      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.
duncanawoods 12y ago
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 12y ago
  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 12y ago
  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?
yaur 12y ago
.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.
deleted 12y ago
[deleted]
sebcat 12y ago
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 12y ago
  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 12y ago
    > 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.
jonathanoliver 12y ago
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.
taternuts 12y ago
> 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.

by com2kid 12y ago

zaphar 12y ago

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.

Gmo 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      You could use YAML, which is also kinda hip, but still allows comments...
- zaphar 12y ago
  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 12y ago
    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.

duncanawoods 12y ago

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 12y ago
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 12y ago
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?

yaur 12y ago

.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.

deleted 12y ago

[deleted]

sebcat 12y ago

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 12y ago
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 12y ago
  > 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.

jonathanoliver 12y ago

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.

taternuts 12y ago

> 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.