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.

ASP.NET 1.1 to 2.0 Conversion Continued

So far, I've identified three key issues with the upgrade process:

#1. Automatic Conversion Limitations - The automatic conversion seems to sporadically experience issues converting web pages and user controls that contain a namespace in the codeBehind definition. The strange errors I reported in my previous blog were completely caused by this issue. I found two key changes that needed to be made in the affected files:

The conversion automatically creates a new page or control declartion at the top of the markup code. The declaration looks something like this:

<%@ Page Language="vb" AutoEventWireup="false" Classname="myNameSpace.myPageName" CompileWith="myPageName.aspx.vb" %>

In certain situations, the conversion forgets to add the myNameSpace portion of the class name. This causes the IDE to be unable to link the page with the codeBehind, causing all sorts of confusion. If you see all sorts of strange compilor errors, including objects not being declared, look for this issue.

Another related issue is that VS.NET 2005 no longer needs the autogenerated code created by VS.NET 2003. In fact, if any auto-generated code exists, you end up with the same kinds of errors. It appears that the conversion process attempts to remove this code, but fails in many circumstances. You need to manually remove this section of code from each codebehind page:

#Region " Web Form Designer Generated Code "

'This call is required by the Web Form Designer.
Private Sub InitializeComponent()

End Sub

Private Sub Page_Init(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Init
'CODEGEN: This method call is required by the Web Form Designer
'Do not modify it using the code editor.
InitializeComponent()
End Sub

#End Region

I feel like this process is going to end up being fairly time-consuming in my case, as I have about 300 forms to fix. I'm dreading the fact that I may end up going through this process again when we are actually ready to switch over to ASP.NET 2.0...that is, if they don't fix the conversion process before then.

#2. ASP.NET 1.1 Page Paradigm vs. ASP.NET 2.0 Master Pages - Master pages are a great new tool available in ASP.NET 2.0, but it appears that the producers of VS.NET 2005 want to ensure you use them. In my current application, I've used user controls to mimic my own version of master pages. Every page in my application has the same format: (Which I apparently can't display, even using PRE tags)

myNamespace:myHTMLHeaderControl tag
form declartion
myNamespace:myPageHeaderControl tag
...content....
myNamespace:myFooterControl
form close tag
myNamespace:myHTMLFooterControl tag


Now, when I attempt to compile the application, every page complains with an error, rather than a warning, that the element form must be included within a parent element. I just went through a recent site overhaul, which led to the present master site layout. The recent overhaul occurred because I wanted to include a form element in every page header. The compilor complained unless the

and

were in the same page. Now, the compilor seems to complain unless and

are all in the same page. I'm guessing that this is where master pages fall into play. I'm really hoping I can run a single clever search-'n-replace to take care of this one.

#3. Could not find any attribute 'NAME' of element 'Hyperlink' - This one makes me mad. In VS.NET 2003, the IDE automatically added the attribute "NAME" to any control that you copy-'n-paste, even when the original control didn't have a name attribute. I guess some older browsers use the name attribute, instead of the ID attribute, in JavaScript code. Suddenly, with VS.NET 2005, all of these NAME attributes are declared illegal, generating errors rather than warnings. I'm really glad that you are actually able to generate XHTML 1.1 Strict code using ASP.NET 2.0, but this is annoying, considering VS.NET put all that crap in my code in the first place. If I invested a little more time in thoroughly understanding Regular Expressions, I could probably strip out all those NAME attributes with a simple AWK script. Again, hopefully the conversion process is updated, and the redundant NAME attributes are automatically removed before the final product is released.

#4. Option Strict disallows late binding: Did I mention that I love the fact that VS.NET 2005 now checks your markup pages, along with your code behind? When I first started this application, I was using the beta version of ASP.NET 1.0, and I hadn't yet developed the best coding practices. A large chunk of the current application code still has pages that don't even use code behind. I simply haven't had the time and energy to dig through all of the ugly .NET code I created during my first weeks/months on the project. Now that VS.NET 2005 won't even compile my application without fixing the bugs, I have no reason not to switch everything over to a nice, clean code-behind model. For instance, the following is no longer permitted:


<%# Container.DataItem("partNo") %>


Overall, I am pretty happy with the automated conversion process, even though it's going to be a headache to get this application to compile successfully. I haven't found a lot on the web on converting projects to VS.NET 2005, so I thought it would be nice to share my experience.

Good luck,

Mark Heimonen

ASP.NET 1.1 to 2.0 Initial Upgrade Experience

I am currently attempting to convert a fairly large ASP.NET 1.1 based application to ASP.NET 2.0 so that I can continue my evaluation of Whidbey. So far, I have had a mixed experience. The application I am working on is composed of:

A) A set of class libraries and data access libraries written in C#. These libraries work with SQL Server 2000

B) A large ASP.NET project written in VB.NET. This project uses a mix of calls to the class library and calls directly to a MS SQL 2000 Database

First, I attempted to create a sample ASP.NET 2.0 application that calls the c# class library written in C# (V1.1) . I was surprised and happy to see that this functions flawlessly. I am able to connect my classes directly to an object data source, and bind them to gridViews and detailViews. This is great news.

I've also noticed a few other cool features:

I accidentally added a c# web page to an existing vb.net web app. To my surprise, you can now mix different languages in the same app.

The VS.NET 2005 IDE is vastly improved. I love being able to drag from the toolbox directly to the source view (I hate the design view, and never use it) . I also love the feature which allows you to quickly select a section of code by grabbing the tag at the bottom of the source pane.

Back to my project upgrade experience -->In the future, I may attempt to run the class library through the upgrade wizards, but for now I wanted to simply upgrade the website the ASP.NET 2.0. When you attempt to open a 1.1 application, Visual Studio .NET 2005 automatically opens a wizard which provides you the opportunity to back up the application. The upgrade process takes a while to run, and eventually spits out an upgrade report.

For the most part, it initially appeared like the upgrade had succeeded, although the log reported that it was unable to parse 6 files. I could not see any reason why these files did not parse correctly.

After opening the converted project, I attempted to perform a build, and was left feeling disappointed. The compiler reported the maximum number of errors (92 errors + 60 warnings), and it hadn't even made it through the first 20% of the project files.

I see all kinds of strange errors listed in the task list:

Event "Load" cannot be found
Event "PreRender" cannot be found
name "Viewstate" is not declared
'asp' is an unrecognized tag prefix or device filter
'asp' is an unrecognized namespace (What?? This is on a page with a simple declared in the presentation layer. I'm glad that the IDE is now checking the markup during compilation, but I can't imagine that they've removed the ASP namespace)

name "SearchResults" is not declared --> These types of errors show up in my codeBehind files, even though my old project had them declared in the codeBehind file. At the MSDN event, I was told that we no longer need to declare our page controls in the codeBehind file because Visual Studio takes care of that for us. Supposedly, Visual Studio lets you use Partial classes, which allows the IDE to hide the ugly implementation details from the developer. Personally, I like to see everything, and I haven't figured out where VS.NET is trying to hide the rest of the class implementation. It looks like the conversion wizard tries to help out in this regard, but fails to place the control declarations in its hidden part of the code behind classes.

Even though this is a beta version of Visual Studio .NET 2005, I plan on plowing through this upgrade experience until I have a working version of my application. I will keep you up-to-date on any breakthroughs I have. I

Two sites I recommend

A couple weeks ago, I discovered two great coding-related sites which I recommend checking out:

The Daily WTF is subtitled "Curious Perversions in Information Technology.

On the Daily WTF, coders are encouraged to submit fragments of code they stumble upon that just don't make any sense. I highly recommend a daily visit to this site for a few quick laughs. I wish I still had access to some of the old code I've had to debug in the past, and I'll admit to having written some pretty foul code myself when I was first started out my software career. My personal favorite block of heinous code is How To Query "Pointless Pointless Pointless Pointless Pointless Pointless Pointless". I personally hate in-line sql statements, and that has to be the worst in-line statement I've ever seen.

Here's another good one: Good Table Name, Redux, where every table name in the system is a three-character abbreviation. If you ask me, the Software Development Industry has a long way to go before it becomes a mature industry. Databases such as the one illustrated here should simply not exist. Personally, I consider this type of development to be completely negligent.

I've had to waste more time than I care to think about working on poorly structured and documented systems such as those described on this website.

If you haven't checked out .NET Rocks yet, you are missing out. .NET is a weekly radio show hosted by Carl Franklin and Rory Blyth. The show features discussions on many .NET related technologies, and is quite entertaining. Each week, they invite guests to come on. Recent guests have included Rocky Lhotka, Jeff Richter, Miguel de Icaza, and Charles Petzold. In addition to the guests, Carl and Rory keep things entertaining with various features like "The Google Weirdos" and musical performances. They are currenltly on episode #79, and every episode is available for download in MP3 or WMA format from the website. I'm currently working on downloading and burning every single episode to CD. I enjoy listening to the shows with headphones during the workday, although I've occasionally caught myself laughing out loud, much to the disdain of my fellow co-workers.

ASP.NET 2.0 - Exploring objectDataSource

I finally got around to installing Visual Studio .NET 2005 Beta 1 (Whidbey) last night, after viewing a preview at an MSDN event in Toledo earlier this week. I was impressed with the enhanced databinding abilities included in ASP.NET 2.0--especially the claimed ability to automatically bind custom business objects--so I was eager to begin trying out this new feature.

I was a little disappointed to find so few online tutorials discussing how to use the objectDataSource object, so I started to explore the object myself. So far, my experience has been mixed. I have invested a lot of time during the past few years developing my own custom business object library, and I have developed my own standarized object format. So far, I have hand-coded everything I've ever written in .NET, and haven't found much use for the form designers and wizards in Visual Studio .NET 2003. The new objectDataSource, GridView, DetailView, and FormView components looked like an opportunity that was too good to pass up.

After a few minutes of tweaking I was able to bind one of my object collections to the objectDataSource, and get it to display in a gridView. For one, you have to manually set the "TypeName" and "SelectMethod" properties, and then select "Refresh Schema" from the smart tag menu to get started. When you first drop an objectDataSource onto the page, a wizard pops up to help you auto-configure the objectDataSource, but the built-in dropDownList doesn't let you select anything. I'm guessing they're still working on this feature.

Anyways, once you get the gridView set up, it's nice to be able to use the "Edit Columns.." smart tag to quickly generate the code required to remove the columns you don't want to display. The interface for the formView and detailsView is similary easy to set up.

Now, I'd like to explain where the objectDataSource falls short. My main issue with the object is how inflexible the "SelectMethod/SelectParameters", "InsertMethod/InsertParameters", and "UpdateMethod/UpdateParameters" are set up. I'm still hoping that I haven't explored the features enough, and that there are alternative methods to work with the objectDataSource. Here is my main gripe:

My business objects are all property based. To create a contact record, you would do something like the following:

myContact = new contact();
myContact.FirstName = "Bob";
myContact.LastName = "Smith";
myContact.ClientId = 34;
myContact.Insert();

(Each field is exposed as a public property on the object)

I'm pretty sure this is likely a pretty common practice. If you wish to set up the objectDataSource to automatically select, insert, and update your objects, they want you to use a single function in each case. So, to perform the following insert, I would need to add an additional function that looked like this:

Insert(string FirstName, string LastName, int ClientId)
{
firstName = firstName;
lastName = lastName;
clientId = clientId;
insert();
}

You also need to do the same for select, update, and delete statements. Maybe this is a pretty minor gripe? I'm currently working on a code generator for my entire business object library, and I could easily work these additional functions into the code generator, but still, I think it would be nice to have some additional flexibility in the objectDataSource. The dataBinding is smart enough to pull the data using the public properties--why can't it write back to the object using the same public properties?

I've actually only had Whidbey installed for about two hours, so I may be missing something here, but the lack of online discussion on the matter led me to write this blog. If anybody has any additional insight on the subject, please let me know. For now, I'm going to continue exploring my new installation of VS.NET 2005.