Whidbey Project Conversion Woes, Continued...
I've decided to give up on my dream of converting my web application to ASP.NET 2.0 using Beta 1 of Visual Studio .NET 2005. After getting past the first set of compiler errors, I realized that it would be just too time-consuming to complete the process until the official version of Whidbey is released. I do plan on converting the main shell of the site over to a master pages layout, which should be a lot of fun.
It turns out that DataBinding in Whidbey has been significantly altered, and a lot of my pages using asp:repeaters and asp:datagrids will not compile because "Option Strict On disallows late binding". I've been using Option Strict all along, but the compiler never checked the markup pages before. For instance, the following code in a repeater is no longer acceptable:
code does not display correctly, because I can't figure out how to display preformatted text. I was demonstrating how to bind a container.dataitem variable to the text in a textbox, within a repeater. Anyways, I've decided to set up a Hello BloggerBot account, and use graphical images to demonstrate code in the future. :)
Due to these extensive changes, I have temporarily put my project conversion plans on hold.
On the bright side, I did have some positive conversion experiences. I successfully converted two c# class libraries today, without a single hitch. The first is a relatively small (4K Lines of Code) base class library. The second was my data access layer, which was weighs in at 35K LOC, and 198 individual source code files. Mind you, about a third of the files are mindless strongly-type arrays. I can't wait to see if I can find a way to use generics to rid myself of this useless boilerplate code. I'm also looking forward to using partial classes to help ease the pain of code generation :) I haven't had a chance to diff the converted project against the original, but on first glance, it does not look like the conversion process made any changes at all.
I was able to generate a "Class Diagram", which is kind of cool, but it ended up being similar to my experience with diagrams in SQL Server 2000. I attempted to expand all of the classes, but the diagram generator was not smart enough to spread out all the items, and everything ended up overlapping. I guess I should say "what do you expect when you have 198 classes?", but who has time to manually drag hundreds of objects around until they appear in a usable fashion. As with the diagram tool in SQL Server, this appears to be a gimmick once you reach a certain level of complexity. The tool was able to diagram inheritance within the project file, but did not appear to recognize inheritance from classes in separate classs libraries. I could be missing something there. A cool feature is that the classes had context-sensitive menus, including "refactoring". I wonder if refactoring would correct code appearing in separate projects, or if the refactoring would be limited to the scope of a single project?
For my next task, I plan on attempting the conversion of a c#-based web services project. I haven't heard much about web services in Whidbey, so I'm not sure what type of results to expect.
It turns out that DataBinding in Whidbey has been significantly altered, and a lot of my pages using asp:repeaters and asp:datagrids will not compile because "Option Strict On disallows late binding". I've been using Option Strict all along, but the compiler never checked the markup pages before. For instance, the following code in a repeater is no longer acceptable:
Due to these extensive changes, I have temporarily put my project conversion plans on hold.
On the bright side, I did have some positive conversion experiences. I successfully converted two c# class libraries today, without a single hitch. The first is a relatively small (4K Lines of Code) base class library. The second was my data access layer, which was weighs in at 35K LOC, and 198 individual source code files. Mind you, about a third of the files are mindless strongly-type arrays. I can't wait to see if I can find a way to use generics to rid myself of this useless boilerplate code. I'm also looking forward to using partial classes to help ease the pain of code generation :) I haven't had a chance to diff the converted project against the original, but on first glance, it does not look like the conversion process made any changes at all.
I was able to generate a "Class Diagram", which is kind of cool, but it ended up being similar to my experience with diagrams in SQL Server 2000. I attempted to expand all of the classes, but the diagram generator was not smart enough to spread out all the items, and everything ended up overlapping. I guess I should say "what do you expect when you have 198 classes?", but who has time to manually drag hundreds of objects around until they appear in a usable fashion. As with the diagram tool in SQL Server, this appears to be a gimmick once you reach a certain level of complexity. The tool was able to diagram inheritance within the project file, but did not appear to recognize inheritance from classes in separate classs libraries. I could be missing something there. A cool feature is that the classes had context-sensitive menus, including "refactoring". I wonder if refactoring would correct code appearing in separate projects, or if the refactoring would be limited to the scope of a single project?
For my next task, I plan on attempting the conversion of a c#-based web services project. I haven't heard much about web services in Whidbey, so I'm not sure what type of results to expect.
posted by markh100 at 1:07 PM
0 Comments:
Post a Comment
<< Home