After having the Visual Studio 2005 Beta 2 for several months, I finally got around to trying out ASP.NET V2.0 and converting a small application over to it.
The conversion did not go too smooth. The project uses URL Rewriting and a custom form tag to strip the page name from the form action. The custom form tag allows the page to postback without having the URL in the address bar of the browser expose the true page name the browser is viewing. An example would be pages:
MyWebSite.com/Home/
MyWebSite.com/About/
MyWebSite.com/Services/
In each of these folders is a default page. When someone uses the Home URL above, they only see the directory folder as shown, they do not ever see "MyWebSite.com/Home/Default.aspx". This may not sound like much of a biggy and you might wonder why I even bother. One reason is that I can switch the page type (asp..net, .php, .asp or even .htm) at any time without breaking people's or search engine links to the specific page. This allows the web site to remain flexible to change and use any technology without breaking links.
The problem with this method is mostly due to a bug in Visual Studio that does not like the custom Form tags (a tag of a class derived from HtmlForm). Whenever I open a webform in the designer that contains a custom tag, it spews out an error:
--
Unable to cast object of type 'System.Web.UI.Design.HtmlIntrinsicControlDesigner' to type 'System.Web.UI.Design.ControlDesigner'
--
While the designer in VS has a problem with these tags, ASP.NET 2.0 does not and the forms function as they did in .Net 1.1. This is an annoying problem and forces me to manually change the form tags ("<skm:form></skm:form>") back to normal ("<form></form) when I want to edit the form in the designer and then change them back when I am finished. As you might guess, this is a pain every time you want to edit an ASPX page.
Another thing VS does not like is the method I use to maintain multiple web sites on my local Windows 2003 server development machine. I currently use a multi-homed method with names in a custom hosts file. The link below will give you more information on exactly what I use:
http://hintsandtips.com/ShowPost/42/hat.aspx
The reason I use this method is that I may easily have multiple websites on my server, each as root webs that I can access by the name of the domain minus the .com. For an example, at any time, I can point my browser to "http://rockymoore" and it will pull up my local version of this web site. Makes it very easy to keep track of the sites.
The problem is that every time I go to run a page in the debugger it gives me the message:
--
Unable to start debugging on the web server. You were not connected because a duplicate name exists on the network. Go to System in Control Panel to change the computer name and try again.
--
It does not seem to like the host file aliases for the web names. Of course, this was not a problem in VS.NET 2003 which worked great for all the above.
Supposedly, this is a bug in VS.NET 2005 and is said to be fixed in the final version when released. Until then however, I have to do an "Attach Process" and attach the debugger to the currently running web session to do any debugging. This again, is quite a pain if you have to debug/testing often.
I have noticed that html editor in the IDE is does not always render in a WYSIWYG manner all the time, but it is much better that VS.NET 2003's editor.
One thing I really do not like is the method they are displaying non-displayable components on a web form. In the past version, they would display a panel area below the page that would list all the components you added to the form (such as a dataset). In the new version they place those items on your actual form in your markup. Talk about ugly and hard to work with if you are laying out a page. They were sleeping on this one for sure!
The quick remedy to this is to change the "View/Non-Visual Controls" menu option to be not checked so that you see the page like it should be. Of course, to edit the components you drop on a page, you have to enable this again to see them.
Another little jewel I noticed and spent way too much time solving, was an error from vs.net when I tried to compile the web application that it could not find or load a web form's codeBehind (CodeFile) page. I spent many hours figuring out that, the real error was usually down the list and that this error was a ghost. Talk about wasted time!
Overall, though, this tool has a great deal of promise. There are many nice enhancements along with generation of XHTML forms instead HTML 4.0 transitional of VS.NET 2003. I could go on with a list of features, but those are listed all over the net. I just wanted to give people a little heads up of possible problems you might run into.