Deploying everything can be one-click. VS even has git integration now.

The old IIS is like you describe. But, the latest IIS is fast and easy.

In all honesty this is what I find from most unknowledgeable Microsoft bashers. They tried out the MS development stack with Classic ASP, Visual Basic 6 and SourceSafe 15 years ago. Then in their head they're contrasting that to the latest RoR tools with github. Many are not even aware of ASP.NET MVC and how different it is from ASP.NET.

Now, this isn't to say there aren't knowledgeable Microsoft bashers but this is what I find from many of them that aren't knowledgeable.

I can only say after managing a project with 400 controllers that it doesn't scale up to complex UI or even medium sized projects well. Also we're reaching 5 minute edit, compile, run cycles (on E5 Xeons!). Also production debugging (which is inevitable one day) is a PITA on CLR based projects.

It has become the opposite of all promises. It's like wading through tar.

To be honest after over a decade of .Net experience and over a decade of Win32/COM etc before that, I'm tired of it all.

I wrote my first Objective C+Cocoa application last week (an RPN calculator) and it's where I'd rather be. It was fun and frustration free. I tried to do exactly the same with WPF/C# a few weeks ago and it was horrible.

You complain about singletons, then prefer a language where the use of [sharedInstance] is extremely common. Objective-C is singleton hell. Both in third party code, and core libaries.

C# is vastly nicer than objective-c, and I'm a iOS developer. I'd rather use C# or Scala with a IoC container to handle the lifetime of objects, rather than using singletons.

The difference is that your Objective-C/iOS application doesn't consist of thousands of threads which require synchronised access to these objects. It's a pretty static thing with an event loop. Possible a couple of background worker threads.

For a desktop application or even mobile application it's fine but for a massively scalable back-end enterprise system it's a pain in the butt.

Singletons are not for managing lifetime as well. They are a container for an object -- nothing else. Lifetime should be managed separately i.e using a container/service locator or something. Everything I've seen Cocoa-wise is pretty decoupled so far. There are some crimes but only inexperience seems to require them.

And since you attribute those problems to .NET, your solution is a small project (which incidentally uses another technology).

Not dismissing your argument as a whole, but you have to admit you made at least one giant logical fallacy right there.

The problems with the project scaling are primarily down to the infrastructure: MSBuild and the C# compiler are damn slow as is the whole rip up and replace assembly system in .Net. When you have something at the bottom of a dependency chain that is quite deep (with any enterprisey project), you have to recompile all consumers and therefore everything that depends on them and so forth. A single line change means you end up compiling the entire system on top of it. All 200Mb of DLLs need building again. That's a long time. Not only that, when it comes to testing and runtime dev (i.e. using the web front end), reloading assemblies and performing JIT is really expensive and time consuming.

Every time you do something, mount everest is destroyed and recompiled twice: one to IL and once to native. This is expensive and seriously screws productivity. It doesn't scale development-wise. Simple as. This is not specific to my current project - I've consulted at various companies since 2002 and that's exactly what it has ended up for everyone, every time.

Going back to LLVM/XCode. I'm not particularly experienced with the specifics of the abstraction that Apple provide, but I've spent 20 years building monstrous bits of C on top of Unix/Linux with GCC and Sun compiler suite. That's what we're still dealing with but we have LLVM which slings code out much faster than anything we've had before. We also have incremental build support (individual .o files per source file), faster linking and a runtime system that doesn't require recompilation.

I'm not saying it'll realistically turn into anything better at the end of the day but one some points:

1. The Xcode tooling is like lightning, even with a 200,000 line C project I imported from a previous project.

2. The startup time is 487ms compared to the same thing in C# of 2.2s to first output and 10.5s to it actually doing something.

Think I've explained myself better now. Sorry for the initial confusion.

This just isn't true at all. Even in COM days it wasn't true. With COM, if you preserved binary compatibility you didn't need to re-compile a client if you compiled a new version of a DLL it calls. In .NET it's even more forgiving. Sure, if you change something major like delete a bunch of properties that are used in the client then you have to recompile the client. But in many cases you don't.

Beyond this, if your architecture has 200 DLLs, it might be completely appropriate but it is a suspect architecture. I manage a .NET project that trades $4 billion of fixed income instruments per day, interfaces to three trading platforms, interfaces to 13 custodial systems and 7 different data providers. It uses about 25 DLLs and is quite manageable.

Finally, how often do you recompile a DLL that is "quite deep" in the dependency chain? Generally, such low-level DLLs should do very little. For example, maybe it's appropriate to change them if you change from Oracle to SQL Server but how often would that happen?

In .Net, any contracts that break between layers in your dependency chain force a rebuild of all layers above it. This is not unusual in .Net projects as the components are bound at runtime.

There are not 200 DLLs - there are 200Mb of DLLs. Total count is 122 DLLs.

This particular beast handles integrations with over 100 systems using vastly different non COTS integration methods, has over 2500 tables, 950 domain objects, 400 controllers, 45 databases, 200 API endpoints, async background processing and piles of MSMQ queues. Data volume is terabytes. It's a behemoth and it's been around for 33 years in various forms.

If you, as we do, change architectural components and APIs, dependencies are broken. The main case for this is when we version our API. We have up to 3 API versions in production. When someone introduces a new API version, the oldest is deprecated and all the historic versions are ported to the newest internal API. This is where it becomes dependency hell.

However it's a fine way to avoid technical debt!

What are the features of Resharper that make you say VS isn't complete without it?

Next big thing is navigation. Go to type, go to symbol and go to file are super quick and means I never go to the source tree to navigate the solution.

Symbol search is incredibly useful, that was a revelation when somebody told me about it. But Visual Studio has had that since at least 2010, I think maybe 2008. Resharper's is a bit more complete, but I think the VS built-in one is a bit faster. The VS native implementation is Edit -> Navigate To, the default key combo is ctrl-comma, but I think Resharper takes that combo for its own purposes.

I think it's because I find the VS interface incredibly cluttered anyway, and Resharper just makes it worse. The right click menus are already 10 miles long filled with useless clutter and when it starts mucking around with the already edging towards overwhelming intellisense pop-ups it just annoyed me one too many time.

After 2 weeks of trialling it then only thing I was really using was the "go to implementation..." but I've long since given up on the ridiculousness of making everything mockable anyway so it's only occasionally useful.

The worst thing about VS is how slow it can be sometimes, even on incredibly powerful machines. In the end it's a glorified text editor and everything should be secondary to that.

There's nothing more annoying than pressing ctrl-f (find) and then have it pause for 1/2 a second because it's trying to parse a massive html tree for intellisense you don't even need because you're just trying to delete a single node you know the name of.

The text editor is only a tiny part of an IDE, the bits that are added are quite important. Integrated debugging (with edit+continue while debugging), integrated version control interface, integrated build system, integrated profiler and much more makes it so much more productive than having to e.g. do debugging with recompile/restart turnaround times.

That's the main reason to use an IDE, in my mind, along with the ability to display the call sites of a function.

> integrated version control interface,

Never noticed any advantage compared to a shell with git or git-svn, personally.

> integrated build system

Depends what you mean by that. What's precious is the ability to detect errors before doing a build or testing anything. "Integrated build systems" in general I find often fall flat on their face when something outside of the IDE touches the files.

It's also the thing that's most important to flow, to producing, not navigating or testing.

That it can pause and stutter when you're just trying to do a simple edit is pretty silly.

I love VS and it's one of the things I always miss whenever using something else, but there's a lot of annoyances and a lot of sub-par features and some you should never use features.

I notice you said "integrated version control interface", if you're talking about TFS, it's terrible. Stop using it. The interface is terrible, all generic tables that you can't tell apart. It's a massive effort to see file changes. And worse than all of that, the actual version control system is shockingly bad, even compared to SVN, let alone Git. You're a madman to be using TFS, it's so bad.

I haven't lived with it long enough to find out if it's as easy to break as Eclipse when you install the wrong combination of plugins, though. Oddly enough, its vim emulator plugin is much better than what I found for Eclipse, which I find quite ironic.

One problem I'm running into at the moment is I'm trying to port a vendor's reference SOAP Service over to Mono/Linux and their provided secret sauce DLL is blowing up when calling their objects' constructors. I'm yet to pin it on Linux or Mono. Here's hoping the vendor is Mono friendly and willing to debug it. If not we're going to have one oddball Windows server in a sea of Ubuntu EC2 instances.

Ironically, we have some large-ish C# code-bases that run on everything but Windows.

The memory model is, IMHO, where Microsoft is pushing the limits of the existing C# language.

What has Microsoft changed in the .NET memory model that makes you think they're pushing the limits?

From what I can tell, the .NET memory model is one of the things that has changed the least. The languages have changed a lot faster than the memory model.

.NET seems to be well worth the cost of running Windows, but the consequent platform and vendor lock-in is still a concern for us.

Maybe you should contribute a better one. ;)

Getting a web app built on .NET/MVC4/IIS running on mono isn't a trivial endeavor, and the open source implementations rightfully tend to lag behind the closed implementations.

[1]: https://wiki.gnome.org/Projects/Vala/ValaForCSharpProgrammer...

While developing with MS technologies, you must accompany any code, tests and documentation with a "My License" folder with "licensing.cs" files to calculate, the implied licensing costs of each piece of code you develop along with all required MS components down to the metal. Finally, you must make sure the relevant "My License/licXX.cs" gets updated with changing licensing policies.

Next to your developers, designers you must staff an MS certified licensing specialist, or for larger projects a License team with a director level position to analyze, plan, design, test, negotiate and pay licensing costs.