I've noticed more and more customers getting into MySQL instead of paying for SQLServer. For the record, I much prefer developing with SQLServer because there are many features MySQL doesn't have; that being said, MySQL has an attractive price tag for inhouse application development -- free -- and offers the basics. I generally side with Frans Bouma's post about Stored Procs adding a new API to maintain in your application; I use a data-entity framework that constructs SQL statements in memory, based on class metadata. It's very slick and I never have to worry about porting an app from SQLServer to MySQL (or elsewhere) because it's plain vanilla SQL. Now, I still end up writing Stored Procedures from time-to-time, but only when the customer intends to be tied to SQLServer.
The following link is a good one for connecting to MySQL with .Net: http://www.mysql.com/articles/dotnet/ (although the site to download dbProvider from eInfoDesigns is dead --hopefully only temporarily!). I've had success with the MyODBC driver, but I'm following the MySQLConnection work that's going on at SourceForge -- still in beta but it won't be for long.
Of course, when Yukon becomes available the gap between SQLServer and MySQL will broaden. From what I've read about Yukon, it sounds like the term “Database” takes on new meaning to Microsoft -- they've added whole layers of functionality that MySQL can't compete with. SQLServer development will dramatically change, and sticking to “plain vanilla SQL” will surely become less attractive and productive . . . but for now, with MySQL, it's not a bad substitute.
Happy .Netting!