Converting a WebSite project to a Web Application project

.. an interesting journey

In the last few weeks we have been preparing a conversion from a WebSite project to a Web Application project in Visual Studio 2005 solution. To complicate things a bit there is also SharePoint in the equation.

The reason to do the conversion was that we could not automate the build process in TFS and subsequently could not automate the deployment. Also the building of the solution itself within Visual Studio was handwork and took about forever.

What did we do?

Well, quite a lot was done to do the conversion. Along the process we were wishing louder and louder that someone had used his brain before picking the WebSite project. We had about 180 User Controls and about the same number of WebParts, that used these user controls. I know, what you want to say, probably not the best architectual design decision. But then again, when you do not take the time to think about the architectual design no one can put the blame on you for making the wrong architectual design . Duh.

We needed to do a two fold conversion: once for the User Controls and once for the WebParts.

Image by Getty Images via Daylife

Converting the User Controls

We created a new Web Application project, deleted the Default.aspx and the Web.Config files and then copied all user controls from the WebSite project. Then we did a Convert to Web Application action through the context menu in the Source Explorer. This adds a.o. the designer files.

Using a specially written tool we processed all ascx and ascx.cs files to add namespaces, change and delete some of the attributes on the <%@ Control %> node. And we added a <%@ Assembly %> node.

Converting the WebParts

In the WebParts the UserControls were instatiated in the CreateChildPanel() method by calling the constructor. That needed to be replaced by a Page.LoadControl() command. Another tool was created to do that conversion.

Bumps in the road

We first figured the process out by creating a small and simple Proof Of Concept. That worked like a breeze. Then we started on a copy of the real code. Yep, that's when the manure hit the propellor. We came across multiple problems, mostly because of inconsistencies in the coding. Sometimes there were comments when did not expect them or a code file was not placed in the correct folder. So, some of our assumptions failed and we had some manual clean up after our conversion tools. But that was limited to roughly 20 files. Not too bad.

But we also saw that our Proof Of Concept was many times less complicated than our real world code. That kept us busy with debugging for quite a few days. That and the fact that we were not experienced SharePoint deployers did nt help speed things up.

Ready to roll

Last friday we were ready to roll. We had figured everything out and had fixes for all the small problems that we encountered. So, the monday was set as the big conversion day. We mailed our offshore team in India to stop any work on the code around noon and made a branch in TFS.

The Big Bang conversion

With the script in hand we took the steps one at the time and started the conversion at half past one. Ticking off each step we were ready to try and compile about an hour later. More manure hitting the fan. Some caused by missing references and some by the new code that was created by our friends in India. They did coding while we were testing out the conversion so we were now working with a new code base. So afcing some new interesting bumps.

We only had to do some things a second time, having forgotten to update one of our conversion tools. Gradually we saw the number of build errors go down from 300 and then up a bit again. And finally at half past seven we had a fully building situation we then checked in in TFS.

Today

Today, we hear some enthousiastic noise from fellow developers who find that the solution compiles a lot easier, without any manual building of separate projects and above all a lot faster than before.

Also we are now starting testing the deployment and ironing out any last bugs that are in there.

Lessons learned

The most important lessons learned is that especially in bigger application development projects it is absolutely necessary to think before you do, design before you start building as that will save you loads of time and trouble later on.

Further we have learned a lot about conversion and file manipulation through RegEx and changing files loaded into MemoryStreams which was an interesting excercise as well.