There are a few exceptions to this rule (think EF Code-First), but that's a drop in the ocean.
Don't get me wrong, this type of thing drove me from the MS ecosystem a while ago now but they do move largely in the right direction, just too slowly for my tastes.
A lot of things in VS are wrappers around very well-documented CLI tools, e.g., svcutil, and I don't begrudge these tools for doing a lot of heavy lifting.
My biggest gripe are all kinds of wizards, most notably "New Project" ones. They do generate a lot of cruft I have to clean up later and pull way too many dependencies.
Maybe you are just now noticing, but MS dev tools have always had wizard clicky things. For example, see the original Visual Basics from the 90s.
My main gripe with abundance of today's "visual programming" is that we have memory-managed languages with immense expressive power and ability to write all kinds of DSLs, yet what Microsoft does is it provides crippled XML-backed designers along with half-baked frameworks and class libraries.
I actually like MFC, but it never really got past the "good for a first cut" phase, IMO. Fortunately, I've never had to deal with .NET, and besides a little MFC, most of my work is on Linux these days.
http://www.youtube.com/watch?v=hkDD03yeLnU things like this never help
>Microsoft developer tools are becoming more and more oriented towards "wizard-and-designer-clickety-clickery" type development.
MS have always done a good job of catering to a wide range of developer personas.
Still 100x better than digging through 100 pages of abstruse Java docs about AbstractProxyBeanDAOFactoryProxy.GenerateAbstractProxyBeanDAOFactoryAccessor though.
Closer to this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... than drag and drop, clickety-click.
The term "wizard" came about because of the AppWizard and ClassWizard features in Visual C++.
Clickety-clickety has been a goal of Visual Studio since before it was Visual Studio.