First Preview Download of VS 2005 Web Application Project Model Now Available

 May 8th Update: The final release of the VS 2005 Web Application Project is now live.  You can learn more about it here

I wrote last week about a new web project model option we are going to make available for VS 2005 (you can read the original post here).  We are calling this option the “ASP.NET Web Application” project model (VS 2005 also has the “ASP.NET Web Site” project model built-in as well).


This new “ASP.NET Web Application” project model option provides the same conceptual web project semantics as VS 2003 web projects (a project file based structure where all code in the project is compiled into a single assembly), but with all the new features of VS 2005 (refactoring, class diagrams, test development, generics, etc) and ASP.NET 2.0 (master pages, data controls, membership/login, role management, Web Parts, personalization, site navigation, themes, etc, etc).  This new “ASP.NET Web Application” project model also eliminates need (with VS 2003) to always use FrontPage Server Extensions and have a local copy of IIS to-do development on a local box (it now supports both the built-in Cassini web-server as well as IIS).


When building new web projects, developers will be able to choose whichever web project model (Web Site Projects or Web Application Projects) works best for their workflow and scenarios.  Some developers love the new dynamic web project model, some hate it and want the old approach back – the good news is that you now get a choice to pick whichever works best for you, your style of development, and your existing code-base (note: yes, we made a mistake in not providing this choice in the first place).  This new project model option will also make it much easier to migrate large/complex existing applications to VS 2005 without requiring significant effort (since it has the same code semantics as VS 2003 today).


About Today’s Preview Release


We are making a preview release of the VS 2005 Web Application Project support available today for anyone to download.  The download itself is .5Mb in size and does not change or modify any existing VS 2005 binaries (instead it is built using the public extensibility APIs).


This preview is not a feature-complete version of the functionality.  There are several important features that are not yet implemented, as well as a set of bugs that are currently active (note: these are documented in the known issues link on the site I’ll reference below). 


Our goal with putting this first release out is to get early feedback from the community, as well as to provide a core feature-set that enables some developers to start using this project model option immediately (with workarounds for the missing functionality which will come online in later refreshes). 


We are then going to release refreshes of the preview download early next year as we complete the feature-set.


I’ve put up a simple web-site that provides more information about the new project model option, as well as links on how to download and install.  The link to this site and download information is here:


To learn more about how the new project model option works, you can walk-through the tutorials I’ve built on the site (these include step-by-step screen-shots that you can use to follow along with the preview build).  Here is a pointer to the C# tutorials which are live now.  I’ll be posting the VB tutorials a little later this weekend.  I’ll also be building a migration tutorial with steps on how to update VS 2003 web projects to use this new project model in VS 2005 in the next few days.


Update: Both the C# and VB Tutorials are live now.  As are the migration tutorials.


Hope this helps,





  • Hi Scott, thanks for the grate news. I have two questions so far :

    1- Is "Build Page" feature supported in this project model?

    2-If i edit any single page's codebehind after clean compile and hit that page, will it restart appdomain or just compile that page ?


  • Hi Habib,

    Build Page isn't supported in this project model -- since all code gets compiled into a single assembly in this world (Build Page works in Web Site projects because each page can optionally be compiled into a separate assembly).

    The Web Application compilation process only compiles the code-behind classes, though, so ctrl-shift-b operations (which build the solution) are very fast.

    If you make code-changes and do a re-compile/re-launch of your project (which is the default behavior of a F5 or Ctrl-F5 action), then it will restart the app-domain. Note that we do not tear down the process after detaching from the worker process, though, so there is not a requirement to restart that on each F5 (previous versions of VS did that -- which meant slower F5 perf).

    These two aspects you asked about are two nice features of the Web Site model -- so if you really want these features you might be best served by using that approach for your projects.

    Hope this helps,


  • Hi Scott,

    I am really miss the project model of vs2003, and therefore, I am looking forward to this new project option in VS2005.

    I am a bit confused about how this will work with the Web Deployment Projects option. Should I put my time into investigating this Web Application Project model, will it include the functionality of the Web Deployment Projects? Should I still investigate Web Deployment projects?

    Thanks for all your efforts on the VS2005 project models!

  • Hello Scott

    I am very happy to see the positive (and fast) response from the ASP.NET team in terms of providing the community with the 2003 single-assembly model.

    Although I agree that the multiple-assembly model is great, the previous one is definately going to make our work much easier, as we have great succes in referencing standard ASPX / ASCX components using virtual directories from client websites (i.e. references to web projects from the client projects are necessary).

    Thanks for doing this - it's really appreciated!

    With regards

    Borum.NET / ProActive Denmark

  • One could be cool Scott, but maybe I am jusst a dreamer :-), would be to have a way to switch to the new model. So then people like me would be able to migrate their current applications, and then when we're ready choosing to jump to the new model to use the Build a Page compilation scheme.

    What do you think?

  • Hi Paschal,

    Yep -- we are going to make it easy to switch between the two models. The code-behind models files between the two are identical -- the only syntactical differences are that the web application model has a "codebehind" attribute in the page directive, where the web site model has a "codefile" attribute.

    The conceptual differences are then whether all of the pages are compiled together or not, and whether a project file is used to define the project contents (or whether the directory structure implies it).

    Hope this helps,


  • Does it only work with VS 2005 or can it be used with Visual Web Developer 2005 Express Edition too?

  • Hi David,

    The Web Application Project model works with VS 2005 Standard Edition and higher (and not with the express edition).

    Hope this helps,


  • Scott,

    Ok, I'm not sure where the offical place for feedback on this new project is, so I will provide some here.

    I don't see why you need to change some of the compile/build semantics. I think you could make this even closer to the web-site model but still provide some of the advantages.

    For example, consider this a web site model with a project file. The dev time model could work the same as the web site. The main difference...

    Instead of an app_code folder you could have a Build Type (or other properties) of shared so at dev time the system would know to compile these. This would still allow for the compile-page semantics. The shared stuff would only need to be recompiled if it changed. Also, this would allow for the web site style edit and execute without having to build that monolytic dll. Actually, this could be the default for "debug" builds. But, for release builds it would build all into a single dll.

    The bottom line would be everything would work like a web site but instead of considering all the files in the folder as the "site" it would consider all the files in the project. Also, references could go in the project rather than the config.

    Does this make sense? I'm not sure why this couldn't be done technically.


    Now as it is described I am concerned about the design time maintenence of the .designer files. To me there is still to much of a chance of these getting messed up.

    Would it make more sense to only generate these at build time, or perhaps still at run time as happens with a web site project?

    I am concerned about source control of these files and dev's manually editing them, or perhaps changing the name of a control, etc. It takes away the abilty to edit the ASPX page using Notepad as we might do on a server. With the web site model if I change a control name in the ASPX page, only it works... with this model it sounds like it will break things.


  • Are custom build providers working with this drop?

  • I would like to know something about 2005.

    In 2003 you could NOT pass security from one web project to another. It was simply not possible. So you could not separate your applications into multiple web projects and navigate from one to another without a work around to pass security.

    Is this possible in 2005 web applications or web sites. I have 2 solutions. A user logs into the website which is in essence solution 1. The he can click on a link which navigates him to another page on the site but is actually a different solution and the session is lost.

    I am not sure which method I like more. I guess it all depends on how flexible security is handled.

  • Hi Fabrice,

    Custom build providers will continue to work like they do at runtime and for pages not built as part of the project assembly. Their output won't be referenced by the project assembly though -- for this you'll want to build a build extension provider that will integrate with the project (we will make sure to publish how to build one of these in the near future -- it shouldn't be hard to take your existing build provider and plug it in this way).

    Hope this helps,


  • "for this you'll want to build a build extension provider that will integrate with the project"

    I'm really curious to know how this can be done. Would you have a hint?

    I may just wait until you publish a complete how-to, but I would like to support this new model ASAP.

  • Hi Scott,

    Just tried converting over web project using your instructions.

    It worked prefectly. We use Wilson Master pages, blowely compression, active reports and other third party components.

    This has saved me a ton of time, as I've already tried before converting before and could not get it going.

    I've now got the chance to move all our projects to 2005 and take advantage of the new features as I get a handle on them.

    Thank you Scott and thanks to the hard workers on the ASP.Net team.

  • Hi Fabrice,

    Unfortunately the three people I know who could easily build a sample for you are currently on vacation (doh). But if you send me mail directly I can start a mail thread with you and them.

    Hope this helps,


  • Hi scott,

    good to see this new option which enables to work on the project same way as before.but i still had a query.i already upgraded my project to vs2005 and was using the web deployement plug-in released by you people to get the single dll for the if i want to directly use this feature instead of using the deployment plugin how exactly should i proceed ,am a bit confused?

  • Hi Srinivas,

    If you've upgraded and are happy with your current web-site, then I'd recommend just sticking with that option. This new download is primarily aimed at folks who either had large projects that would be hard to compete, or who preferred a stricter project model approach.

    Having said that, migrating a web-site project to a web-application project will be fairly straight forward (although I'd probably recommend waiting till the next refresh drop when it will be even easier). I'll post a tutorial on how to-do this with the next refresh.

    Hope this helps,


  • Hi Jason,

    In 2003 you could actually pass the security ID from one web project to another. As long as they are apps running on the same domain (eg: and, or and then this is pretty easy. You just need to configure the appropriate forms-auth cookie in the forms-auth section of your app's web.config files.

    Is this what you are trying to-do, or something else? Can you provide more details on this?



  • Hi Scott,

    one of the issues of the preview is that control field references aren't automatically added to the designer code-behind class files.

    I'd like to ask you to make this optionally to be turnend off via an attribute in the page or control directive. So you can have the references already being declared in a class from which the page's or control's code-behind class might derive.



  • In answer to your questions:

    1) Yes, it's running using IIS.

    2) I'm using IIS5 on XP and I've only seen compression settings in IIS6 (so there's nothing to disable).

    3) External .js files are found. Just script that is handled by WebResource.axd is not found

    I found the problem. It's in the application's global.asax.vb file in the Sub Application_BeginRequest(ByVal sender As Object, ByVal e As EventArgs) event where we decrypt querystrings. Our code tries to decrypt the querystring in requests to get the javascript like the following:

    /webappXYZ/WebResource.axd?d=HP3pvyYCwAinmgetO0eAlQ2&t=632674127977343750 and really screws it up! (I guess we can work around this! :) )

    Thanks for your response.


  • Hi Gary,

    Yes -- this new project model option compiles everything in the project into a single assembly. This avoids the need to generate stubs at all, and allows standalone class files to reference user-controls and pages directly.

    Hope this helps,


  • Scott,

    Excellent, we were dreading the day when we have to migrate our massive web app to VS2005 later this year... but this will make it a breeze. Also fixes a lot of issue with bin folders being checked in source control. With the web app model it is clear what is included and what is excluded.

Comments have been disabled for this content.