@Charles: Sure did, I watched the entire GoingNative 2012 conference over CH9 as well as all the talks, pretty sure I've almost watched ever language oriented video on this place. GoingDeep and Checking In with you and Erik Meijer was one of my favourites. As an independent developer doing this without any kind of degree, I thrive on learning from videos like these to gain expertise (Rather than just knowledge), whitepapers, et cetera, et cetera. So never stop the videos from coming!
Jason made a comment that Microsoft will continue to invest in existing technologies like Asp.Net Web Forms, and Windows Forms. Can we get some additional comments or details on this? I haven't moved to WPF quite yet because with my in-depth experience with WinForms I can still make beautiful user interfaces that are performant, so I'm curious as to the details of what he meant.
Hey EF team! I have a question that has been driving me and others nuts, because a solution is not easy to find on the net. What is the best way to output metadata files for multiple types of databases to file (or embedded).
For example, I have a EF model that defines my database schema. The same model is used for both MySQL and SQL Server. The current way we have dealt with this is to change the DDL Generation Template property between SSDLToSQL10.tt and SSDLToMySQL.tt and build each one to get the appropriate output, then load them from the file system in our app.
This has to be done manually for each database type we support. So we have to do a build for SQL, and a build for MySQL. Is there a better way to automate this process so we don't have to manually edit the model in Visual Studio causing a checkout from source control and to prevent breaking the model? It would be best if these changes did not have to be made manually each time.
I didn't think there was any poor presentation skills here. I think the gentlemen in the middle (Diego I believe) could have been a little bit more involved through the beginning, but it was a good video and educational nonetheless.
I however see different data in terms of Linq to SQL usage over Linq to Entities in the field. Primarily because Linq to Entities has some problems on Windows XP and that is a large platform in the deployment area, specifically for line of business and enterprise software. Its also quicker out of the box to knock out a Linq to SQL classes model and start coding right away, without the worry about how to handle the metadata files that are intrinsic to Linq to Entities.
Despite all of this, I agree that Linq to Entities is the way to go in the long run. I use it in many of my products and services to support multiple database models (primary SQL Server and MySQL).
Keep up the hard work and will look forward to more videos to come.
@rogreen:I actually prefer longer episodes that go really in depth. I listen to these while I work and the longer episodes allow me to listen without having to load a new one in the player every few minutes. As far as going in depth I am an advocate of learning through experience and from others rather than just white papers. Shared knowledge is often more easily remembered and the experience that comes with it is something you can't get from a document.