About the VS.NET Express beta products

Having watched Scott Guthrie's presentation at TechEd in Amsterdam last week about the VS.NET 2005 roadmap, and after having toyed around with some of the Express products, I do have to make some comments - and where better to vent them than a blog?

  • First of all - it is not clear to a lot of people what the 'Enterprise' differences are between the full-blown VS.NET 2005 and/or the equivalent Express IDE's. I have noticed (as expected) that the Class Designer and Source Control are not supported, but what else? What is the positioning of the Express products in terms of the 2005 versions of VS.NET? I think a feature matrix might help here.
  • SQL 2005 Express would be more useful with some sort of an interface. A very basic, cut down version of the SQL WorkBench would do miracles.
  • ASP.NET - and this is not just the Express products. Whatever happened to good old code-behind? Why isn't it the default anymore? OK, I can change it. But why does even the sample code in demo's show us ASP.NET mark-up and server side code intermingled? I thought the days of classic ASP were behind us...(just...) ;-)
  • Again on ASP.NET, it's nice to have SQL and XML data source ASP.NET controls in the markup, but does it really belong there? Designers who'd be only interested in the mark-up of the page, would rather not see a stored procedure name specified as an attribute of an UI-less ASP.NET control, surely!? Where's our UI vs. code separation?
  • With these Express products, every MS Access guru could use some wizardry and throw together a data driven WinForms or Web App, and say he's got experience with C# WinForms and Web Apps....that can't be good.

I might come up with more comments as and when I play around a bit more. These are just early observations.

What are your thoughts?

1 Comment

  • Hi Wim,



    When you create a new page in VS 2005 (both VS and Express) there is a checkbox called "code separation" that you can select/deselect to build the page using either code-behind or single-file. By default it is code-behind. This gives you complete code/content separation.



    Regarding the datasource controls, the ideal approach is to use the ObjectDatasource to point to a middle-tier component that encapsulates the data access. It is possible to also use the SqlDataSource to embed the SQL data access in the page - but it is much cleaner to build it in a 3-tier fasion and point to either a DataComponent or standard business component.



    Hope this helps,



    Scott

Comments have been disabled for this content.