Good question. You asked it, so now I don't have to!

The comments are good.

So, yes, for my startup, I'm using the Microsoft 'stack'. But for C#, I'm not using it! Haven't touched it! Instead I'm using Visual Basic .NET and .NET, ADO.NET, ASP.NET, Windows Server, etc.

For 'training' people, my guess is that 'basic' Visual Basic .NET will prove to be super easy for nearly any reasonably talented, interested hire to learn.

Why? For nearly everything I'm doing, nearly all of the the syntax and semantics of Visual Basic (the current .NET version) couldn't be easier to read and type.

I also like the Visual Basic compiler, just as shipped with the .NET Framework (version 4.0). The Visual Basic compiler is right there as file VBC.EXE, and to run it just use a command line or some scripting language (I am using ObjectRexx) to type the command line. The command line syntax is short and easy to understand. The compiler is fast and generates remarkably small EXE files. The error messages are from good to quite nice. So far I've found no bugs at all. I'm thrilled.

My view is that the syntax of C# is more difficult, and so far I see no reason to struggle with it. So, for my startup, so far it's just Visual Basic and .NET.

For typing in software, I just use my favorite text editor KEdit with a lot of macros. And I make heavy use of just the ordinary desktop 'windowing': So, when typing, typically I have about 15 windows open, 'tiled' with the upper left corners running from upper right to lower left (can always see at least the top or left side of each window and can rearrange the Z-order without moving any windows). So, I have windows with pieces of my design, software, testing, documentation, etc. all readily available. It's nice.

I'm also thrilled with how ASP.NET works when I just type in Web page software with KEdit. So, when a browser displays a page under development, if there are Visual Basic errors then get a nice page in the browser making clear what the errors are. NICE. When the compiler errors are gone, then at the bottom of the Web page is a NICE description of all the work ASP.NET did with a 'control tree', various ID values, some sizes in bytes, some timings in milliseconds, etc. NICE.

When finally understand from 5000 feet up basically what ASP.NET is doing, then it's fairly simple and clear and okay.

Why I am staying with Microsoft:

(1) What I Knew. I got started on that path to Microsoft and stayed on it. So I did a lot with OS/2, and when I changed to Windows it was, of course, similar.

(2) Documentation. I am finding that my code is heavily just some 'glue' to call code from Microsoft, especially their .NET. So, I do more reading documentation than writing code. So, I care a lot about the quality of the documentation.

The Microsoft .NET documentation is enormous. I have about 2400 Web pages of Microsoft documentation on my computer, abstracted, and indexed, and I put as comments in my code the file system tree names of relevant documentation and with one keystroke KEdit will display the Web page. Nice.

But that's a LOT of documentation. Writing such documentation is EXPENSIVE. In simple terms, the quality from Microsoft is high. More deeply, often the writing quality of the real 'content' needs to be improved. I'm afraid that, without the big bucks of Microsoft, alternative documentation would be worse.

(3) Support. If my startup is successful, then I will want a lot of technical support. I'll be willing and able to pay for the support. I am hoping that going with Microsoft I will be able to get some good support.

So far I've gotten some surprisingly good support for free from various experts at Microsoft via various Microsoft fora. Of course, to get a good response, tend to need to have done some good homework and actually ask a good question! The free support is so good that I am looking forward to some nice help when I'm able to pay.

For Unix flavors, I'd be afraid on each of these three points. Afraid? Yes. Well informed on Unix? No!