If I'm wrong, show me. What word did I redefine? If I'm so obviously wrong, it should be easy for you to point to how I did it.

So, I'm clever, therefore I'm wrong? Sorry, I don't follow the logic. If I'm wrong, show me. If not, skip the ad hominem.

It's a reference-counting garbage collector that never allows the reference count to exceed one, and requires explicit reference count management from the programmer (free() calls).

A good programmer will know the platform well, and will choose algorithms and code constructs that are appropriate for it. When these are chosen poorly, performance suffers. This is not a situation that is unique to Java, C#, C++, or any other platform.

Yeah, we don't use TFS. I haven't come across any issues with MSBuild as a build system, though.

You're incorrect. Here's an excerpt from an old .csproj (which you should be storing in source control... the .suo and .csproj.user files are the per-user files) which shows a reference to a pre-compiled .dll file:

<Reference Include="SecureBlackbox, [...]">
    <SpecificVersion>False</SpecificVersion>
    <HintPath>C:\Program Files\EldoS\SecureBlackbox.NET\Assemblies\NET_20\SecureBlackbox.dll</HintPath>
</Reference>

Here's an excerpt from a .csproj showing project references (which are preferred):

<ProjectReference Include="..\myproj\myproj.csproj">
    <Project>{F4895F92-1E42-4322-9886-0585A5F06035}</Project>
    <Name>myproj</Name>
</ProjectReference>

Note that using absolute paths is generally a poor idea, as it requires every development machine to be set up exactly the same. Instead, solutions should contain subdirectiores, each containing one project. Project references such as the one above then always work, even when projects participate in multiple solutions (we do this ALL THE TIME). It took some time for us to work out a solid process on this, but we seem to have arrived at a very satisfactory solution. When we do references to pre-compiled DLLs (and we only do this for third-party libraries), there's a subdirectory at the solution level that contains those. That way, when multiple projects reference (for example) SQLite, they all reference the same version of it.

There are CI solutions for TFS, but we don't use TFS, we use Subversion. I imagine that when we move off Subversion it will be on to Git.

Besides, the poster I replied to (which may or may not be you) specifically said they'd be interested in hearing about C# DI frameworks...

Wait, what? There's a million DI frameworks for Java too. I'm not defending anything, except maybe competence and avoiding reliance on "patterns" and "frameworks".

Including his sig...

Please, for the love of all that's holy, do not let Javascript become the "one true language". It's a steaming pile of terrible language design.

Also, Python (the language) is for people who didn't think VB's whitespace-significant syntax went far enough.

Overlapped I/O (or, on Unix, AIO). Learn it. Live it. Dedicating a thread to each open socket is the most brain-dead way to implement a system. It's like bubble sort for sockets. It's simple, it's easy, it's what the noobs do the first time around, but it should never, ever, be used in a system that requires performance.

By the way, C# supports asynchronous I/O using completion ports (on Windows). I don't know for sure if Java does, but I think NIO.2 might.

6 times the RAM required for a GC to function properly? Over what? Just how, exactly, is malloc()/free() not a garbage collector? It serves the same purpose, it simply requires more handholding to do so.

We do CI with C#, using TeamCity. I don't know what these "conflicts" are that you see all the time, but perhaps you're the problem?

There's a million of them. Take your pick. Or, you could just write maintainable/testable code without relying on some jackass' DI "framework".