The case for or against .NET (the beast) [closed]

The case for or against .NET (the beast) [closed] - c#

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The company I work for uses C++ Builder 6. We've been developing native code since conception. Our flagship product is written completely in native code.
Enters the .NET Framework with its bells and whistles. I fall, hook, line and sinker. I convince management that .NET should absolutely be our new framework for all new software development and that we should start migrating our existing codeline ASAP. With all the benefits it doesn't take much convincing. They accept my proposal as usual.
At this point I start developing my very first .NET application. It's all going as planned. The project is only one component of our product. And so I get to the point of creating an installer for this new component. As a company we pride ourselves in making things for the user as easy as possible. Even Microsoft with thousands of developers don't create installers like we do. When you install Microsoft CRM for instance, you will only get a list of failures and prerequisites that needs installing before you can continue. Not us. Never. If you need something, we will install it for you.
This makes our installations feel so easy. .NET Framework not installed? No problem! We'll do it for you. Need SQL Native client? Fine!
The issue is this, now that one single component of our solution is written in .NET, it complicates the installation process incredibly. Before I can even get to installing our product, I need to do the following:
Detect whether the prerequisite is installed
Install it if it isn't
Verify that it was installed successfully
Next prerequisite
To install .NET Framework, I need the Windows Installer 4.5 first. But there are different versions for the different OSes, so I add OS detection and launch the correct EXE. Oh, .NET framework is already packaged with 2k8 and the installer exe cannot run on it, you have to run OCSetup.exe with parameters to install it.
And so it carries on. Then SQL Express 2005 needs to be installed. The dependencies increase once again.
I argue with management that even Microsoft don't make it this easy for the user. Their response is that there is no reason for us to not be better than them in this way. I can't argue with that except that I feel that there are very good reasons they've gone with their approach.
Suddenly, our installer is massive. All the prerequisites for .NET, not even talking about 64 bit support which has a whole separate range of EXEs to install. So now it gets to the point where we want users to be able to download a "quick" evaluation. What a joke. You need to download 500MB to get a 30MB application running. The majority of the installation package is prerequisites.
Management feels that we have too many dependencies/prerequisites. I understand completely. They suggest we move away from the .NET framework, back into native land where things were still "easy" in terms of installation. This is where the one part of me wants to stand up for .NET explaining the benefits in the big picture, the improved development experience, easier maintenance and overall code quality. The other part of me agrees with them wholeheartedly! Developing in .NET simply requires you to install too many other prerequisites which complicates the installation.
Yes, some of the .NET advocates will claim that everything should be installed on a patched and updated operating system. This is true, but not all customers have this, and simply saying "I'm sorry, update first" just won't cut it. Remember, we pride ourselves in the overall user experience.
We are now considering writing native code again and I know we're losing in terms of development speed and all the goodies of .NET. But we are gaining in this area, be it small if you look at the big picture or not. As we have native code development skills and .NET is actually new ground for us, it even makes sense to move back.
My question is this: what is your company's view on this issue if it even is an issue at all and what will the business case look like that I propose to management assuming I want to continue migrating all our products to .NET?

This is the reason to why many companies have switched to web installers that download all prerequisites on the fly from your homepage. Since in most of the cases, the OS have 99% of what's needed (if they have been updated using Windows Update).
I would not put everything for x64 and x32 in the same installer. Create two installers, one for each architecture.

Paint.NET wraps the installation of prerequisites up nicely without bundling the .NET framework with it by default. The end result is an unmanaged shim executable that checks for the .NET framework and some other stuff and holds your hand as it gets installed; all downloaded on the fly as they are needed. They then run a WinForms application that pInvokes into MSI to further wrap the installation up in cotton-wool.
Worth a Google.
Also likely is the fact that a lot of client machines will already have some version of the .NET Framework installed as it is part of Microsoft Update - making it more easily consumable in the business world.
Paint.NET blog posts about installing:
http://blog.getpaint.net/2008/08/24/the-paintnet-install-experience-part-1-version-3xx/
http://blog.getpaint.net/2008/08/25/the-paintnet-install-experience-part-2-version-40/ (thanks Rup!)
Reading into the story a little more, presumably management had to go through the pain of deployment with the C++ application at least once, but it is now done and classed as "easy". Put some time against the deployment and present this to management and, hiding the pain, show them how easy it is to install :)

Let's go back to why you wanted to switch from native code to .NET code in the first place: it's more efficient for you, as a programmer. Many things are easier in .NET than they are in C++ (or whatever native language you're using), and so you can develop your applications much more quickly.
Then, how does the time you spend developing the application compare to the time you spend developing the installer? Even if you have to spend a couple weeks nailing down the installer (specifically the framework setup portion), that should be more or less the only time you have to go through that.
For all future applications, you would be using an almost identical installer; you would still do all the prerequisite checks, but instead of copying files to C:\Foo, you're copying some different files to C:\bar.
In my opinion, this is a simple question of economics. Yes, it's more expensive to develop a (good/complete) installer for a .NET application, but if that's the step you need to take once to dramatically improve your development time, it's a no-brainer. Your return on investment would probably be in the order of weeks.

I feel I need to respond to this statement:
Yes, some of the .NET advocates will claim that everything should be installed on a patched and updated operating system. This is true, but not all customers have this, and simply saying "I'm sorry, update first" just won't cut it. Remember, we pride ourselves in the overall user experience.
If your user is insistent on shooting themselves in the foot by operating a system that the vendor has informed them is no longer fit for purpose, then there's nothing much you can do to 'help' them. I'm aware that this makes me look like something of an obnoxious activist, but I look at it in the same way that a manual tradesman might - it is up to the customer to ensure that the environment in which they want me to work is sound and appropriate for the product. If it isn't, I'll accept further renumeration to do that job as well, but it might still cause them extra work because they haven't had the foresight to make sure they understood what they were buying.
I believe software customers have been allowed to remain ignorant for long enough, and that they should now be required to understand what it is they are buying. Operating a corporate IT environment that isn't properly patched is the same as continuing to run a vehicle that has been subject to a manufacturer's recall - a Windows service pack is equivalent to a recall in many respects. You're not legally obliged to submit to a recall, but it's in your best interest as a business and you may be held responsible for damages caused by your shirking of responsibility.

Any Visual C++ app has prerequisites / external dependencies as well: runtime 6.0, 2003, 2005, 2008 or 2010? no SP, SP1 or SP2? x86 or x64? What version of Windows Installer does 2005 SP2 require? And what 2008 SP1? And so on, so on.
Thus that's far-fetched arguments! Like Joel's grumblings about .NET. And look what's now!

I don't see how there are significantly more pre-requisites for .net over C++ Builder. You complain about SQL Server, but you ignore the fact that you have to install some database with C++ builder as well. You complain about x64 vs x32, but .NET doesn't require any change.. the same exe runs on both (and compiles itself optimally for either environment). The same can't be said about C++ Builder. You may need seperate versions of SQL server, but again that would apply to C++ builder (unless you just install x32 on everything).
Yes, there are the new installer version issues, but those components aren't very big. And you really can get the installers to download and install only the aprts that are necessary.
C++ builder is probably easier for you because you've already invested the time in creating a good installer. You need to do the same for .NET, and then you can choose based on real issues.. and not this.
By the way, the reason Microsoft chooses to do things the way they do is that many users, especially corporate users, do not appreciate having things installed for them automatically (perhaps because they have an application that depends on a specific version of a library, and you come along and wipe it out with a new version that they can't easily uninstall).
What you view as "making it easier" for less knowledgable people is actually making things MUCH harder for those that know what they're doing.
Here's a good example. One thing I absolutely despise is when I install an app that needs SQL Server, and it installs its own instance of SQL Server, even though I may already have several instances already that it could use. Easy for the novice, a pain in the ass for me to try and get your app to work with my single instance.

If your app runs under Mono, then shipping your app with the Mono runtime might be less painful.

Related

How and which tool should I use for Source Control? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
A little bit of Background first:
I have been using Team Foundation Server for about few months and know pretty much how to use it. I have been using it for my project on Codeplex. They required TFS and it was in my Visual Studio Installations, so basically I never knew what all it took to get it to work as it seamlessly worked inside Visual Studio and I just had to do Check In and Check Out stuff...
But now I wanted to see what other Alternatives were available and first installed Mercurial command line (which I never used), then searched for a GUI alternative and installed TortoiseHg and followed instruction from documentation on its Website. Then it said to install a 3 way Diff tool... I searched for it and then Found TortoiseSVN; I thought it must be some plugin or something so I searched SO for questions related to my situation when I stumbled upon this SO Question and was pretty mesmerized by so many tools for different work.
Now:
Can somebody explain what all tools are for source control. Do I have to install a different tool for every different task. Isn't there any single package for all of them. And basically what are the tasks we perform in Source Controlling. I only know Check In, Check Out and checking difference from Codeplex Website. What else should I know.
Does every website like Git, BitBucket, etc use different Tortoise (xxx) for their source control.
Are Source Control and Version Control different terms
Please help..

This is a huge topic and will be impossible to provide a single all-encompassing answer. Nonetheless here are a few thoughts, assuming you are looking for more of a Software Configuration Management solution rather than a simple Revision Control System type approach:
Release Management:
In addition to concurrency control (check-in, check-out, etc.) your SCM can/should also provide history, tagging, branching, and other release management type capabilities. That is, it should always provide a single source of truth as to what source files when into which release, service packs, etc. In order to do this, your build environment needs to be well integrated into your SCM.
WIP Management:
A good SCM system will allow to you compare your work-in-progress to the latest checked in revision. It should also let you revert your WIP, shelve it temporarily, or merge another's changes on a file by file basis.
Documentation & Training
Do not underestimate how important it is to use a tool that can give you a ton of help, books, documentation, community support, and even paid support if needed. Also selecting a "popular" tool can mean that some new developers have one less thing to learn.
Continuous Integration:
Automated builds are a must for any serious organization and you should pick an SCM that can be access by your build systems (e.g. Hudson, CruiseControl, Bamboo, etc.)
Security
The SCM system should have a built in authentication system and also be able to use outside authentication providers as many organizations change over time. In addition, it should be able to support developers working outside the firewall, preferrably over http.
IDE and Build Tool Integration
To make all this stuff easier your SCM must be able to be seamlessly linked into your development system and any command line tools you use. This fact is made easier by the fact that almost all non-Microsoft IDE's support all SCM tools.
Source Browsing
Most SCM tools that I've seen have a number of very high quality, third party browsers such as Fisheye. So I discount this as a differentiating factor.
So which tool to use?
If your organization is fairly well contained within your company then pick Subversion. It is very popular, integrates with every IDE/OS/Build tool, works with ToroiseSVN, supports all platforms, supports multiple protocols, several UI, a powerful command line, a huge community, is free, and is rock solid. It also has an excellent free book.
If you have a highly distributed development group and/or expect to receive open-source contributions from many different folks, go with the distributed capabilities of Git.
Beyond these two, save yourself a ton of time and hassle and forget everything else....really. I realize I am being opinionated, but you kinda asked for an opinion.

If I was to advise something to you, it would be
Use mercurial (aka hg), and start by
learning it in the command line. That
way you will learn all basic concepts,
which could be somewhat hidden from
you when using only GUI overlay such
as TortoiseHG. All with a good
simplistic tutorial of course, perhaps
widely known hginit which covers
some simple usage scenarios.
That would be answer to "What else should I know" part, at least for a start. You can then explore by yourself, having a limited, but somewhat solid base. Or, at least, you will be able to ask more concise questions to learn more, or make more sense of the SO question you quote. Your question is somewhat broader than this, of course, but I would advise not to try to grasp everything at once. Each system has it's own quirks and specialties, but you shouldn't be worried by that fact now. Just as with programming -- you should not try to learn many languages at once, if you don't know any yet.
Ah, and as a finishing touch: Tortoise(xxx) is not exactly a revision control system, thats just a typical name for a shell-integrated Windows client to system xxx. As far as I'm concerned, the "Tortoise" part refers to "shell".
PS. the "Mercurial" advice is due to my personal taste of course, but also by the feeling that learning Hg will enable you to grasp most of the ideas from other systems quite easy (if you ever need to).

From my personal experience I would recommend looking at the new generation of 'Source Control Systems' that are called Distributed Version Control Systems. These are systems like Git (and I think Mercurial but I haven't used that.) that actaully store a full version control system locally and when you commit to the remote repository (push in git terms) you push the changes in your local version control system to the master version control system on the server.
Also Git is designed to make Branching a breeze. In systems like Subversion branching is not as easy but with Git Branching is the recommended practice of making changes. I have used Git, Subversion (SVN) and SourceSafe(the worst Source control System of the three by far!) and this is the major advantage of Git over more traditional Source Control Systems.
For Example if you are fixing a bug or adding a feature in a code base that uses SVN the standard practice would be to
Check out the branch you are going to work in.
Make any bug fixes and test them.
Checkin the changes.
With Git or Similar systems you would
Branch the master branch locally (i.e. development, producton version 1.1, etc.).
Make any bug fixes and test in your locally branched version (i.e. you made a jira-123-bugfix branch for version 1.1).
Merge the branch back into your local copy of the master branch that you created it from and make sure everything is OK.
Then push the changes you made to your local copy of the master branch to the central Git repository.
The advantage of this is that if you have to go back and revist the bug fix you still have your local copy of that branch.
See articles like A Successful Git Branching Model for more info.

Are Visual Studio Express products really only for "hobbyists, students and novices"?

I have used Visual Studio Professional 2008, and have been testing the free C# Express 2010 version recently. In general I'm amazed at how good it is for free, and how many of the full VS features it has. I'm thinking of using it for a commercial program and I know the license allows for that, it's just the description of it being for "non-professional developers like hobbyists, students and novice developers" concerns me a bit.
What I'm interested in knowing is what is stopping it being 'professional', that is:
Have you evaluated the express edition, and found a specific useful feature lacking that stopped you from using it ? Or did you initially use the express versions, but upgraded to full VS because of a feature lacking ? If so, what was that feature ?
I've searched for similar questions and found lists of differences between the full VS and express versions, but I'm more interested in knowing peoples personal experiences with it. It seems like many of the extra features in VS target developers working in large teams, so I'm mainly interested in hearing from either solo or small team developers where it seems like there's less compelling reasons to upgrade.
The limitations I've personally encountered are:
Extensions not being supported, though I can still use DotTrace, NUnit and an obfuscator outside of the VS integration, albeit it's a bit less convenient.
Limited refactoring, although the "Rename" and "Extract Method" are still there and I think they're the most useful. Edit: Not having 'Encapsulate Field' in Express used to be annoying though, though the introduction of automatic getters and setters has pretty much canceled that out I think.
More limited debugging for multi-threaded apps.
Edit: Another is that you can't easily switch between targeting "Any CPU/x86/x64" in Express like you can in VS. It is possible, but needs manually editing your project file to do so.
But the pluses seem to outweigh the minuses so far. Is there anything you found was a deal-breaker for you ?
Update: To come back to this a couple of months later, and after releasing a product built with the Express version, it is indeed possible to program professionally with the Express versions. The limitations within the program itself are pretty minor and can be worked around, but I've increasingly come to realise it's really the "extensions not supported" one that's the (only) major drawback. No Resharper, CodeRush or the like, and no source control, profiling, database explorer or unit testing and the like within VS itself. It's more of a productivity drag than a deal breaker, but it is annoying to come across a cool looking VS extension only to see that "Not supported in Express versions" notice.
If anyone else is in the same situation, I'd evaluate the extensions you use (or might be planning to use) first and see how important they are to you. Express is fine if you don't use any extensions or could live without them without a significant drop in productivity, otherwise stick with the Professional version.

I've used express for 5 years, it has everything you need to produce professional projects. There's one important feature that's missing, which is the extensible Database Explorer, e.g. if you need to generate an Entity Framework model from a MySQL database. But for that I use Visual Studio Shell (also free). For other stuff such as unit testing and source control I use other tools. You really don't need Visual Studio to have everything you need to manage a software project.

No add-ins => No ReSharper => No dice.

The biggest problem with the Express version is you don't have any source control. You can't professionally work without it, even if you are a lone freelancer. Keeping a change history on a project is vital when you mess something up and want to go to a previous version or simply want to compare different revisions.
Also I think in Express you can't have web and desktop applications in the same solution, or do other types of combination of projects. I'm not really sure about this one, because I don't use Express (for the first reason :))

Other answers have covert the fact that it can very well be enough, but if you are more than a hobbyists, students or novices, just get enrolled into the Microsoft BizSpark program.
You get all the tools for free (Visual Studio Ultimate, Team Foundation Server, All Windows Versions etc.) and you don't even need to be a company. Enrollment is super easy and uncomplicated.
The only requirements are (taken from the homepage):
You develop software
Privately held
Less than 3 years in business
< 1mio $ per year
This is not an ad. We have been very happy with the program and got access to everything we needed. Just wanted to let people know it existed.
Additional info:
You can be member of this program for 3 years
When you leave the program you have to pay a 200$ fee, its made for startups afterall

I had been using VS Express for several years but I recently upgraded to VS Ultimate. There is nothing that you cannot do in Express, but the integration of features in the full product makes everything more convenient.
When you have source control, unit tests, performance/code analysis, installers all in the same solution, it saves a lot of time and hassle jumping between different programs. Also one big issue for me was not being able to mix features that are spread across the different Express editions, such as mixing ASP.NET with WinForms, or even VB.NET with C#.
I got a lot of use out of Express, it's a great product, but I was very happy the day I got to uninstall ten programs and replace them with one.

The pros:
Absolutely free
Has enought functinality for you to develop commercial products (you know the saying: you need 20% of anything to get 80% done). I developed and deployed a wp7 (windows phone 7) app with the express edition and it was a pleasant experience.
The cons:
No integration with source control. I use svn for my projects and i have to use tortoise svn outside of vs to manage the code. Its a minor annoyance, not a deal breaker.
Can't develop web/desktop/mobile in the same solution. Its easier to have them all in the same project when you have a common dll for your business logic. Unfortunately with express edition you will end up using copy/paste for moving dlls that are common between projects. Again it's a minor annoyance, not a deal breaker.

Professional is not the big step up here - Ultimate is. VS2010 Ultimate, for example, comes with bunches of profilers and that kind of thing. They give Professional away to any old student, for example.

There's only one plus: the cost. Every other difference is a minus (or at best reduces the cost of the minimum useful system). That means that, if the extra features are worth the money, buy the higher-end version.
The free lower-end version is great for (as they say) students, hobbyists, and novices. Students often don't have much money, and hobbyists and novices often don't want to spend all that much money on their hobbies and introductions.
However, a software professional is making money writing software, and presumably will make more money if he or she becomes more efficient. Assuming our professional is making decent money, the cost of an upper-end version of VS isn't large compared to revenues, and if it leads to even modest productivity increases it's worth it.
When you're doing something for money, don't try to do things too much on the cheap. Taking more time and inconvenience to do things will cost real money in that case, and avoiding it is worth real money.

Microsoft's marketing approach to these Express editions may be is to introduce Visual studio flavors to users (any user). Later, bring them on board with more powerful versions. Also, Express editions allows you to write code anywhere without getting worried about licensing part. You can use them to try out your test bed projects, community projects etc. I must re-iterate again that free licensing is the biggest draw towards Express editions

The only substantive differences I've found are the integration of code control and the ability to create heterogeneous projects. The first is not a major issue if you are the only developer. With the Express versions, You can use whatever code control mechanism you like, just not built in.
The second is only an issue if you want to develop using some combination of C++, C# or VB in the same project. You need at least VS2010 Professional to do that. Given the extensive features in C#, the absolute need to use C++ or VB with it in the same project is highly unlikely. However, those situations exist if you need C++ in a C# project for some low level API or have a legacy VB system and need some feature from C# or C++ that is just too difficult to manage in VB.
As a friend who built racing engines once observed: Speed costs money. How fast do you want to go? Express is free, the others can be pricey, although the price for VS2010 Professional just plummeted with the advent of VS2012.

Is the Windows dev environment worth the cost? [closed]

Microsoft offers lots of express editions of Visual Studio and SQL Server that are free of charge and may even be used commercially. In programs like DreamSpark, students can download e.g. Visual Studio 2010 Professional (full edition!) for free, so it is not said that you need to pay hundreds of thousands to develop Windows applications.
Other IDEs like SharpDevelop are available for free, too, but they are not nearly as terrific as Visual Studio. However, even when using the express editions, one can be very productive.
The MSDN library is free of charge, too. I cannot say whether the Telerik controls justify their costs as I have never felt the need to use them.

The cost of the tools is tiny compared to what you spend on the developers themselves. For example, most of the tools you've mentioned are included in Visual Studio Professional with MSDN, which runs about $800/year.
The real question, then, is whether you get any benefit from that cost. That's harder to answer, and I suspect depends on your developers and what kind(s) of software you develop. As such, it's impossible to give a blanket answer. Nonetheless, from the employer's viewpoint there's hardly enough difference between the two to notice.

The cost might not be as high as you think (depending on a lot of factors). There is the BizSpark program, and there are also 'express' versions of Visual Studio, SQL Server, etc, available.

Taking Windows 7 cost a side, you can use Visual Studio Express, SQL Server Express to create your applications. Of course this version has less features than the "bigger" ones but has the compiler, IntelliSense and many other stuff that makes a solid option.
Since you mentioned Blend, I think you are interested working with WPF, I don't think the Mono alternative is completely mature.

I have been a full-time .NET/C# developer of desktop and web applications since 2002, and of the pricey items that you list, the only one that I have ever paid money for as a professional deveoper is Visual Studio.
The cost of a current version of Windows is virtually inseparable from the cost of a new PC. SQL Server Express is free and is absolutely sufficient for virtually all development-related database needs. Don't need or use Expression Blend. ViEmu? Not a chance I'd pay for something as awful as vi. I've been able to get by without every using anything from Telerik.
Buying a copy of Visual Studio is far from an extraordinary investment in tools when one considers the productivity gains.

Well it always depends on your projects specifics but to the extent that it doesn't no, probably not for a web app. There's plenty of people out there who can code HTML/CSS, Javascript, SQL and at least one of PHP, Python or Perl so devs should be reasonably abundant. There's a whole bunch of frameworks, libraries and free code for each and you can use them all in any combination you like for no dollars down, no dollars per month.
As far as IDEs go if you're considering hiring web and web app developers who are uncomfortable working outside an IDE you're probably looking in the wrong place for developers. If you can't live without an IDE then Eclipse is OK assuming you have some pretty well specced dev boxen but I have to say the best code ninjas I've encountered all use either emacs or vim!
Also it's nice to code on a system with unlimited virtual desktops and a proper command line. Having said that I hear MS have made some progress with these in the last couple of versions so they may be more aligned now. I'd be loath to start coding a big project on Windows without making sure there were good builds or equivalents of tail, grep, systemtap/dtrace etc available though.
Funnily enough though the last web app I had to do was mostly in Windows as it was Flash based. The flash IDE was pure pain but thankfully most of the donkeywork was in the classes so I got to use the lovely Notepad++ for the bulk of that, anyway that's not really relevant to our discussion on the worth of the MS toolchain so I'll move along!...
Top tip if you're developing on Windows after working on Linux make sure to install Kat-Mouse and an "Always-on-top" program like deskpins or you may quickly end up defenestrating your dev machine!

You're mixing two questions here.
If I was spec'ing a new project (for myself), would I go with the Windows platform?
As a target? Yes. As the development platoform? No.
If I was spec'ing a new project (for myself), would I choose C# as my language?
Yes. Most definitely. The Mono project has a great set of tools that you can use to build Desktop, Silverlight, and Web applications. The web apps run inside of Apache, so you get to stick with all the common Open Source tools.
If you do things right, you can even use Mono on Linux to target Windows clients for a Desktop application (using the available subset of Windows.Forms that Mono includes).
If I was spec'ing a new project (for a company) would I choose the Windows platform?
Yes. The productivity gained is worth the extra cost. Microsoft also has several programs like BizSpark that are targeted at reducing the entry cost to development on the Windows platform.

I think this is a great question! Mostly because you asked it without being judgmental. Here are some thoughts from me:
Visual Studio and all of the tools are quite good. It is quite expensive but there are programs from Microsoft which can help with those costs. For example, in a smaller shop you might consider a TechNet subscription. Or one of the many small business helper programs from Microsoft like BizSpark.
Many .Net developers you hire will ask for or require Visual Studio and for good reason! They have used it for years and they are comfortable with it. So be ready for that. Not everyone will be that way but most will be that way. They know their tools and they use their tools.
That being said c# and .Net development is still just text :) I personally use VIM for my .Net development because I felt that a lot of the tools in Visual Studio just got in my way. I have had some bumps with that, I still use Visual Studio some of the time, because it has something I need. This is a great resource I use: c# with Vim Blog posts
So I would say try it both ways and be open minded :) it's a great language and a lot of fun to try.

To answer this question, which is a worthy +1 from me, in recent years the Microsoft developers stack has reduced in cost with the advent of the Express editions since after Visual Studio 2003, we're talking about Visual Studio 2005, this is where the Express editions started appearing to increase penetration of the Visual Studio to a wider audience, using a bare bones version which gave the wider audience a much bigger appreciation of learning the Visual Studio environment and reflected in the professional trade.
Now you can subscribe to Dreamspark if you are a student and avail of the professional version provided your student id checks out. Likewise the same for businesses using the BizSpark programme for businesses who wants to roll out a Microsoft platform onto the internet.
Your question more or less focuses on the extras outside of Visual Studio, Note, I am not talking about MSDN (in fact, that is an extremely vital part to have as it is a gem of a minefield of knowledge, know hows etc - that is now freely available) which boils down to this - use only the tools to get the job done first! No point for a professional developer starting out on these extras as they hardly make a real difference, not alone that, hitting their wallet and bank account very hard which is all the more a futile exercise!
Those extras you're talking about here, those extras such as Telerik and so on, lets get one point straight, sure it may add a pretty face to your app, but who cares? As long as you use the Visual tools to draw up the interface, add event handlers, add logic, test it and debug it, you will realize that those extras are not really worth it, even the end-users are not going to care if it has a pretty eye candy of an interface, as long as the end-users gets the job done simply and efficiently.
Now, over the last few years we have seen Mono's strength grow and conforming to the .NET 2 standards, I am not a preacher for Mono, have seen it and tried it, sure you can splice up an app to use Mono running on Linux, perhaps a back-end that communicates with MySQL, that relays results to a simple Windows forms, let me emphasize the words, you as a developer would have the choice and freedom to do so. Perhaps, work on that as a part-time thing outside of working hours, to investigate and learn. Sure, WinForms is somewhat reasonable on Linux, but just do not rely on Win API calls as that will produce undefined and unexpected behaviour in the context of a GUI application, if its a pure WinForms with no DllImports, the chances are good that it will work under Mono.
Of course, you are not necessarily tied to the Visual Studio platform when there's SharpDevelop, MonoDevelop, Mono for Windows available at your disposal, you need to think long and hard and see if it's worth it at the end of it all, no harm, in using the Visual Studio Express edition to do so, or even use SharpDevelop either.
Put simply, investigate your choices as long as you use only the tools to get the job done!

I'm going to do my best to be objective here. Let's start off the with some background. I do some occasional VBA and VB Script work, but that is pretty rare. I haven't worked with the more recent MS dev stack, but worked with it a few years back. Since then I made the transition to working with PHP and Ruby on Rails primarily. I do it from Windows because that is what I am familiar with. I have talked to a TON of people who are doing stuff with Ruby on Rails and PHP over the last couple of years and one thing that strikes me as a pattern is the fact that it is rare that I encounter a C# or VB (.net) developers on the street. When I do it is usually someone who is not that good. Maybe this is a regional thing. Maybe .NET people live inside 9-5 developer caves and only come out at certain times of the year. I don't know why it is, but it is. The fact that .NET people, especially good ones, are hard to find is a cost that nobody on this thread has discussed yet. Someone did make mention to the fact that people who are dependent on IDE's for development might not be the best people out there which supports this somewhat random hypothesis.
Don't get me wrong - I'm not supporting PHP or Ruby on Rails as the end all be all. All I am saying here is that the people cost is a big one. If you are working with tools that are preferred by the people who are arguably not always the sharpest ones in town then the benefits of tools may be less relevant in general. If you have a larger team then the extra cost of the tool set might be better spent on a more competitive bonus or salary for people on the team. Again, this supports the idea that you want the best team you can get first.
All of this assumes you have a choice of what you are doing from the onset. If you don't then there are some really good tools put out there by the MS dev community that are very useful. There are also tools like VMWare Server that balance the Windows/Linux divide. A smart team armed with good tools will get the job done well.

Debates about the quality of the result aside, you'd have a much easier time filling the developer positions on a new startup with people who are used to working with VS as opposed to developers comfortable working in Linux.

The cost of getting a Windows development computer setup is not that great in the grand scheme of things. Say it costs $10,000 (probably too high)( to get all of the software compared to $0 for an open source setup (assuming the cost of the hardware is the same). I would say your choice would depend a lot more on the developers you could find. If your project manager is familiar with and prefers Windows, wouldn't you rather spend the extra forty or fifty thousand dollars (assuming a team of four or five) to get something he/she is comfortable with? Compared to their salaries and others costs of employment, $50K is not a lot. Obviously that would change if you didn't have the money to invest.

The cost of setting up a dev environment in Windows does not have
to be so great.
The cost of the dev environment is really just a drop in the bucket
when compared to the cost of the
developers themselves. (This doesn't
help a small startup or a freelance
programmer, though).
You are getting there, but I don't think you really have the picture yet:
*1 Visual Studio Express editions are free for commercial development. VS Express may be called "Express", but they are better IDEs than anything I have been able to find in the Open Source community (for my needs, at least). There are a lot of other free tools too, so you can work around several of the limits of the express editions (for instance, source control is not integrated, but it's just as easy to setup a Git repo in your project's folders)
If you want to keep working with open source IDEs for C# on Windows, you can use SharpDevelop or MonoDevelop (There is a windows version), but I find both of them to be inferior to the VS Express editions. (Haven't checked in a while though, things could have changed).
So in actual fact, setting up a basic Windows development environment is not cheap, it's free.
I am a regular guy working on small projects in C#. The Express editions filled my needs pretty well and I am now considering the full versions using BizSpark https://www.microsoft.com/BizSpark/Startup/Signup.aspx
*2 What you are missing here is BizSpark. BizSpark is Microsoft start-up initiative. If your start up is less than 3 years old, generating less that a million $ in revenue and privately held, Microsoft will give you downloads of a full Windows Development environment, including almost everything (VS Pro, all SQL versions, MSDN premium, Vista, XP, Windows Server, Ms office, SDKs...and they even throw in a bit of free tech support). This lasts 3 years. When you exit the program, you have to pay $100 and you get to keep everything, except for the subscriptions. (Also, the license for non dev products allows only for usage as part of the dev process, not for regular usage)
In other words, if you are a small start-up, you get everything and it will cost you $100 when you exit the program.
Developing for Windows is not an expensive proposition at all, and the tools are excellent. Microsoft may be a lot of things, but stupid isn't one of them. They know that their business depends mostly on the development's ecosystem and they have made it very easy for people to develop for Windows.

What is the best practice for asp.net 3.5 build management for fast-changing line of business apps

I work with two other developers for a medium-sized company writing internal applications in asp.net. We have about 10 discrete web applications, about 5 class libraries, and probably two dozen assorted command line and WinForms apps. Management expects us to be able to roll out an application multiple times per day, as required by their business rules du jour.
We are currently (mostly) using Microsoft.Net 1.1 and SourceSafe. When we need to roll out a web app, we get latest from SourceSafe, rebuild, and then copy to the production web server. We are also in the habit of creating massive solution files with 5-10 projects so that everything gets rebuilt and copied to our "master" bin folder instead of opening up each project one by one to rebuild them.
I know there must be a better way to do this, and with Visual Studio 2010 and Microsoft.Net 4.0 being released in the coming months it seems like a good time to upgrade our environment. Does Microsoft have an official opinion/whitepaper on how to set things up? My biggest problem in the past was having a system that worked well with how quickly we're expected to push code into production.

There's a build server for .NET called CruiseControl.NET. You may find it useful as it can be heavily automated.

See "patterns & practices Team Development with Visual Studio Team Foundation Server".
Read the whole thing. It contains things you may never have known existed.

Just for the sake of offering different options, you can also look at Microsoft's Team System. It does cost a good bit and also has a bit of a learning curve. However, we use it where I work, and it makes the scheduling of builds and source control easy. I know some people are totally against everything Microsoft, but I honestly haven't run into any problems with TFS yet. Just another thought.

Dynamics CRM migration from 3.0 to 4.0 resources

We are about to embark on migrating our CRM 3.0 installation to CRM 4.0. We have a lot of custom entities, and have written a lot of code using the web service SDK, Stored Procs hitting the views in SQL for the entities, and even some Workflow and Callout DLLs. While I'm certainly not going to miss the .Net 1.1 development environment of the Workfows and Callouts, I am apprehensive about what's going to bite us hidden away in bowels of CRM. I have not had any experience with 4.0 at all.
My current gut feel is that this is either going to be fairly simple, or completely painful, with no middle ground.
Google searches have not turned up any good references, so I'm going to ask here:
Does anyone have any pointers, either links to resources, books to recommend, or even personal experiences that will ease the pain of transition?

There are a few gotchas, but first things first and visit this link. That's a Microsoft article that discuses upgrading to 4.0.
I've done about a dozen upgrades and most go smooth but here are a few things to consider:
Are you moving to a multi-tenancy environment? If so you'll need to rewrite your callouts to plugins.
If you have a large code-base, you should find any references to these deprecated classes or these deprecated messages
Are you currently on Server 2000 or SQL Server 2000? Neither is supported
There are a list of items that will NOT be upgraded and these may or may not be relevant to you.
I'd try and provide some more info but without knowing more about your system I wouldn't know where to begin. All in all, though, the move from 3.0 to 4.0 is HUGE from an admin/developer's perspective. I'm sure you'll enjoy the new system.

We Keep Coding

C# (C-Sharp) is a programming language developed by Microsoft that runs on the .NET Framework.