June 2006 - Posts

Visual Studio 2005 ships with a new compilation model for ASP.NET. This compilation model has already been pounded to death so instead, I’d like to focus on its adoption. While there are many benefits to the new compilation model, there are also a few disadvantages. And, although the benefits of the current Web Site Project model (introduced with Visual Studio 2005) are tremendous, some developers have found it difficult to master especially for large enterprise projects where the simplicity of Visual Studio’s 2003 project model was more than adequate.

 

The outcry has been loud enough that Microsoft has decided to release another compilation model to Visual Studio 2005. The Web Application Project model will be fully supported going forward and is expected to be released with Service Pack 1 of Visual Studio 2005. In the meantime, the WAP offering is available for download on Microsoft’s website at http://msdn.microsoft.com/asp.net/reference/infrastructure/wap/default.aspx.

 

The WAP model essentially allows legacy projects authored under Visual Studio 2003 to be ported to Visual Studio 2005 format while maintaining the project concept that developers have grown accustomed to in Visual Studio 2003.

 

The strategy provides the best of both worlds because the Visual Studio 2005 feature suite and innovations are available in the new WAP model. For instance, personalization, theming, master pages etc are available in the new WAP model. The benefit is that developers can migrate with zero learning curve.

 

There are a few issues that you should be concerned about and a fairly exhaustive list is available at this link. http://msdn.microsoft.com/vstudio/default.aspx?pull=/library/en-us/dnvs05/html/WAP.asp#wapp_topic1

 

The new WAP model demonstrates that sometimes we have to take a step backward in order to take a giant leap forward. I believe that Microsoft has listened and responded appropriately by easing the burden of migration thru the WAP model. Project managers and decision makers can readily adopt this strategy since Microsoft has committed to fully supporting both models in the enterprise.

 
The O.W.C does not work correctly when used with VS 2005. This blog will provide a work-around of sorts. If you are not satisfied with this solution, you may consider switching to VSTO 2005 and thin clients to provide Office functionality. I'll blog more about this exciting approach at a later date, but for now, this fix is geared toward web pages.

One way is to embed the object tag in the Internet browser. Currently, there is no support for the OWC outside of Internet Explorer. Here is an example. Create a web project and open the aspx file. Embed the OWC object tag between the form tag.

<form>
<object classid='clsid:0002E559-0000-0000-C000-00000000004 6' id='sp' ></object>
</form>

If you switch to design view at this point, the spreadsheet will present as a tiny X. You can ignore it. When you run the application, the spreadsheet will show up normally. If you attempt to set design-time features by right-clicking on the tiny X, VS 2005 may crash unexpectedly.

A final option is to embed the object tag in the code-behind and stream it out to the browser. Here is a complete example.

using System;
public partial class _Default : System.Web.UI.Page
{
    string spreadsheet = "<object classid='clsid:0002E559-0000-0000-C000-00000000004 6' id='sp' ></object>";
    public string CustomizeSpreadSheet()
    {
        System.Text.StringBuilder scripter = new System.Text.StringBuilder();

        //it's safe to use document.all here since this can only run in IE
        scripter.Append("\n<script language='javascript'>");
        scripter.Append("\nif(document.all.sp != null){");
        scripter.Append("\ndocument.all.sp.ActiveWindow.FreezePanes = true");
        scripter.Append("\ndocument.sp.columns(2).hidden    = true");
        scripter.Append("\n}\n</script>");

        return scripter.ToString();
    }
    public string LoadData(string payload)
    {
        System.Text.StringBuilder script = new System.Text.StringBuilder();

        //it's safe to use document.all here since this can only run in IE
        script.Append("\n<script language='javascript'>function loadData(){");
        script.Append("\nif(document.all.sp != null){");
        script.Append("\ndocument.all.sp.CSVDATA=").Append(payload);
        script.Append("\n}\n}\n</script>");

        return script.ToString();
    }
    protected void Page_Load(object sender, EventArgs e)
    {
        Response.Write(spreadsheet);
        Response.Write(LoadData("'1,2,3,4,5\\n6,7,8,9'"));
        Response.Write("<script>\nloadData();</script>");
        Response.Write(CustomizeSpreadSheet());
    }
}

The code is fairly easy to understand. The customizespreadsheet routine simply adds some customization to the spreadsheet. The loaddata routine, fills the spreadsheet with data. Once these routines are called, data will be loaded and customization will be implemented on the server as a string. The string is streamed to the client and loaded in the browser to display the spreadsheet.

Until MS fixes the design-time bug, there is no way to actually allow the OWC control to be visible in the browser. Consequently, you will not be able to customize the controls at design-time. However, as the example demonstrates, you can easily add those customizations at run-time.

The code presents bare-bones functionality. You are free to use other constructs available to stream script out to the browser. Finally, I've used only the spreadsheet in this example, however, the other components