+1-888-365-2779
Try Now
More in this section
Categories
Bloggers
Blogs RSS feed

Sitefinity 4.0 CTP – Web Application Project Support

by Gabe Sumner

The purpose of this blog post is to announce that the Sitefinity 4.0 CTP Project Manager now creates Web Application Projects.  [Get to the point.]

Sitefinity 4.0 Web Application Project

However, before I get to this, I have a confession to make: I’ve spent most of my career in the PHP and Perl world.  In these environments, there is no such thing as a “project”.  All code is dynamically compiled at runtime. 

As a result, web development looked a lot like this:

1.  Edit the code
2.  Refresh the page in the browser
3.  See the changes
4.  Rinse-wash-repeat

This workflow became embedded in my head for many years.  When I migrated to the ASP.NET I continued to follow this workflow.  Watch any of my Sitefinity videos and you’ll see me doing this constantly.  All of this worked fine until I stumbled into a Web Application Project.

Where are my changes?

I was able to use the workflow described above because Sitefinity 3.x used Web Site Projects.  Web Site Projects are file-based, not project based.  Any file placed in the web site directory automatically becomes part of the pseudo project.  Furthermore, any code-changes get compiled dynamically when accessed for the first time.

However, there is another ASP.NET project type known as Web Application Projects.  Web Application Projects are true Visual Studio projects.  Files located in the project directory can be excluded from the project.  All project code is compiled into a single DLL.  Furthermore, this compilation does not happen automatically.  This means, after code is edited, clicking refresh in the browser accomplishes nothing. 

As a result, workflow in a Web Application Project looks different:

1.  Edit the code
2.  Press F5 in Visual Studio  (build and start debugging)
3.  Wait…  Wait…  Wait…
4.  Default page opens up in the browser
5.  Wait…  Wait…  Wait…
6.  Re-navigate to whatever page I was interested in testing
7.  See the changes.
8.  Press Shift + F5 (Stop debugging)
9.  Rinse-wash-repeat

There are short-cuts to this process.  For example, you can leave the web browser open and then use F6 to simply rebuild the solution.  Even with these shortcuts I’ve not been able to reproduce the sheer simplicity of merely refreshing the web browser for the latest changes.  Suggestions?

What are the advantages?

At a glance, it looks like Web Application Projects involve a lot more work.  I, personally, spent several months hating them.  Web Application Projects inserted extra steps into my cause & effect development workflow.  However, as my projects grew in complexity, I discovered a handful of advantages to Web Application Projects. 

For example:

More predictable (and accessible) namespaces

Many months ago I wrote a blog post describing how to create a ControlDesigner for Sitefinity 3.x.  The blog post described how to create a base class (in ~/App_Code) to facilitate communication between the UserControl and the Control Designer.  This trick is necessary because, in a Web Site Project, UserControls are compiled dynamically and only exist in the namespace while actively in use.  

To overcome this limitation, I used App_Code and a special Base Class to bridge the gap between these 2 dynamically compiled controls.  This is confusing and painful. 

In a Web Application Project, this trick isn’t needed; the entire project is compiled in advance (not at runtime) and all UserControls (and their public properties) are accessible without any App_Code tricks.

The project source code isn’t sitting on the server

Because all code is compiled into a single DLL, I don’t need to deploy raw source code to the server.  This makes is very unlikely that code will get changed outside the formal build & deployment process.

Web Application Projects work like other Visual Studio projects

In my own opinion, the main advantage (or disadvantage) is that Web Application Projects work like other Visual Studio projects.  By contrast, Web Site Projects are a bizarre aberration.  This will probably seem great to Microsoft developers and will probably feel foreign to PHP, Perl, Python and Ruby developers. 

More Information:

Microsoft created a very helpful article that compares Web Application Projects to Web Site Projects.  I also found a helpful question on StackOverflow.  These two resources explore the differences, advantages and disadvantages of these two project types.

Formal support for both ASP.NET project types

It has always been possible to convert Sitefinity 3.x Web Site Projects to Web Application Projects.  However, several Sitefinity customers requested that we formally support Web Application Projects (source 1, source 2, source 3).  Telerik is delivering that formal support in Sitefinity 4.0.

The Sitefinity 4.0 CTP Project Manager creates Web Application Projects.  However, the final release of Sitefinity 4.0 will offer a choice of project type.  Customers will be able to choose the project type that best fits their development style. 

What about you?  Do you prefer Web Application Projects or Web Site Projects?  Why?

7 comments

Leave a comment
  1. Luk May 19, 2010
    This is great news!

    Namespace predictability and not having to ship all these .cs files is a great step!

    Thanks!
  2. Marko May 20, 2010
    I have also been torn between using Web Application Projects vs. Web Site Projects in several other occasions, too.  One argument for using Web Application Projects for SiteFinity might be the power of one-click publish feature in VS 2010 coupled with the delta-based management of web.config files and such.  It would be nice to be able to deploy customizations to Sitefinity to multiple locations (development vs. production, for example) without worrying about what your config files need to be in one vs. the other environment.  You'd still have to setup the "deltas" for the debug vs. release versions of the configuration files, but in the end, it would look something like this, when deploying to production, for example:
      1. switch the mode from "debug" to "release" in VS 2010
      2. click the publish button

    Done.

    I know that today, I have a bunch of differences in my development web.config from my production web.config (versioning, workflow, etc.), and each time I have to use a "diff" tool to compare the two to make sure I don't forget to move an important config setting.

    There might be a way to use these powerful new VS2010 features with Web Site Projects, too, but it was my understanding that they really shine with more traditional VS "projects."   Could be wrong on that.
  3. Chris May 20, 2010
    I've been using web application projects with Sitefinity since version 3.5, and very much appreciate the publishing process and the fact that there are no source code files on my web server (amongst other advantages). The fact that Sitefinity 4.0 supports web apps by default will make my life just that little bit easier each time there is an update or I start a new website.

    Thanks!
  4. James R. May 21, 2010
    Finally!! no more converting projects back to web apps
  5. Hardy May 24, 2010

    Thanks for the article, Gabe. I disliked web application projects from the start in ASP.NET 1.0 for the same reasons you mentioned. When ASP.NET 2.0 introduced web site projects I was very relieved and have not used a single application project ever since. I have made it a strict requirement though to not use the app_code directory at all but always keep c# files in a separate library project. This help avoid namespace-related difficulties and has served me well over the years. 

    I have to admit I was a little worried at first when I read the title of this post (thinking that Sitefinity would abandon web site projects altogether) but I'm happy to hear that Sitefinity 4.0 will offer both options in the future.

    Thank you.

  6. Hardy May 24, 2010

    Thanks for the article, Gabe. I disliked web application projects from the start in ASP.NET 1.0 for the same reasons you mentioned. When ASP.NET 2.0 introduced web site projects I was very relieved and have not used a single application project ever since. I have made it a strict requirement though to not use the app_code directory at all but always keep c# files in a separate library project. This help avoid namespace-related difficulties and has served me well over the years. 

    I have to admit I was a little worried at first when I read the title of this post (thinking that Sitefinity would abandon web site projects altogether) but I'm happy to hear that Sitefinity 4.0 will offer both options in the future.

    Thank you.

  7. Rick McNorgan Jul 13, 2010
    I use a virtual path provider to contain ASCX and ASPX templates in a DLL. When validating a Web Site project, Visual Studio chokes if it encounters an @Register directive referring to a user control that is not physically on the disk.

    I don't have this issue with a Web Application project.

    So, I'm also happy to hear that you will officially supporting the Web Application model.

    Leave a comment