Web Application Projects and Web Deployment Projects are here

May 22, 2006 @ 8:55 am

[1/4/07 - please note: Web Application Projects is now part of Visual Studio 2005 SP1. Web Deployment Project is still a separate download]

Microsoft has just put out Version 1.0 of Web Application Projects which is a much needed add-in for Visual

Studio 2005. This add-in project type addresses a number of issues related to page compilation, project creation and management as well as deployment in ASP.NET 2.0 and Visual Studio 2005 by providing a project model that resembles more closely to VS2003 projects. If you've had any kind of issues with project management, compilation or deployment you should definitely check out this new add-in that brings back an old but proven concept.

Web Application Projects come in response to some fairly noisy criticism of the stock project model shipped with Visual Studio 2005. Many developers in the community ran into quirky behavior due to the complex new compilation model. Ironically the new stock compilation model was supposed to make it easy to create and work with Web applications, and while it does make many things easier most of the time, the few things it doesn't do well can be major stumbling blocks.

Deployment is also affected by the compilation and project model and many developers ended up downright baffled by the messy deployment output generated by stock projects. The output contains a ton of randomly named files and cannot create a repeatable installation unless doing an in-place install including source files.

In addition, there are project management issues because stock projects aren't real Visual Studio projects and some features that have always been available to projects like Build Actions, XML Documentation and MS Build support, are simply not available.

Microsoft responds quickly

Microsoft took the issues raised quite seriously early on and got down to build a couple of powerful project template add-ins that addressed just about all of the concerns. Unfortunately these tools didn't make it into the shipping product of Visual Studio 2005 and the tools ended up getting released as add-ins that can be downloaded. The initial tool released was Web Deployment Projects (http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/) which addresses the deployment process by combing the jumble of files that the ASP.NET 2.0 compiler (ASPNET_COMPILER.EXE) creates, into a single assembly, along with the ability to create repeatable installs. Shortly thereafter a second tool called Web Application Projects (http://msdn.microsoft.com/asp.net/reference/infrastructure/wap/) was introduced which essentially brings back a full project model similar to VS2003, but with significant enhancements. Both tools were recently put out as V1.0 releases and both will be integrated into future refreshes and updates of Visual Studio starting with SP1 later this year according to Microsoft. Neither of the products works with Visual Web Developer.

Stock ASP.NET 2.0 Projects - The good and the bad

You may be wondering what all the fuss is about. Stock ASP.NET 2.0 projects may work well for you and if they are, there's no reason to switch or add any tools. I would argue no matter what you do deployment (short of in-place installation with source code) can use the help of Web Deployment projects, but Web Application Projects is something that you need to worry about only you've hit some of the snags of stock projects or you simply like the more standard approach that it offers to project management.

Stock ASP.NET 2.0 projects are nice in a lot of ways. One of the highlights of the new stock model is the ability to use file based projects which require no configuration to open a project. You simply point Visual Studio at a physical directory and open it up. Right click on a page, View and Browser and the built in Web Server starts up and you're running the Web Application. Look Ma, no hands!

Along the same lines is the ability to make changes to the code of a page, save the page and run it in the browser without having to recompile it. I know, I know – No Compilation? Blasphemy! But I have to admit I got quite used to not compiling my stock projects but simply running pages after changes. This scenario is even nicer if you have the debugger attached to your Web application. You can now make changes to your code while the debugger is attached, refresh the page and see the refreshed code in the debugger. No stopping the debugger, no restarting of the app, this can be a huge timesaver.

The final improvement in the compilation model comes if you are using CodeBeside pages – the new partial class model eliminates all of the control definition from the source code of your classes and instead generates them at runtime. There's no code clutter of control and event definitions as there was in ASP.NET 1.1 CodeBehind pages in InitializeComponent, and no longer are there issues with Visual Studio mucking up the control definitions or event hooks because that task has been offloaded for ASP.NET at compile time.

All of this is easy and makes getting started with ASP.NET 2.0 easier than what you had to go through with ASP.NET 1.1. It's surely the main reason why Microsoft went through the trouble of cooking up a whole new compilation model to make ASP.NET more approachable.

Stock Projects: A few problems

When I first started using 2.0 Web Projects I was pretty excited. Indeed it did seem much easier to work in 2.0. Especially the Edit and Go functionality and the ability to simply open a project seemed nice especially as I was checking out a lot of sample projects at the time. I started with 2.0 early in the beta and like most people who used these early versions of the time I was just trying to understand the many changes by creating small samples and pages. And ASP.NET 2.0 and the stock project model worked awesome for that. I never really got around to a final compilation of my samples for deployment, and most if not all of my work was with single pages that didn’t have external dependencies or complex page class hierarchies. Life seemed good…

Fast forward to the final betas. By now I was getting more familiar with ASP.NET 2.0 and decided to port one of my more complex applications to 2.0. First thing I found that the migration didn't go very smooth – the migration tool missed many of the pages that were inherited off custom Page classes or Pages that referenced CodeBehind classes of other pages. At this point some of the difference between the CodeBehind and CodeBeside model became clear and it took quite a bit of time and experimentation to understand just what you can and can no longer do when dealing with Page inheritance. And where you need to put files. Can I leave it in my Web directory or do I have to put it in APP_CODE? Will ASP.NET generate my controls or not?

Most of these issues during conversion had to do with ASPX pages that use inherited page classes. I have a number of pages that use a CodeBehind class that serves a number ASPX pages. This is not easily done in 2.0, unless you create your own control definitions at the base class level (ie. a fair amount of manual work) or resort to using FindControl() in the base class. It took a lot of trial and error to figure out exactly what you can and can't do with page inheritance – things that worked just fine and logically in the previous version of ASP.NET. The process is not easy and although I now have a pretty good understanding of how the page model works, I think it's horribly confusing and riddled with inconsitencies and workaround implementation details that developers should not have to deal with. CodeBehindBaseClass anyone?

At the time I figured, I'm upgrading and I didn't do things the ASP.NET 2.0 way that I would if I were starting from scratch today. But unfortunately as I went on with development of new projects I ran into these same quirks over and over again. In most cases I was able to work around the issues, but because of the complexity of the model it's a major time drain working around them. Ever try to create two master pages and inherit one of them from the CodeBehind class of the first? It can be done but it's not very obvious. Need to load a user control dynamically and can't have a @Register tag on the page? Doing simple things like this shouldn't require any special directives or resorting to Reflection or FindControl() semantics to get a proper reference to a type. The model of ASP.NET 1.1 was simple and elegant and inheritance worked the way you expect it to, whereas the 2.0 model seems too clever and full of workaround hacks and directives to force things to work a certain way. If you are doing cross page/control referencing I bet you have run into these issues and wasted a fair amount of time working trying to find the right combination of directives and inheritance to make it work. It shouldn't be this hard!

The next real shock was deployment. When I finally got around to deploying to a staging site, I was stunned of the choices that had to be made. Should I precompile? Should I include the ASPX files in the pre-compilation? Should use fixed names or force assemblies to created for each directory? And the deployment tools built into VS.NET 2005 are pretty lame as they don't even give access to all the options available on the ASP.NET compiler. If you want all the choices you have to use the command line compiler and figure out one of the 20 or so compilation combinations you can come up with through the various options. In fact, I got so frustrated with the options I ended up building a front end GUI tool for the ASPNET_COMPILER.EXE (http://www.west-wind.com/tools/aspnetcompiler.asp) which let me experiment a little more easily with the options.

It took me a couple days of experimentation and reflection on the concepts to find a model that I could work with and manage my site reasonably efficiently. Reasonably… the process was far from optimal and involved deleting all existing files in the BIN directory (50 files just for the Web app plus the satellite assemblies) then recopying all of those files into the BIN directory. The worst part though, was that the install was not repeatable – every build created a different set of deployment files with unique names in the BIN directory. The only way to manage deployment was to delete all the files and copy them back up even if I had only a single tiny little change.

Updating your site in real-time is also a problem because of this model. There are many binary files that need to get updated and while in process the site becomes unstable and results in errors on a live site with the update in progress. ASP.NET 2.0's workaround solution: Use a placeholder file while the update is in progress – Riiiight.

I gnashed my teeth and told myself, "I can live with that. After all I don't deploy that often." But after going through these steps with a few minor updates, finding a small bug with the update and then having to go through this process again, let me tell you this process became more than a little annoying and a considerable time sink.

Long story short, over time I've gotten very discouraged with stock Web projects for real project work. I still prefer stock projects for samples and simple projects, but for anything critical I've moved on to Web Application Projects.

Luckily Microsoft heard these and other serious complaints (no build actions, source control limitations) from other developers and responded with Web Deployment Projects and Web Applications Projects.

Web Deployment Projects

To address the deployment issues Microsoft shipped a pre-release version of the Web Deployment Projects (WDP) add-in almost simultaneously with the release of Visual Studio 2005. Since then Web Deployment Projects has been released as Version 1.0. WDP addresses only compilation issues and it works in combination with stock projects. It can also be used with Web Application Projects to provide for pre-compilation of ASPX pages in those projects (more on this later).

WDP gets added to an existing solution that includes a Web project. You add a new Web Deployment project and this new projects manages the publishing of your project to a specific directory in a similar way that the Publish feature does, but provides a number of useful enhancements and features. WDP still uses the same compilation that ASP.NET 2.0 uses natively and then post-processes the output generated by the stock compiler.

The key feature of the tool is that it can create a single assembly of the mess of files that stock project creates. It still doesn't create just a single file – there are still .compiled marker files for each page if you chose to precompile the ASPX pages as well.

But unlike stock projects all the files generated use ffxed hash values for file names, so the installs generated are fully repeatable. For example, if you compile to a single assembly the single assembly will be the same name, and each of the .compiled files for the ASPX pages will have the same name as the previous build.

This means, now when you deploy, you can in most cases update the single assembly and leave the other files alone. You'd only need to update the .compiled files if you add new files to the project. So if there should a be minor fix after a deploy to the live site, you can now update a single file.

A single assembly also means that you are updating a single binary file on the server, which is makes it possible again to do an in place update of the application without shutting down the server and without seeing error messages while the assembly is being updated. No more out of sync assemblies on the server in many cases.

Because WDP is a real Visual Studio project it is a straight MSBUILD file and can be triggered for automated builds which was one additional complaint with stock projects. There are also a number of useful features in WDP which allow you replace sections in Web.Config with content from external files. This lets you change your config settings for deployment which are almost surely going to be different from what they are in your development environment. You can also assign version information to the assembly created - previously the best you could do is store a AssemblyInfo.cs file into your APP_CODE folder which would give a version to the generated APP_CODE assembly only.

If you plan on using stock projects with ASP.NET and you plan to deploy a pre-compiled Web site, I highly recommend you combine it with Web Deployment projects to create workable installs.

Web Application Projects

To address the main logistical issues with stock projects mentioned above, Microsoft has provided Web Application Projects (WAP). WAP basically takes us back to the compilation model that Visual Studio 2003 used with some important enhancements and full support of all the ASP.NET 2.0 features. WAP brings back the CodeBehind compilation model, where all CodeBehind code gets compiled by Visual Studio into a single assembly in the BIN directory. When you build your projects you get a fully compiled, single assembly and an in-place installation that is fully self-contained.

WAP is provided as a Visual Studio Project project template. To create a new project you Create a new Web Application Project which creates a familiar .csproj or .vbproj file. Unlike VS2003 though, the new project doesn't use FrontPage extensions, but rather accesses the files directly from disk, so it's much faster. The project is a full Visual Studio style project with all the features you'd expect from a project like XmlComments, versioning, compiler switches, build actions etc. As any VS.NET project it's also an MSBUILD script so you can customize as needed with all the functionality MSBUILD allows.

If you already have a stock ASP.NET 2.0 project you can use the 'Convert to Web Application' option to automatically convert the project for you. The converter runs through your project and fixes up each of the ASPX/ASCX/MASTER pages updates the CodeFile tags to CodeBehind and adds the new .designer file with the control definitions. I ran into a few issues with control assemblies in the BIN directory not being found. It might be a very good idea to compile your existing project under stock projects just before doing a conversion to ensure all the required dependencies exist in the BIN directory.

WAP works like VS2003 projects in that it uses the project file to manage the files that it can see, so rather than simply looking on disk and blindly pulling everything in the directory into the project, WAP only holds what you add to the project. So any files you want in the project, need to be added even if they exist on disk. You can also exclude files to remove them – another feature you couldn't do with stock projects.

The key WAP feature in regards to compilation is that it moves the step of control code generation of the ASP.NET page process back into the designer – WAP controls and pages are made up of three files that make up each ASPX/ASCX/MASTER page (C# files shown here):

The aspx/ascx/master markup file
The .aspx.cs file that contains your CodeBehind code
The .aspx.cs.designer file that contains the Control definition

If you've worked with WinForms 2.0, you're already familiar with this model where your code goes into one file (the plain .cs file) and the designer generated code goes in the other (.cs.designer). The generated code consists merely of the control definitions for the page which gives the base class the proper signature. This is an important shift because with this mechanism the class name is known at original compile time and the class is available in the current, single assembly of all CodeBehind code, so Page and Control classes can be easily referenced across the application.

Visual Studio now compiles these two classes together into the base class. The result of this is that the code generation for the control definitions is no longer delayed until runtime and ASP.NET doesn't need to generate a unique classname for the base class. In fact this class compiles into a single assembly for all CodeBehind classes. Any page class can access any page or control or master class by its CodeBehind type as you'd expect because the type now exists at initial compile time.

This simple change solves the problem of cross page referencing of controls and pages, the various inheritance related quirks, and it also makes for a much more speedy compilation process. Compiles of a moderately project with 50+ pages takes about one second with WAP vs. 20-25 seconds with stock projects. If you compile a stock project the process is excruciatingly slow, because ASP.NET actually compiles the entire project including the ASPX files and copies it out to a deployment folder. With WAP a compile only compiles the CodeBehind code – there's no ASPX parsing and the compilation is inplace and results in a single assembly that is placed in the BIN directory.

Web Application Projects also supports Edit and Continue, which was a feature squeezed in at the very last minute. Edit and Continue gives you some semblance of the Debug and Go functionality of stock projects. Truthfully though, I'm not a big fan of Edit and Continue; the fact that all but the active source file are locked and inaccessible for editing really is more hassle to me than it's worth. But if you're already using Edit and Continue in WinForms or library projects, you can expect similar behavior with Web applications now. Again, consistency is a virtue.

Web Application Projects and Web Deployment Projects in Combination

On the downside, WAP requires compilation of any change made, so you can't simple execute pages after a change. You can get familiar once again Ctrl-Shift-B to build your project. Fortunately the compile is fast.

You can no longer get error detection inside of ASPX pages with WAP alone as the compiler only compiles your CodeBehind classes and not the markup code, so errors there don't show up in the Error display. However, if you still want this useful feature, you can use WAP in combination with Web Deployment Projects and precompile your markup pages. WDP compiles the markup pages and can also flag the errors in its compilation error display. This compile is slower like stock projects, but it's a great tool to run at least from time to time and ensure that your expression markup is valid in markup pages.

Web Application Projects are for me

I've spent a fair amount of time now both with stock projects and Web Application Projects and I can tell you that I feel much more comfortable and productive with WAP, than with stock projects. Everything just works as you would expect and I've not run into any issues of things that don't work. It's a predictable and proven model that is based on standard .NET principles that anyone who can look at the output generated can understand easily.

If you are building reasonably complex projects I think you too will find that this model is a better fit for the way most developers work, even though the model is more rigid. Most importantly it's consistent with the rest of Visual Studio, and not an oddball project type and an oddball compilation model with many intricate clever tricks to make it work.

There are doubtlessly some of you who are happy with stock projects too, and if they are working for you, and, unlike me, you are not running into the boundary cases I mention above, by all means stick with stock projects. They are less rigid to work with and the projects are more portable. If I build any sort of demo application or samples, it surely will be done using stock projects.

The good news is that should you run into a problem with stock projects that you can't solve you can now easily switch to WAP if necessary. The conversion isn't completely automatic, but it can be done fairly quickly. Even with some of the compiler issues I had in my conversion I ended up doing the 50+page project in about an hour.

It is also possible to go back to stock projects although this is a manual process (you can find out more here: http://west-wind.com/weblog/posts/5571.aspx) although I suspect there will be little need to go this direction.

Community Driven

Finally I think that Microsoft did a bang up job getting these tools out to solve the problems with stock projects as they became apparent. Both of WAP and WDP were very publicly discussed and Microsoft listened very carefully to community input during the development cycle. Many features were added after the intial releases came out and public community input was made available. Each new release during the preview cycle brought out many of these new changes very quickly. It's good to see this kind of flexibility at Microsoft after dealing with the slow as molasses monster releases of Visual Studio .NET during the betas.

It would have been even better if these tools had made it in the box, but given the timeframe of release that wasn't possible. As it stands these tools will become part of Visual Studio 2005 SP1 later this year and future releases.

Note though that neither of these tools work with Visual Web Developer currently, and I don't believe there are any plans to integrate them into updates in the future either. VWD developers will be stuck with stock projects which is probably OK given the scope of VWD.

Feedback for this Weblog Entry

# re: Web Application Projects and Web Deployment Projects are here
by David M. Kean May 23, 2006 @ 3:35 pm

Aren't the following two sentences a contradiction?

'When I finally got around to deploying to a staging site, I was stunned of the choices that had to be made.'

'And the deployment tools built into VS.NET 2005 are pretty lame as they don't even give access to all the options available on the ASP.NET compiler.'

# re: Web Application Projects and Web Deployment Projects are here
by Rick Strahl May 23, 2006 @ 3:41 pm

No, not really... the VS option doesn't give access to all the switches available on the command line, and worse they're not the options that I would end up using...

# Problems with WAP when building on a machine without VS.Net
by collin May 25, 2006 @ 12:41 pm

I too prefer the WAP project, yet one issue we are running into are build errors when building the project on a server that doesn't have VS.net.

We use cruise control along with msbuild to build our web apps onto a staging server and we now get errors complaining about
"Microsoft.WebApplications.targets not found".

I've tried downloading the the WAP plugin onto the server, and it complains that VS.net is not installed. I guess we'll have to install it or try copying the WAP folder from my development machine to the server so the build can find the import reference.

# re: Web Application Projects and Web Deployment Projects are here
by Matt May 27, 2006 @ 9:15 am

Great post Rick. With regards to "Web Application Projects and Web Deployment Projects in Combination" I can't see the option to add a WDP to a WAP in the same way I would do with the stock ASP.NET Websites. Could you possibly throw any light on this?

# re: Web Application Projects and Web Deployment Projects are here
by Rick Strahl May 27, 2006 @ 1:06 pm

Matt, I see it in my WAP project on the project menu. Make sure you 1.0 installed.

You should also be able to add it to the solution using the standard mechanism to add a new project.

Collin - I wonder if you can install the .target files manually somehow. I had to install .target files the other day for Script# and that's a manual process, so that might work for getting MSBuild to find the necessary target information.

# re: Web Application Projects and Web Deployment Projects are here
by Matt May 29, 2006 @ 10:45 am

Odd, I do not see those options. I already had WDP installed before installing the WAP and its prerequisite from http://msdn.microsoft.com/asp.net/reference/infrastructure/wap/default.aspx. Perhaps it has something to do with the install-order.

# re: Web Application Projects and Web Deployment Projects are here
by Mike W. May 29, 2006 @ 1:02 pm

Rick,

You're my hero. I spent over 5 hours today trying to manhandle my code when it refused to dynamically load a class out of a precompiled assembly. Had it working less than an hour after I found this post. Ironic isn't it, that the new "easy" compilation is much worse than the old way? :)

# re: Web Application Projects and Web Deployment Projects are here
by Rick Strahl May 29, 2006 @ 2:19 pm

Mike, been there done that <g>... Enough is enough, although with one of my projects (which I'm working on now) I'm stuck with stock projects.

# re: Web Application Projects and Web Deployment Projects are here
by Kim June 02, 2006 @ 5:09 pm

I'm looking for a way to explicitly specify the files included in a build, and build all components into a single dll or at least a build with fully repeatable filenames. And I would like to stay with the new code model where there is no need for control and event definitions in the code. I think that I'm most of the way there with stock projects and WDP, but is there a way to specify the files included in a WDP project or does it always build all files in the directory?

Is "Convert to Web Application" broken? For example, if I use File > New > Web Site... to create a "stock" project, "Convert to Web Application" is not available anywhere. If I use File > New > Project to create an "ASP.NET Web Application" (this type of project is only available after installing the Web Application add-on), "Convert to Web Application" is available for this type of project, however, it does absolutely nothing since the project is already a Web Application (and already uses the old CodeBehind, etc.)

Thanks for a very informative blog!

# re: Web Application Projects and Web Deployment Projects are here
by Rick Strahl June 25, 2006 @ 2:18 am

Kim,

As it turns out Convert to Web Application is not available in a stock project. The steps to convert are to create a new WAP project and then copy the files of the old project over into this new project. You can then use Convert To Web Application to make the conversion.

Scott Guthrie has an article that takes you through the exact steps here:

http://webproject.scottgu.com/CSharp/Migration2/Migration2.aspx

# Tip/Trick: Creating Sub-Web Projects using the VS 2005 Web Application Project Option
by ScottGu's Blog August 16, 2006 @ 1:54 am

One scenario that many large development teams often ask me about is whether it is possible to split

# re: Web Application Projects and Web Deployment Projects are here
by Martin August 17, 2006 @ 4:03 am

... and not to mention the stock model's inability to exclude project items, it's tendency to add pdb files to source control and lack of transparency about how it is declaring controls on the page as you never get to see the designer.cs code (and sometimes VS2005 seems to declare usercontrols as "UserControl" rather than it's actual type.

# re: Web Application Projects and Web Deployment Projects are here
by Shahzad September 07, 2006 @ 8:10 am

I am unable to fine the Web Deployemnt project in the web application project even i have installed the Web application project and Web Deployment project. But option is avaiable in web site project(stock project).

# ScottGu's Blog : Tip/Trick: Optimizing ASP.NET 2.0 Web Project Build Performance with VS 2005
by ScottGu's Blog September 25, 2006 @ 12:35 am

This posts covers how to best optimize the build performance with Visual Studio 2005 when using web projects. If you are experiencing slow buildsor want to learn how to speed them up please read on. Quick Background on VS 2005 Web Site Projectand VS 2005

# how about typed Datasets
by Hakan September 28, 2006 @ 10:06 am

---

valueable info, thanks! Rick

can you say a few words about using typed (declarative) datasets and webapplication projects, I hear many people complaining about certain things not working properly

---

# TopXML : Tip/Trick: Optimizing ASP.NET 2.0 Web Project Build Performance with VS 2005, in BizTalk Orchestration
by TopXML Reblogger XML News October 01, 2006 @ 3:30 am

Tip/Trick: Optimizing ASP.NET 2.0 Web Project Build Performance with VS 2005, in BizTalk Orchestration

# re: Web Application Projects and Web Deployment Projects are here
by Rick Strahl October 04, 2006 @ 4:23 am

A more detailed article on this subject can be found here:

http://www.west-wind.com/presentations/AspNetCompilation/AspNetCompilation.asp

# From Web Application Projects to stock ASP.NET 2.0 Projects - Rick Strahl's Web Log
by Rick Strahl's Web Log October 27, 2006 @ 6:22 am

# ASP.NET Forums - Web app Deployment
by Configuration and Deployment December 05, 2006 @ 11:22 am

# ScottGu's Blog : Tip/Trick: Optimizing ASP.NET 2.0 Web Project Build Performance with VS 2005
by ScottGu's Blog January 09, 2007 @ 6:10 am

This posts covers how to best optimize the build performance with Visual Studio 2005 when using web projects. If you are experiencing slow builds or want to learn how to speed them up please read on. Quick Background on VS 2005 Web Site Project and VS

# ASP.NET Forums - To WAP or not to WAP
by VS 2005 Web Application Projects January 09, 2007 @ 6:50 am

# ASP.NET Forums - ASP.NET Website Development across Firewall
by Architecture January 22, 2007 @ 7:32 am

# ASP.NET Forums - WebSite v.s. Web application
by Migrating from Visual Studio .NET 2003 to Visual Studio 2005 February 20, 2007 @ 7:28 am

# 我的一切源于对未知的好奇: WebApplication 和 WebSiteProject 的区别
by March 05, 2007 @ 10:31 pm

我的一切源于对未知的好奇: WebApplication 和 WebSiteProject 的区别

# re: Web Application Projects and Web Deployment Projects are here
by Jon March 08, 2007 @ 6:57 pm

I just tried to install the WAP first by installing the "Update to Support Web Application Projects" but it tells me I must install the "Update to Support Web Application Projects" even though I just did and it told me it was successfully installed. I must have a gremlin somewhere.

# re: Web Application Projects and Web Deployment Projects are here
by Rick Strahl March 08, 2007 @ 7:09 pm

WAP is no longer needed. Install Visual Studio 2005 SP1 and it includes Web Application Projects.

# re: Web Application Projects and Web Deployment Projects are here
by Jon March 09, 2007 @ 10:58 am

Thanks Rick,

I found that after the fact. I have SP1 installed and did find the WAP. I just hope I didn't mess up SP1 by instaling the "Update to Support Web Application Projects".

There's so much information to be aware of, sometimes it feels like, trying to sit down for dinner and eating an elephant.

# re: Web Application Projects and Web Deployment Projects are here
by Matt Brooks March 12, 2007 @ 12:44 pm

Rick,

Reading the latest edition of MSDN Mag prompted me to visit a problem that I encountered some months ago. In short I do not get the 'Add Web Deployment Project' option for any Web Application Project. I never have done, neither before nor after installed VS2005 SP1. In fact, neither do any of my co-workers!

I'm wondering if this is a common problem or perhaps one that only affects certain versions of Visual Studio 2005 (e.g. Professional Edition - ENU).

When I asked about this some time ago no one had experienced the problem except me, so I didn't pursue it further. As it happens the Web Application Project model suits my preferences and the default compilation (single assembly, updatable) is how we choose to deploy all of our applications to our production servers.

However, now I would like to develop some reusable user controls for my team but also make use of the Web Application project compilation model. At the moment I have no support within the IDE for this.

Any help, references or referals would be greatly appreciated!

Regards,
Matt

PS: I'm posting this comment on a number of blogs.

# re: Web Application Projects and Web Deployment Projects are here
by BillA March 28, 2007 @ 4:47 am

From all I can see, WAP development can only be done on a local machine. Is this true?

# Web Application Projects and Web Deployment Projects
by Michael G Walmsley April 22, 2007 @ 11:57 pm

Rick

Thanks for that article. It gave me some good knowledge.

However, ive a problem that lead me to find this blog.

I have a web application project that produces an assembly called DSD.PRS.Web.dll (the assembly name in the web project file).

My web deployment project also produces an assembly. If this is the same as above of course the aspnet merge fails.

So ive given the deployment projects output a different name, eg, DSD.PRS.WebApp.

Now i have two assemblies with different bits of the app in them. Some are even repeated, eg, a class in the app_code folder is in both assemblies.

This sof course does not happen if the new web projects is used as one does not need to specify an assembly name for the web project, just the deployment project.

What is the best way to handle this?

Regards
Michael

# re: Web Application Projects and Web Deployment Projects are here
by Rick Strahl April 23, 2007 @ 12:06 am

A Web Application project produces basically a regular assembly so all the rules of regular CLR assemblies apply.

I think you need to use namespaces to properly separate your class names, or think of other ways how to store common classes in separate assemblies...

# Web Application Projects and Web Deployment Projects
by Michael G Walmsley April 23, 2007 @ 5:00 pm

Rick

I think you misunderstood me. The application does use namspaces correctly.

The problem is that the web app project produces an assembly that contains the app_code, controls, pages etc. And then the web deployment project does mostly the same.

Regards
Michael

# re: Web Application Projects and Web Deployment Projects are here
by Rick Strahl April 23, 2007 @ 5:26 pm

Michael, Web Application Projects should not have an APP_CODE directory. If you do, you should rename that directory. The reason is that ASP.NET will ALWAYS compile all code in APP_CODE at runtime and you're basically telling it to compile it into a seperate assembly and then again into the APP_CODE assembly.

# 技巧和诀窍；在VS 2005里优化ASP.NET 2.0Web项目的Build性能 - 不再犹豫 - 博客园
by May 21, 2007 @ 11:37 pm

# Web app Deployment - ASP.NET Forums
by ASP.NET Forums May 25, 2007 @ 6:51 am

re: Web Application Projects and Web Deployment Projects are here
by Andreas Symeonides May 30, 2007 @ 6:52 am

Rick,

Thanks a lot for this nicely written article. It helped me a lot as it covers well the current deployment issues and options, and that's exactly what I need now.

By the way, I am also using your wwBinder control (had to make some small modifications to get it to work for me such as localization). Thanks for that as well. I was wondering whether you are still maintaining that, and whether it is publicly available.

Andreas

re: Web Application Projects and Web Deployment Projects are here
by Rick Strahl May 30, 2007 @ 10:22 am

The databinding article was updated for ASP.NET 2.0 and published in MSDN some time ago:

http://msdn.microsoft.com/msdnmag/issues/06/12/ExtendASPNET/default.aspx

# To WAP or not to WAP - ASP.NET Forums
by ASP.NET Forums June 06, 2007 @ 6:53 am

# 58bits - Tech - Web Deployment Projects, Web Application Projects and aspnet_merge.exe
by 58bits - Tech June 11, 2007 @ 2:11 am

Six bits short of sixty four...

# ASP.NET Website Development across Firewall - ASP.NET Forums
by ASP.NET Forums June 18, 2007 @ 6:39 am

# re: Web Application Projects and Web Deployment Projects are here
by gazeteler June 30, 2007 @ 10:34 am

# ASP.NET 2.0 Project Model - Continues to be a thorn in my side - Karl Seguin [MVP]
by Karl Seguin [MVP] July 12, 2007 @ 3:28 am

TDD .NET Agile ADO.NET VB C# ASP.NET

# 技巧和诀窍；在VS 2005里优化ASP.NET 2.0Web项目的Build性能
by Scott Guthrie 博客中文版 July 15, 2007 @ 10:20 pm

# Debug and Release dropDown list - ASP.NET Forums
by ASP.NET Forums July 20, 2007 @ 6:33 am

re: Web Application Projects and Web Deployment Projects are here
by Behnam Divsalar August 03, 2007 @ 4:24 am

Hi
I have problem on installing the WEbDeployment project. When I run .msi file, it asks me to install the VS changes first and when I d that and run .msi again, still it askes me to install the VS updates. I did this three time and I cannot install deployment installation

I wondered it's because I installed the SP1 before and it doesn't let me to install deployment.

I have WindowsServer2003 in my machine.

Please can you help me??

Regrads

Behnam

You can reply me on my email also please because I might not find this blog again: email: divsalar@hotmail.com

re: Web Application Projects and Web Deployment Projects are here
by Alex December 02, 2008 @ 1:19 pm

Hi Rick, I apologize for such a an outdated comment but I can't find anything more relevant in regards to WAP & WDP then this post of yours. So first, do you use WAP & WDP in VS2008 SP1? If no don't bother to read further on. We have recently stepped on this problem: we've been using WebSite project with WDP in VS2008 SP1 for quite a while and quite successfully. Recently we've switched our WebSite project to WAP because we wanted to have a versioned assmbly for the web site and suddenly WDP stopped working for us: there are no errors when it works and it produces a precompiled web site all right but the site does not function properly. In particular all the aspx pages located in the root of the web site render empty content. Empty meanin absolutely empty: response size is 0 bytes. If precompilation is turned off they work. There are no obvioud problems with the code (no exceptions, etc.) or any other logical explanations of such behavior. Would you by any chance have any clues on that? Thanks in advance.

re: Web Application Projects and Web Deployment Projects are here
by Rick Strahl December 02, 2008 @ 1:46 pm

I haven't dealt with WDP in a while so i can't comment for sure but I think you just need to use the right command line switches for WDP. Specifically not to precompile the ASPX pages (although that should still work).

Frankly when using WAP I don't see a whole lot of reason to precompile. You have your assembly with all your code behind, so all that isn't pre-compiled is the actual ASPX markup. And you're just easier of deploying those files raw anyway.