Tooling in the .Net World — Actively Lazy
Tooling in the .Net World — Actively Lazy
As a refugee Java developer first washing up on the shores of .Net land, I was pretty surprised at the poor state of the tools and libraries that seemed to be in common use. Read on for more.
Join the DZone community and get the full member experience.Join For Free
As a refugee Java developer first washing up on the shores of .Net land, I was pretty surprised at the poor state of the tools and libraries that seemed to be in common use. I couldn’t believe this shanty town was the state of the art; but with a spring in my step I marched inland. A few years down the road, I can honestly say it really isn’t that great–there are some high points, but there are a lot of low points. I hadn’t realized at the time, but as a Java developer I’d been incredibly spoiled by a vivacious open source community producing loads of great software. In the .net world, there seem to be two ways of solving any problem:
- The Microsoft way
- The other way*
*Note: may not work, probably costs money.
The obvious place to start is the IDE. I’m sorry, but Visual Studio just isn’t good enough. Compared to Eclipse and IntelliJ for day-to-day development Visual Studio is a poor imitation. Worse, until recently, it was expensive as a lone developer. While there were community editions of Visual Studio, these were even more pared down than the unusable professional edition. Frankly, if you can’t run ReSharper, it doesn’t count as an IDE.
I hear there are actually people out there who use Visual Studio without ReSharper. What are these people? Sadists? What do they do? I hope it isn’t writing software. Perhaps this explains the poor state of so much software; with tools this bad–is it any wonder?
But finally, Microsoft have seen the light and recently the free version of Visual Studio supports plugins–which means you can use ReSharper. You still have to pay for it, but with their recent licensing changes I don’t feel quite so bad handing over a few quid a month renting ReSharper before I commit to buying an outright license. Obviously the situation for companies is different–it’s much easier for a company to justify spending the money on Visual Studio licenses and ReSharper licenses.
With ReSharper, Visual Studio is at least closer to Eclipse or IntelliJ. It still falls short, but there is clearly only so much lipstick that JetBrains can put on that particular pig. I do however have great hope for Project Rider, basically IntelliJ for .net.
A few years back another Java refugee and I started trying to write a RESTful, CQRS-style web service in C#. We’d done the same in a previous company on the Java stack and expected our choices to be similarly varied. But, instead of a vast plethora of approaches from basic HTTP listeners to servlet containers to full blown app servers, we narrowed the field down to two choices:
- Microsoft’s WCF
My fellow developer played with WCF and decided he couldn’t make it easily fit the RESTful, CQRS style he had in mind. After playing with ServiceStack, we found it could. But, then begins the long, tortuous process of finding all the things ServiceStack hadn’t quite got right—all the things we didn’t quite agree with. Now, this is not entirely uncommon in any technology selection process. But, we’d already quickly narrowed the field to two. We were now committed to a technology that at every turn was causing us new, unanticipated problems (most annoyingly, problems that other dev teams weren’t having with vanilla WCF services!)
We joked (not really joking) that it would be simpler to write our own service layer on top of the basic HTTP support in .Net. In hindsight, it probably would have been. But really, we’d paid the price for having the temerity to step off the one true Microsoft way.
Worse, what had started as an open source project went paid for during the development of our service–which meant that our brand new web service was immediately legacy as the service layer it was built on was no longer officially supported.
The thing I found most surprising on arrival in .Net land was that people were checking all of their third party binaries into version control like it was the 1990's! Java developers might complain that Maven is nothing more than a DSL for downloading the internet. But you know what, it’s bloody good at downloading the internet. Instead, I had the internet checked in to version control.
However, salvation was at hand with NuGet. Except, NuGet really is a bit crap. NuGet doesn’t so much manage my dependencies as break them—all the damned time. Should we restrict all versions of a library (say log4net) to one version across the solution? Nah, let’s have a few variations. Oh, but NuGet, now I get random runtime errors because of method signature mis-matches. But, it doesn’t make the build fail? Brilliant, thank you, nuget.
So, at my current place we’ve written a pre-build script to check that nuget hasn’t screwed the dependencies up. This pre-build check fails more often than I would like to believe.
So, managing a coherent set of dependencies isn’t the job of the dependency tool, so what does it do? It downloads one file at a time from the internet. Well done. I think wget can do that, too. It’s a damned sight faster than the NuGet power shell console, too. NuGet: it might break your builds, but at least it’s slow.
The Microsoft Way
And then, I find things that blow me away. At my current place we’ve written some add-ins to Excel so that people who live and die by Excel can interact with our software. This is pretty cool: adding buttons, menus, and ribbons into Excel, all integrated to my back-end services.
In my life as a Java developer, I could never even imagine attempting this. The hoops to jump through would have been far too numerous. But, in Visual Studio? Create a new, specific type of solution, hit F5, Excel opens. Set a breakpoint, Excel stops. Oh my God–this is an integrated development environment.
Obviously, our data is all stored in Microsoft SQLServer. This also has brilliant integration with Visual Studio. For example, we experimented with creating a .Net assembly to read some of the binary data we’re storing in the DB. This way we could run efficient queries on complex data types directly in the DB. The dev process for this? Similarly awesome: deploy to the DB and run directly from within Visual Studio. Holy integrated dev cycle, Batman!
When there is a Microsoft way, this is why it is so compelling. Whatever they do will be brilliantly integrated with everything else they do. It might not have the flexibility you want, it might not have all the features you want, but it will be spectacularly well integrated with everything else you’re already using.
Why does it have to be this way? C# is a really awesome language—well designed with a lot of expressive power. But, the open source ecosystem around it is barren. If the Microsoft way doesn’t fit the bill, you are often completely stuck.
I think it comes down to the history of Visual Studio being so expensive. Even as a C# developer by day, I am not spending the thick end of £1,000 to get a matching dev environment at home, so I can play. Even if I had a solid idea of an open source project to start, I’m not going to invest a thousand quid just to see.
But finally, Microsoft seem to be catching on to the open source thing. Free versions of Visual Studio and projects like CoreCLR can only help. But, the Java ecosystem has a decade head start and this ultimately creates a network effect: it’s hard to write good open source software for .Net because there’s so little good open source tooling for .Net.
Published at DZone with permission of David Green , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.