I spent the last couple of days in the Visual Basic.NET SDR up on the Microsoft campus. It was an enlightening experience and while much of what we we were told is NDA stuff, I learned quite a bit about Microsoft’s approach to making VB.NET better. They are working hard to bring as many VB6 developers over to .NET as possible. Hopefully, this means VB.NET but I don’t think it makes a snit of difference whether they use VB.NET or C#. Sure, I think VB.NET has (and will continue to have) a lot more appeal to VB6 developers (and their managers) especially having seen some of the new features being planned for the “Orcas” release. However, if developers pay the price to transition to .NET, most of their battles will be won.
The Rest of the Story...
No, I won’t steal Microsoft’s thunder as they want to make a number of Orcas announcements at TechEd to try to sell them to the developer community. Just a word of advice here--based on past experience, the Microsoft marketing team and evangilists have been known to go over the top in their enthusiasm of each upcoming release.
As to VB6 conversion support, it’s clear that the VB.NET team takes this challenge seriously. They have come to the conclusion (based on reports from the trenches) that COM interop makes a lot of sense for those transitioning large VB6 applications or app suites. They suggested that more emphasis should be made on using VB6 to interact with .NET forms and they plan to help developers do that. I think it’s safe to say that there were a number of very cool new features that VB6 folks have been asking to see for a long time incorporated in the plans—these are bound to make a number of VB6 customers more inclined to convert.
I was disappointed to hear that more progress had not been made on the documentation issues. Last year’s SDR was laden with feedback about the search engine (which still has not changed), the “un-topics” (topics with no meaningful content) and the screwed up help links. While I’m sure the doc folks are working hard on this, I don’t see much progress here. All of the gurus and pundits brought in for the SDR agreed that Google was used far more widely than the sad little search engine used by Visual Studio help. Unfortunately, when one hits Google, we often find content from every Visual Basic release since Leif Erikson discovered the east coast of America (and doubtless found native Americans standing there waving back). But I digress. I plan to get back up on campus and help the doc team get back on track if I can. IMHO, they have a lot of work to do so they need to build up a lot of steam to get over the mountain of topics that need help (so to speak). I think they should start by focusing more on the basic topics like the ReportViewer control, but others think that these are adequately covered by third-party authors (like me). I’ve read a lot of the third-party content and found it’s okay, but still lacks much of the depth that serious developers need. Others at the SDR felt that Microsoft should focus just on topics that don’t show up in Google… Perhaps that’s right, but I also think that it would help if Microsoft knew what topics were most requested and make these the top priority. As to the search engine, we told them to buy Google a long time ago. It’s clear (based on the feedback they got on the MSN search engine’s appeal (or lack of it) in the developer community that they need another viable solution. It seems to me that Google will let applications use their search engine from within an application… humm.
One subject that kept coming up as we were shown one new data access feature after another, was business rules. Since the dawn of the first data access interface, little accommodation has been made to deal with the problems associated with data integrity. Sure the new strongly type DataSet and TableAdapter classes include specific types for columns, but no support what-so-ever for making sure that value is in the right range, has the right mask pattern or set to the current default value. Much of the code we write in forms-over-data applications is to implement data validation—I (and many of the other SDR attendees) feel that this job should be easier and automated. For example, if there was a standard way to set the min, max, default, acceptable values (like 10, 20, 25), length, mask, prompt, currency type and a bevy of other attributes, we could write business-rule validation routines far more easily. As it is, if these rules are hard-coded, they have to be recompiled and redeployed with each change. IMHO, Microsoft would be better served (and more respected) if they spent (far) more time on this missing functionality that virtually every application could use before creating a revolutionary new objects approach to data access. Unfortunately, this elephant in the room was quickly covered with a big tarp—and Microsoft went on with the sales pitch for the new Entity Data Model architecture.
I agree with you whole-heartedly on the issue of data validation.