So you like new Whidbey features like intellisense enverywhere but you only have ASP.NET 1.1 hosting? Have an existing ASP.NET 1.1 site to take care of? Sounds like me 😉
Last week I have spent some time redoing my formerly static, *nix hosted Web site to ASP.NET and moving it to Windows 2003 server host. Sure I preferred to use Whidbey, but no ASP.NET 2.0 hosting is available yet. So I decided to try and see if I can manage 1.1 site with Whidbey tools. In fact, I managed fairly well.
Now, the usual disclaimer: this is not something that is supported. If something does not work, please don’t complain to tech support. Please don’t try it on real commercial high value sites. You should not be doing it anyway since Whidbey is just Beta 1 product. Please don’t hold me or Microsoft responsible in any way.
Now that you were warned. I wanted to have
1. Front page with general news and announcements.
2. Family page in Russian for our relatives and friends with family photo album.
3. Random photo of the day from my art collection on the front page and random family photo on the family page.
4. Page dedicated to my Audio/Video projects.
Later I was plannig to add photo album, blog and feedback/discussions. Since I wanted to exercise more of VWD functionality, I decided to add something that would consume a Web service. I developed weather forecast user control that pulls weather data off the NOAA Web service, parses XML and renders nice weather forecast for the upcoming week.
I used 1.1 Portal Starter kit as a template. I installed Visual Web Developer Express 2005, but then I reconfigured IIS on my local XP Professional to run ASP.NET 1.1. This way I could open my Web site as file system Web in Whidbey to run and debug with Cassini. I could also run in the browser against IIS localhost to verify that app runs fine in 1.1.
In overall I was able to flip between 2.0 and 1.1 fairly smoothly since original code was 1.1-based solution. There were a few fixes I had to make in the Portal source code to make 2.0 C# compiler happy. The biggest hassle was to manage compilation in the Code folder in Whidbey vs. building an assembly manually and dropping it into Bin folder in 1.1. Once in a while Whidbey complained that I had one assembly in the bin and another compiled from my sources in the Code folder both serving same types. I had to remember to delete the assembly in the Bin before running application in Whidbey and rebuild it from command line using 1.1 compiler before trying to run the app on IIS with ASP.NET 1.1.
Basically, my workflow was
1. Work in Whidbey, debug and run with Cassini.
2. When done and ready to try on 1.1, rename Code to Code~ in the Solution Explorer, open command line window, build the assembly from cources in the Code folder using 1.1 compiler and put bits in the Bin.
3. Run against local IIS with ASP.NET 1.1.
4. Repeat 1-3 as necessary.
5. FTP bits and pages to the remote site.
I had to establish connection to the remote database since Whidbey publishing does not currently support replication of local SQL Express database to the remote SQL 2000 database.
You have to be careful though not to use any of the new features such as master pages, generics or any new controls. When in doubt, check with MSDN if the feature is available in 1.x . In most cases 1.1 compiler will bark on new features, but it is aways better to check twice. Since Whidbey does not support CodeBehind directly (it requires migration), the described steps only apply to sites with code inline.
The result can be seen at http://www.arkhipov.com