none
Go Live? RRS feed

  • Question

  • Anyone converted a production site to 2.0?  What kinds of problems did you encounter?  Was it a good decision?b
    Monday, July 4, 2005 2:59 PM

Answers

  • I am wrapping up developing an ASP .Net application with the GoLive license.  Choosing ASP .Net 2.0 was an error in this case.

    The databinding in ASP .Net is significantly harder to work with for anything sufficiently complicated.  Its great for binding to single tables and modifying reference data, but you end up working around the formview when doing anything complicated.  Figuring out how to do this took a little while.  There is no option for doing the databinding the old way, at least not with the designers, so you basically have to figure ways around the form databinding.  Ultimately this made the application take at least twice as long to develop as it should have.  Also, there were numerous bugs in the designers (including an annoying bug where the DataObjectType property on the objectdatasource keeps getting reset to System.Null when changing the objectdatasource properties) that caused the development to be slower until I got used to them.  I had also counted on the ReportViewer control with local reports for the reporting functionality, but I still haven't figured out how to deploy this to an ISP (it works great locally).  One last bug deserves mentioning.  The two way databinding does not work from templated controls in beta 2, such as a multiview or a panel.  It works to populate the controls, but not to update.  This should work properly by the time the RTM is released.  This again made the forms harder to code, since controls on the formview can not be accessed directly and have to be retrieved using findcontrol calls, making intellisense unavailable when doing the update code.  Except for reference tables (where a single table was being updated), I was not able to take advantage of the two-way databinding anywhere in the application.

    The login controls and security/profile functionality is great, and if you don't already have a version of this (there was a prerelease for 1.1 that is very code compatible), it may very well be worth doing the application in 2.0.  Also, when you are only working with a single table, the databinding functionality is great, to the point of being a downright no brainer to implement.  Just don't count on taking advantage of this if you use multiple datatables.  Master pages are also very nice, although they give only a slight productivity gain over user controls in 1.1.  There are numerous menu controls out there for 1.1, but there is a big bang for the buck in the ones in 2.0 as they support filtering by roles.

    One thing of note; I had originally counted on databinding to datasets, and using the formview databinding (particularly the two way binding) to make the development go faster.  The datasets do not work well with the formview or detailview if the dataset has multiple datatables; in fact you can only specify a single datamember as your source for these controls and that datamember is the only one available to the child controls, unlike 1.1 where you can specify the datamember by control.  If you use business objects with embedded objects, this works much better with the model, as you can bind the embedded objects to web user controls in the formview.  I haven't attempted to make the databinding work inside the web user controls (I spent WAY TOO MUCH TIME trying to make the databinding work properly already) but I suspect this would work with a formview in the web user control, and overriding an object datasource control's ObjectCreating event to get it to use a passed object. 

    Really it comes down to analyzing your application and judging what features from ASP .Net 2.0 you will be able to take advantage of.  I probably will do other applications under the Go Live license, especially now that I know where the pitfalls are.  But my advice for anyone doing their initial one; I would count on it taking considerably longer than the development under 1.1, and this is NOT including learning curve.  You can implement much of your website without code and in these places you get a major productivity gain, but in many cases, where you do need to use code, the code is harder to implement.
    Monday, July 4, 2005 11:58 PM

All replies

  • Hi,

    I converted a APS .net 1.1 project to 2.0 and had to rewrite nealy the half application.But it was worth its work !!
    Monday, July 4, 2005 3:43 PM
    Moderator
  • I am wrapping up developing an ASP .Net application with the GoLive license.  Choosing ASP .Net 2.0 was an error in this case.

    The databinding in ASP .Net is significantly harder to work with for anything sufficiently complicated.  Its great for binding to single tables and modifying reference data, but you end up working around the formview when doing anything complicated.  Figuring out how to do this took a little while.  There is no option for doing the databinding the old way, at least not with the designers, so you basically have to figure ways around the form databinding.  Ultimately this made the application take at least twice as long to develop as it should have.  Also, there were numerous bugs in the designers (including an annoying bug where the DataObjectType property on the objectdatasource keeps getting reset to System.Null when changing the objectdatasource properties) that caused the development to be slower until I got used to them.  I had also counted on the ReportViewer control with local reports for the reporting functionality, but I still haven't figured out how to deploy this to an ISP (it works great locally).  One last bug deserves mentioning.  The two way databinding does not work from templated controls in beta 2, such as a multiview or a panel.  It works to populate the controls, but not to update.  This should work properly by the time the RTM is released.  This again made the forms harder to code, since controls on the formview can not be accessed directly and have to be retrieved using findcontrol calls, making intellisense unavailable when doing the update code.  Except for reference tables (where a single table was being updated), I was not able to take advantage of the two-way databinding anywhere in the application.

    The login controls and security/profile functionality is great, and if you don't already have a version of this (there was a prerelease for 1.1 that is very code compatible), it may very well be worth doing the application in 2.0.  Also, when you are only working with a single table, the databinding functionality is great, to the point of being a downright no brainer to implement.  Just don't count on taking advantage of this if you use multiple datatables.  Master pages are also very nice, although they give only a slight productivity gain over user controls in 1.1.  There are numerous menu controls out there for 1.1, but there is a big bang for the buck in the ones in 2.0 as they support filtering by roles.

    One thing of note; I had originally counted on databinding to datasets, and using the formview databinding (particularly the two way binding) to make the development go faster.  The datasets do not work well with the formview or detailview if the dataset has multiple datatables; in fact you can only specify a single datamember as your source for these controls and that datamember is the only one available to the child controls, unlike 1.1 where you can specify the datamember by control.  If you use business objects with embedded objects, this works much better with the model, as you can bind the embedded objects to web user controls in the formview.  I haven't attempted to make the databinding work inside the web user controls (I spent WAY TOO MUCH TIME trying to make the databinding work properly already) but I suspect this would work with a formview in the web user control, and overriding an object datasource control's ObjectCreating event to get it to use a passed object. 

    Really it comes down to analyzing your application and judging what features from ASP .Net 2.0 you will be able to take advantage of.  I probably will do other applications under the Go Live license, especially now that I know where the pitfalls are.  But my advice for anyone doing their initial one; I would count on it taking considerably longer than the development under 1.1, and this is NOT including learning curve.  You can implement much of your website without code and in these places you get a major productivity gain, but in many cases, where you do need to use code, the code is harder to implement.
    Monday, July 4, 2005 11:58 PM
  • John, you are right about everything... Unfortunately, ASP.NET 2.0 is very troublesome to implement due to countless bugs and mostly non-existent documentation. Although you may find some nice articles on What's New in 2005, you won't find nearly complete docs on most classes! Where it says, "Here is an example..." it does not provide one, etc.

    John, I have troubles with FormView, too. I am binding a collection of classes to it and that collection has one class in it. I specify formview's DataSource property, then do .DataBind(). The collection (Products) contains only one class (Product) because this is the page for adding a new product. I can see that binding works (at least one-way) because the default values are being read properly from Product's properties. However, when I try to retrieve the Product class OR Products collection from the formview via such properties as .DataItem and .DataSource, I get Nothing in return. And I do use Bind(propertyName) instead of Eval(propertyName) syntax. But I don't even get the original collection I assigned to it!? What's going on!?!?

    The formview is in edit mode by default. I load the page, bind the collection to the formview, then click Save, and I get Nothing from the DataSource property. How does one bind a collection of classes or retrieve anything data-bound out of a formview?!

    THANK YOU!!
    Tuesday, July 19, 2005 1:23 PM