VS 2005 Web Project System: What is it and why did we do it?

There has been a lot of online discussion lately about the new web project system that is being introduced with VS 2005.  My goal with this post is to explain a little more about what it is, and provide some background as to the features it provides and the motivation we had in introducing it.

What are Web Projects?

Web Projects are used when building ASP.NET applications inside Visual Studio 2005.  They can be used either standalone where everything within an application lives inside a single project, or together with class library, data, web-service, unit-test and/or any other project supported by Visual Studio as part of a Solution.  They fully support references and project build-ordering within a VS solution -- you set these up and manage these cross-project relationships using a .sln solution file just like you to-do today with VS 2003 (for example: you might have 3-4 class library projects that build class library assemblies that are then consumed and used by the web project).

When you are ready to “publish” a web-solution, you can use the new “Publish” option on the “Build” menu to compile and generate a deployable directory structure for a web-server.  This is logically equivalent to the user workflow steps taken with a WinForms client application project in VS2005 (except its Publish option generates a client “Click-Once” package instead of web site).  You can also automate web project build operations using the new MSBuild system (more on this later) for command-line and automated build server scenarios.

So What Are The New Features with VS 2005 Web Projects?

The new VS 2005 web project support provides a number of new feature enhancements over VS 2002 and VS 2003.  A few of the big improvements that we think developers will like:

No More FrontPage Server Extension Requirement

Unlike previous releases of Visual Studio, VS 2005 no longer requires developers to use or have FPSE (FrontPage Server Extensions) installed in order to create or build web projects.

You can now browse, create, and open local IIS applications and vdirs without FPSE on the box (instead we now have support for VS 2005 to directly use the IIS Metabase configuration store to attach and identify sites/apps/vdirs and associated physical path bindings).  You can also edit and open web projects directly off of the file-system, or access them remotely over FTP.

FPSE is still fully supported for those who want it.  But if you are in the camp that doesn’t want it (which based on feedback is 95%+ of you), your _vti_ directories will be a thing of the past.

Built-in Development Web Server (No IIS Requirement &  Debug as Normal User)

In addition to providing full support for developing and testing web projects on IIS, VS 2005 also includes a built-in development web-server that ships in the box.  This test web-server is ideal for doing development when IIS is either not installed, or your IT policy limits desktop deployment of it.

This web-server only handles local requests for security reasons (so people can’t access your application remotely while you are developing it), and it automatically shuts down when you close your web-projects.  It also supports developers debugging applications running within it while running under a non-admin “normal user” account.  Once you’ve built your application using it, you can then upgrade the web to either run under IIS locally or deploy the application to a remote server to test and verify.  There is also now a new built-in “Copy Web” wizard that can help with copying your web to a remote server (it supports FTP and FPSE as copying protocols too).

Obviously we also fully support building web projects against IIS directly (note: this is required when you are building a solution with nested vdirs and sub-applications).

More Flexible File Management and Better Cross-Tool Collaboration Support

Web projects have a few unique characteristics that often differentiate them from other types of application projects:

1) Web projects are almost always built using a variety of very-different tools in parallel.  Images are worked on using tools like Photoshop, Illustrator, and FireWorks.  CSS and .ASPX/.HTM content layout is worked on using DreamWeaver or FrontPage.  Code is worked on using VS.  A tremendous amount of integration and collaboration goes on between these different types of resources.  Sometimes the same person performs all of these tasks, typically for larger projects they are split up across multiple people working together.

One of the big complaints we hear with VS 2002/2003 is how hard it is to manage these cross-tool workflows – especially given that non-VS tools do not work with FPSE and do not integrate at all with VS project files.  For example: a designer might update a CSS file in a web project to use a new background image, and add the new image to an images directory under the web project using their image editing tool.  If the web developer using VS 2003 does not coordinate this change by updating his or her project file to remove the old image and add the new image to the project file manifest, then they will find that things work ok during development, but it will fail in production since the new image will not be copied/deployed when the web project is built to a new location.

2) Web projects are also unique in that the file layout of pages, images, CSS stylesheets, Flash SWF files and other items within a web application are directly surfaced to end-users accessing the running web app with a browser.  File-layouts are almost always hierarchical, and a great deal of attention and work is done when coming up with this organization.  The number of files and project items within a typical web site can easily climb into the hundreds or thousands of items.  One of the complaints we hear with VS 2002/2003 is how hard it is to manage this within the IDE – especially when source control is used and it is necessary to check-out and then check-in a common project file every-time a file layout is changed or a file is added/renamed/deleted.

To better support both of these scenarios, VS 2005 web projects no longer store a list of all files in a central web project manifest file.  Instead, the content and layout of the web project are directly inferred from the file-layout and file contents of the web-project folder.  Additions/deletions/movements of files and folders within the web-project do not require updating one central project file that is a single point of contention.  This means you can easily use any non-VS tool that directly works off the file-system with your web project, and that when running under source control you do not need to lock and update the project file anytime you move or make a file change.

The project layout under the Solution Explorer for web projects has also been changed to show a file-system view of the web project.  This ensures that developers always see a 100% accurate view of what the exact file-layout and content of their web projects look like (something not true with VS 2003).  Note: we no longer show the “references” tree underneath the root web project node because it is not represented in the file-system – instead you pull up the references list for the project from the project’s property-page (right click on the project in the solution explorer to quickly go there), and you can add a new reference to a project directly using the “Add Reference” menu or context menu item.

Web projects obviously fully support source control.  If you move or rename a file in a project under source-control, VS 2005 will move and rename the item appropriately with the source control depot (preserving history) without requiring you to exclusively check-out/check-in a project manifest to update it as well.

Better support for building much larger web projects

We’ve heard complaints from developers who work on large web projects with VS 2003 that the IDE and workflow environment doesn’t scale well to handle lots and lots of files and content.  Opening a large web-site can sometimes take minutes, and re-building and running it can often take a very long time when you make a change.

With VS 2005 we’ve tried to significantly improve this scalability to handle hundreds and thousands of items within a web-project.  As an example, on my local desktop machine (a P4 3Ghz) I just tested opening up a local web project with VS 2005 that contains 9,000 files (5,000 .aspx pages and 4,000 images – distributed across 36 directories each containing 250 items).  It opened with VS 2005 in under 3 seconds.  I could then open up and immediately begin editing any of the .aspx pages in any directory without any pauses or delays.  This is several orders of magnitude faster than any previous version of VS (where it would take minutes for a project of this size to even open).

Doing a first-time clean build of this 9,000 item web-site takes about 42 seconds on my machine (about the same time as VS 2003).  What is cool, though, is that after building the web project once I can now open any of the 5,000 pages, make a change to the code in the page, re-build it, and immediately run and test it in less than 2 seconds from the moment I hit Ctrl-F5.

There were a couple of architectural changes that we made to facilitate this.  One of the biggest changes was that we’ve moved away from compiling everything in a web project into a single DLL (which is the only mode that VS 2002 and VS 2003 support).  Instead, we now partition the web project into multiple more granular assemblies.

All non-code-behind classes, datasets, web-services and other non-UI code that live in the web project are by default now compiled into one common assembly.  Pages and User-Controls are then compiled into separate more-granular assemblies (by default each directory in the web project is compiled into a separate assembly).  Note that the web project can also obviously reference other class library projects as part of a solution too (these work just the same as today and would compile into their own project’s assembly).

The big advantage of this more granular model is that the entire web-site does not need to be re-compiled on every change -- instead the scope of compilation can be easily calculated based on what changed, what the down-level build dependencies of the change were, and only the affected pieces need to be re-built.

VS 2005 developers also now have more options in their “Build” menu -- they can force building the entire solution (including the current web project and all other projects in the solution), they can build/re-build just the web project, or they can now also choose to use the new “Build Page” option and build/re-build just the current page they are working on (and any dependent resources like user controls that it is using that have also changed) that they are editing.  This provides a great way you can quickly validate local changes you’ve made to a few files without having to-do a full build.  For C# developers who don’t have the background compile capability of VB, it also provides a super convenient way to update intellisense without having to-do a full re-build.

The F5 and Ctrl-F5 “run” options can also be configured by the developer to choose what level of compilation error checking should occur when these keystrokes are used to launch a web app.  The default continues to be compile all changed pages in the web site – although a useful configuration option when dealing with large web apps is to compile just the pages/resources you are currently working on (this would allow me to open a 9,000 file web-app in 3 seconds, and then compile and run any page within it in about 2 seconds – and avoid the first time hit of compiling everything else).

Deeper and More Accurate Error Checking and Validation at Built-time

Errors found at compile/build time are infinitely easier to identify and fix than ones hit at runtime.  One of our goals with VS 2005 and ASP.NET 2.0 was to increase the depth of checking we provide at build-time in VS 2005, and provide a more accurate view of what will happen with the web app at runtime that with VS 2003 built apps.

Today with VS 2003 and ASP.NET V1.1 developers actually use two different build environments (typically without realizing this). One of these is VS 2003 which compiles and builds the code-behind files within the web project using one set of settings (stored in a .proj file) and produces a .dll stored in the \bin directory.  The other build-system is ASP.NET V1.1 which at runtime will then use a different build system to parse and compile controls, markup and code within .aspx files that derive from the compiled code-behind classes, and which then saves the output of these compilations into a separate temporary folder on the server.  The build-settings of the ASP.NET compilation system, and the subsequent load-time behavior of the code-behind .dll that VS produces, are stored in the application’s root web.config file.

The fact that these two systems are completely different today can be confusing, and can often lead to errors that are missed entirely by VS at compile time – but which cause web apps to blow up at runtime.  A few common issues we often hear complaints about:

1) A developer renames the id of a control in the .aspx file, but doesn’t update the field reference in their code-behind.  When they build in VS 2003, they don’t see any compile time errors – but at runtime they get a null-reference exception (because there is a mismatch between the .aspx and code behind).

2) A developer has a typo on a server-control definition in the .aspx (wrong attribute, incorrect attribute value, misclosed server control tag, data-binding expression error, template error, etc).  When they build in VS 2003, they don’t see any compile errors – but at runtime they get a parse time error.

3) A developer has an error in their web.config file (either bad syntax or an illegal value).  When they build in VS 2003, they don’t see any compile errors – but at runtime they get a configuration error.

4) A developer builds a web project.  After testing it and thinking it is done, they switch the project from debug->release mode and compile assuming that the deployed project is now running optimized.  They forget that the <compilation debug=”true”> section in their web.config is the true switch to control whether the app runs under debug mode, and that VS configures this to be true by default and never changes it.  Their app ends up running slowly, and has different behavior (error handling paths are different, .aspx compilation is much slower and inefficient, etc) than it should.

5) Discrepancies between the values in the <assemblies> section in web.config and the references in VS can cause assemblies to be incorrectly loaded or not found.

With VS 2005 and ASP.NET 2.0 we decided to merge the ASP.NET and VS web project build-systems into one common compilation architecture with one shared place to store compilation settings for a web project.  Among other benefits, this now means that all of the above 5 issues will now generate compile-time errors when building web projects in VS (both in the IDE and through the command-line with MSBuild) instead of only being caught by testing at runtime.

It also means that we can do much deeper design-time integration inside VS itself – so that things like Master Pages, User Controls, Themes and other resources that have previously been “dynamically compiled” by ASP.NET only at runtime can now be compiled and used within VS as well (for example: this means you now get both WYSIWYG and intellisense support for user-controls, master pages and skin resources).  It also allows us to get full intellisense of code+content within .aspx pages – so <script runat=server> blocks, <%# %> databinding blocks, and other syntactical elements inside ASP.NET pages are now fully supported inside the VS editor.

We choose to store the unified compilation and build settings (release/debug, assembly references, namespace imports, warning levels, etc) within the <compilation> section of the application’s web.config (where all of these settings already existed in ASP.NET and V1.1).  Because this file is relative to the web project root, it allows the web project to be easily included in multiple .sln solutions within VS. 

In addition to providing richer compilation and runtime validation within web projects, we have also added new accessibility compliance validation in VS 2005 (to allow developers to check for Section 508 and WCAG compliance).  This accessibility checking can be run manually (there is a button in the toolbar and a menu item to configure and run it), or developers can also configure their web projects to automatically run the accessibility checker each time a web project build occurs.

More Flexible and Iterative Web Development Experience

We’ve tried to optimize the workflow behavior within VS 2005 to enable a more iterative and flexible web editing model.  Several of these optimizations are a direct result of the changes we’ve made in the web project system and include:

1) The ability to make quick tactical changes to your web projects in VS 2005 and immediately “save and refresh” to see the changes.  With VS 2002 and VS 2003, developers were always required to re-compile and re-build their projects to see the affect of any changes within their web apps.  VS 2005 obviously fully supports this as well (as mentioned earlier you can “Build Solution”, “Build Web” and “Build Page” to compile and verify there are no errors at any granularity). 

We also then support an “on demand” compilation workflow where a user can just save the code-behind or class file they are editing, and immediately hit refresh in the browser (no explicit re-compile or re-build required).  ASP.NET will then on-demand re-compile only the changed resources and apply it to that request – allowing you to immediately see the difference.  This is ideal for making quick surgical changes (one or two liners where you are confident you have it right and just want to immediately see the changes).  We think this feature merges the best features of dynamic languages/scripting (rapid development) with the best features of strongly-typed compiled languages (better error checking and performance).

2) The ability to both edit and add code while the debugger is attached.  With VS 2002 and VS 2003, attaching and detaching the debugger can often be cumbersome and time consuming (especially when it nukes the process on detach).  When the debugger is attached, developers are not allowed to make any changes to the running web application or web project. 

With VS 2005, we now allow a workflow where developers can launch a web project under the debugger, try out and step through a request to identify an issue, and then – without closing or detaching the debugger – add methods, classes, pages and change code in the project, hit save, and then hit refresh in the browser to immediately step through things in the debugger again.  This is supported for both VB and C#, and enables much richer editing support than the “edit and continue” support in client projects (where only code inside methods can be changed – and method, parameter, and class signatures can’t be changed).  I personally have found it useful to keep the debugger attached for 1-2 hours at a time, while I work on pages, classes and develop the entire web with the ability to step through things at anytime.

Richer Web Deployment Options

VS 2005 and ASP.NET 2.0 now support several additional deployment options for web projects not previously available with VS 2003.  These include:

-- The optional ability to completely compile a web project, including compiling all .aspx, .ascx, and .master file content (allowing you to compile and then remove the HTML and ASP.NET server control markup code, and optionally even remove the .aspx and .ascx files themselves and just ship the .dll assemblies).  There are a couple of benefits with this feature: 1) It allows you to ship a totally “locked-down” deployment package for enterprise deployment environments. 2) It allows you to better protect your intellectual property from customers if you don’t want them to see or change your markup. 3) It eliminates all runtime ASP.NET compilation steps, avoiding the first-time performance hit when a page is first accessed and the .aspx markup is compiled, and enabling much better application startup time and working set usage.  This later benefit can be particularly noticeable with large applications, and provides a big performance improvement over VS 2003 built apps today.

-- The ability to support “patching” of deployed assemblies within a site, and allowing you to overwrite some (but not all) of the compiled code-behind binaries on your deployment server without having to change all of the DLLs.  This is enabled using the “fixed names” option within the new web build-system, and is particularly useful with user control libraries where you might only want to re-issue a binary for one or two controls in a library and not have to update the code-behind dll used for all of them.

Note that in addition to support complete compilation, we also obviously continue to support a model where only the code-behind is compiled and the .aspx markup is left for later customization.  We also now support a fully dynamic compilation model where everything (including code-behind and classes) is dynamically compiled on the production server (this is useful for small site and hobbyist scenarios).

Web Project Build Automation Support

VS 2005 and ASP.NET 2.0 now have richer support for command-line level build automation, and can also be integrated and automated using the new MSBuild system being introduced in VS 2005.

ASP.NET 2.0 ships with a new command-line compiler (aspnet_compiler.exe) that provides full support for compiling and building ASP.NET projects (with or without VS installed).  It supports all of the new build and deployment options mentioned in web projects earlier (optional compilation of .aspx content, updatable assemblies, etc), and provides deep error warnings and detections when compiling web applications.

The aspnet_compiler.exe utility can be invoked standalone, or used within the context of a MSBuild project file.  MSBuild provides a very rich framework for automating and constructing build and environment rules.  Some scenarios of how you could use this for web projects: support building and then copying user-control libraries from multiple web-projects into a web-site as a pre-build step, compiling your web projects, code-signing output, producing both release and debug builds in separate directories for each automated build you kick off, kick off automated unit tests, send out code-coverage reports, etc.

MSBuild can be directly run from the command-line (it ships as part of the .NET Framework redist setup – so no VS is required on your build-server).  If you pass it a .sln file that has web projects contained within it, these can be built and deployed as part of the solution by MSBuild and provide basic build option support.

Unfortunately we don’t have direct MSBuild IDE support to launch MSBuild workflows in the web project IDE – so you can’t add a MSBuild file into a solution with only a single web project and directly kick it off in the IDE (note: C++ projects also don’t support this either in VS 2005).

What you can do though with VS 2005 web projects to get equivalent functionality is to add a “Build Helper Project” that lives next to your web project in the same VS solution.  This “Build Helper Project” is just an empty class library project, but can contain custom build/configured MSBuild scripts where you can specifically script custom build actions for both your web project and overall solution (for example: as part of a single script you could compile multiple user-control library projects, then merge them into a web application project, then compile and publish it, then run a post-grep utility over it to make sure only production deployment connection strings are being used in the web.config file, encrypt any necessary web.config files, etc, etc).  You can then kick-off these builds/actions by building the “Build Helper Project” either in the IDE or directly from the command-line.  This isn’t as elegant as attaching all of these build scripts to the web project directly, but it enables the same functionality – and provides a lot more power than what was available in VS 2003.

Going forward we are looking to add more integration support with MSBuild in the next VS Orcas release – there is a lot of cool stuff we will be able to-do with it.  In the meantime, we are also planning to post some samples on the web of additional MSBuild tasks (w/ source code so you can see and tweak them) that show how to enable both common and advanced scenarios with web projects.

Visual Studio Team System Integration

One of the biggest things in VS 2005 is the introduction of the Visual Studio Team System products, and the advanced development support they provide.  These features are fully integrated with the web project system and allow developers building web projects to take advantage of lots of new capabilities.  A handful of a few of the big new features that touch a little on the web project system include:

1) Ability to develop unit tests for both classes and web UI within a web project (allowing functional ASP.NET UI validation within test projects).  VSTS includes a built-in web replay tool that captures interactions between a browser and the server, and allows easy automation and validation of behavior.

2) Ability to measure and precisely quantify the percentage of code exercised by tests (what we often call code coverage).  A web developer can build a web project, then build lots of tests to exercise its functionality, and can then run those tests and get a report detailing that “74% of the lines of code in the web project were executed during the tests”, as well as a precise breakdown of what parts of the code-base were not exercised because boundary and use cases weren’t good enough.

3) Ability to load-test web projects to measure RPS (requests per second) throughput, average latency, memory usage and dozens of other metrics.

4) Ability to profile code execution of web projects, and analyze the % of time spent where within a web project as well as memory allocations and usage.

5) Ability to automate and kick-off regular or nightly builds using the new Build Server capabilities.  Tests can automatically be run as part of this to verify and report build quality. 

And a whole lot more… 

Visit: http://lab.msdn.microsoft.com/teamsystem/default.aspx for more details on Visual Studio Team System.

Sharepoint Server Support

We’ve done a lot of work to integrate ASP.NET 2.0 with the next release of Sharepoint that ships with Office 12 next year.  The new version is built entirely using the new feature of ASP.NET 2.0: WebParts, Master Pages, Themes, Site Navigation, Membership, Roles, Personalization, Localization, Data Controls, etc.

One of our goals with Visual Studio is to enable great tool support for building Sharepoint solutions.  Today with VS 2003 this is fairly limited (you can pretty much only create a web-part control as a class library).  One of the design goals of the new VS 2005 web project system was to enable great Sharepoint support, and enable directly opening and debugging Sharepoint solutions.  Going forward we will support creating and editing new pages in running Sharepoint servers, support adding code-behind logic to pages, creating application logic, customizing workflow, building and adding new webpart controls, and debugging the finished solution.

In closing (btw -- thanks for reading this far...)

As the above sections hopefully spell out, there is a heck of a lot of new functionality provided with the VS 2005 web project system.  We think this functionality not only adds a lot of new features to take advantage of, but also addresses a lot of the key pain-points we’ve heard feedback from customers using VS 2003 today.

So what are the downsides to it?  Well, we really hope there aren’t a lot….  Several people have expressed concerns about some important features missing from the project system in Beta1 and Beta2.  As I mentioned in my earlier blog post, though, these features will be in the final release.

The only current VS 2003 feature I know of that is not directly supported in the VS 2005 web project system is the lack of pre/post build events defined directly in the web project itself.  As I mentioned above in the “Web Project Build Automation Support” section you can add a “build helper project” into your solution to get back this equivalent functionality, as well as to get much, much richer build customization support than VS 2003 provided using the new MSBuild capabilities.  This extra step is a little more inconvenient than embedding directly in the web project, even though it does provide much more power. We will be publishing a whitepaper before the final release that walks through the steps on how to set it up and take advantage of it to help make its usage and benefits more discoverable.

Because there have been a number of changes to both the web project system, and lots of other parts of Visual Studio, it is also going to take a little time for current developers to learn all the new capabilities, how to take full advantage of them, and sometimes how to map and evaluate the new capabilities to existing solutions (and in some cases workarounds) they might be using today to achieve similar results.

It would be great if people could post questions or suggestions here for additional blog entries or MSDN whitepapers that you’d like to see come out between now and the final release that cover either “how do I do [insert scenario]?” or “is there a better way now to handle [insert scenario]?”  I’ll then follow-up on these and either post new blog entries on them or get whitepapers written that go into more detail.

Here are a few I’ve already been asked about that we are planning to cover:

1) Best techniques for re-using user control libraries in multiple web apps with VS 2005

2) Best techniques for building a single web-site that is partitioned up into multiple nested/isolated vdirs and applications with VS 2005

3) Best techniques for using MSBuild and builder helper projects with web projects in VS 2005.

4) Best techniques for upgrading from VS 2003 to VS 2005 and what project system considerations you should keep in mind.

Hope this helps provide some more information about the new project system, as well as clear-up some confusion about what it is. 

Again – let me know additional things you’d like more details or clarification on.



Recent Update:

I've posted several blog entries since then that discuss the web project system in more detail.  I'd recommend checking these out:

Using IIS with VS 2005 and the new Web Project system

Building Re-Usable ASP.NET User Control and Page Libraries with VS 2005

Some techniques for better managing files in VS 2005 Web Projects



  • Great post, thanks. I've already noticed most of these improvements, but I hadn't realized I can just hit refresh on the browser and the page would recompile. Wow.

    The only thing I think is missing is the ability to specify relative paths when using the built in web server. That forces every developer to have the web project checkouts under the same path. Was any thought given to this? Or is the feature there but I missed it?


    Gustavo Guerra

  • Hi Gustavo,

    Yep -- the on-demand refresh behavior for compilation is a pretty powerful feature. It majorly improved my productivity when I first started using it.

    Can you clarrify the relative path issue you are having with the built-in web-server some more? I'm not sure I understand it 100%.


    - Scott

  • Great stuff, I've forwarded to my dev team so they can study up. ;)



  • How about excluding files or folders? Did I miss that somewhere in the post?

  • Thanks for the juicy details! I can't wait 'til you guys go RTM!

  • Hi Marcus,

    Exclude files are supported with post-Beta2 builds and will be supported in the final release. The model for excluding something is still the same -- basically you select the item (or multiple items) in the solution explorer and right click and choose the &quot;exclude from...&quot; context menu item.

    One implementation change that we have made is that when you exclude something we append a &quot;.exclude&quot; extension to the file -- this then causes it to be excluded from all build operations, as well as from any deployment or publishing steps. Note that source control history is maintained during this rename (and if you rename it back).

    Hope this helps,


  • Need to re-read this again, but most of it looks great, but...

    &quot;Obviously we also fully support building web projects against IIS directly (note: this is required when you are building a solution with nested vdirs and sub-applications).&quot;

    Please make the Web Server allow root-relative, and or nest project or make IIS for Windows XP allow multiple test sites... It's difficult enough to migrate sites.

  • Scott,

    What happens when you have 5,000 folders in your website, with 1 aspx or 1 ascx (or multiple) in your website? If you were to load all of those assemblies into memory you would have some very negative performance problems.

    You said

    &quot;There were a couple of architectural changes that we made to facilitate this. One of the biggest changes was that we’ve moved away from compiling everything in a web project into a single DLL (which is the only mode that VS 2002 and VS 2003 support). Instead, we now partition the web project into multiple more granular assemblies.&quot;

    I think the performance guidelines that Microsoft itself put out stress you should favor 1 larger assembly over multiple small ones due to the overhead of loading an assembly into memory (I think this overhead equates to something like 20Kb + size of the dll.

    I was wondering if you could speak about the kind of testing you have done on this type of scenario, where a large number of assemblies are being deployed to a web server and how the performance is.

  • Hi Jeff,

    With VS 2003 today you compile all code-behind into a single DLL, but ASP.NET will in turn derive new classes for each .aspx file and generate new assemblies dynamically at runtime.

    The granularity of these assemblies is the same as the new compilation model in VS 2005 (roughly one per directory) -- so assuming you compile with full optimizations in VS 2005, you will have the same number of runtime assemblies loaded in your application as you do with VS 2003.

    Having said that, I would recommend against a directory structure containing 5,000 different directories each containing 1 .aspx page in it. That will be suboptimal for both VS 2003 and VS 2005 based solutions. ;-)

    We are actually doing capacity measurements right now and are planning to publish some whitepapers this fall that go into more details regarding large app deployments (for example: how does perf perform when you have 1000s of master pages, or skins, or directories, or pages, etc).

    Hope this helps,


  • We create our web services so the root directory only has a web.config file. Each web service is in a VD that is a seperate project in VS2003. This way we can deploy each seperate web service w/o affecting the rest of web services under the root. From what I am reading this should be doable in VS2005, correct? Below is as example of how we layout our web services.





  • Hi Shawn,

    Correct -- that approach will continue to work just fine with VS 2005.

    Hope this helps,


  • Hi Scott,

    Thanks for such a comprehensive post. One thing I was wondering about ASP.NET 2.0 is how to handle large files that are uploaded to the server. We use ASP.NET to run a large Document Management System where files are both uplaoded and downloaded through ASP.NET. What would be fantastic is the ability to stipulate where you want the uploaded files to be placed, whether in memory or in a certain directory which has the security set by the user. Files uploaded to this directory would be cleared at the end of each request. I have had a couple of OutOfMemory exceptions which I'm sure is due to the fact that ASP.NET is just using too much RAM due to buffering files. Further config options in web.config could be which files are allowed to be uploaded and the size permitted for all or certain file types. This info could be deemed at parse time of the request, so we do not get as far as an .aspx or .ascx and the associated overhead. I know this issue has come up before in v1.1, but is there anything different we can do in v 2.0?



  • Hi Marshall,

    ASP.NET 2.0 now actually spools large uploaded files to disk instead of always reading them into memory (which is what ASP.NET V1.1 did). So I think you should find things a lot better for your scenario with the new version, and will be able to use memory much more efficiently.

    Hope this helps,


  • Hi,

    I am a component developer and I started to look into converting my 1.1 components to DOTNET 2, now my component is an IRootDesigner implementation, so last week I converted it to version 2 and to my surprise I saw the new web project layout. I struggled a bit in getting to my root designer to work in asp.net but I got it to work. Now when I open my rootdesigner component and add an image control it adds the image to the resource file. Now when I run my webproject and I create an instance of my root component it complains it can’t find the resource (image). In VS 2003 it was already compiled into the dll with the old project system.

    So how do I get it to compile my resource file as well into the new “dynamically” created assembly with my component file? Like what you do currenlty with an .aspx file and its associated .resx file.


  • Hi Corrie,

    Any chance you could send me an email at: scottgu@microsoft.com with more details on exactly what your component does and what problem you are running into? I can then connect you with folks on my team to investigate.

    In general, if you are building a re-usable control or component, you'll typically end up using a class library project like you use today with VS 2003 (note that the design-time support for controls in ASP.NET 2.0/VS 2005 is much richer -- so there are a lot of new features to take advantage of).

    I'm not sure why your component project is currently a web project in VS 2005. You can ceretainly create one using a web-project -- although a class library would usually be the normal approach. Regardless -- you will be able to fully use resources with web projects if that is the project approach you take.

    Send me mail and we can investigate further and provide you with some examples and more guidance.



  • Hi,

    sounds realy good. We work with lots of files and its sometimes anoying to see the solution loading for a long time ( but not long enough to get coffee ). I always suspected that it was more a SourceSafe-integration issue. Did you work with lots of files and connected to a source control provider?

    regards Mathias

  • Hi Scott,

    If I understand you correctly you exclude files by renaming them (adding the extension .exclude)?

    1) What if the file name is important (due to other dependancies - I don't have an example)?

    2) More importantly what about thumbs.db? Sounds like that can never be excluded as surely it would be regenerated if renamed?

    Finally what's wrong with just using the 'hidden' file attribute??

    Best regards


  • Great Post, very useful!

  • Hi Mathias,

    I haven't tried the 9,000 file test under source control yet -- I'll try and see if I can give it a try soon. Note that VS 2005 we'll actually be providing two source control implementations. One is Visual Sourcesafe, and the other is a new enterprise source control system that ships as part of Team Foundation. This later source control system is much more &quot;enterprise class&quot; and has lots of additional features you can take advantage of. My guess is that it also scales much betteer -- I'll try to find some time to play with it and measure.



  • Scott,

    Here is my scenario that is not supported by VS.NET 2005 (I am using Beta 2, but I've read a decent about what has been improved since Beta 2). Please let me know if you have anticipated this scenario enough to have a workaround.

    I have an ASP.NET 1.1 application. I want to be able to compile and deploy this application as both an ASP.NET 1.1 and ASP.NET 2.0 application. You can expect me to stick to the ASP.NET 1.1 feature set and not utilize any features that are ASP.NET 2.0 specific.

    For instance, I deploy the application in 2.0 mode and find some 2.0 specific bug that I wasn't expecting. I want to redeploy the application in 1.1 mode (because this is a production app, with real customers and they can't wait while I deep dive into what Microsoft &quot;broke&quot; between 1.1 and 2.0).

    Because of the MASSIVE BREAKING CHANGES between 1.1 and 2.0, I have no idea how I can share code? The &quot;migration&quot; wizard changes almost every file in my 1.1 project in a way that 1.1 can no longer use it.

    So, I basically have two separate code bases for the app. One code base is 1.1 and one is 2.0. Almost all the code is the same, except for all the changes the migration wizard insists on. Is there any way for me to share ALL code between 1.1 and 2.0 (some sort of source code level compatibility mode)? If not, I'm in for some serious pain (I would like to just stay at 1.1, but there are too many things integrated with ASP.NET 2.0 - like VS.NET 2005, SQL Server 2005, etc.).

    This seems like a very common scenario for anyone willing to make the risky migration from 1.1 to 2.0. I'm shocked that there are so many breaking changes. I'm very scared to deploy 2.0 without having an easy to use 1.1 safety net.

    -Michael Maddox

  • Regarding Exclude files:

    If you rename files to .exclude, does that not make them unusable? We store user specific XML files under a directory in the app that should not be part of the project.

    While we can move the XmlStore out of the project, what can we do for temporary image files generated by our app? They have to be under the app root to be addressable.

    This is all under source control of course. I don't think any of the changes you've made really affect anyone not working with a source controlled solution.

    It also seems that working with a centralized copy of the app on a dev server could solve some of these problems.


  • Hi Michael,

    Unfortunately there is no easy way to support building V1.1 applications with VS 2005. The new VS takes advantage of a ton of new features in the framework, and the compilers emit meta-data that will only work with the V2.0 runtime.

    It is possible to build a V1.1 app that will run on both V1.1 and V2.0 using VS 2003 -- unfortunately it is the reverse that isn't the case.

    Note that this isn't specific just to ASP.NET apps -- WinForms and even class library projects are also in the same situation.

    What I'd recommend is that you partition your app into multiple different sub-projects -- where your business logic and data access are implemented in separate assemblies. You could then build and maintain these assemblies using VS 2003, and could then re-use them as binary references in both VS 2003 and VS 2005 projects. This would allow you to develop one code-base, and then use it projects built against both versions of the runtime.

    Note also that V1.1 and V2.0 support side-by-side -- so it is possible to have two apps running on the same server, one using V1.1 and one using V2.0. One strategy to consider would be to keep existing running apps locked back to use V1.1 (since presumably they are working today adn you don't want to go through a test-hit of re-certifying them). You can then deploy new applications using V2.0 on the same box as well.

    Hope this helps,


  • Hi Alexey,

    Note that there shouldn't be any problems with your XML file solution that you are describing above -- except if the files in their are buildable resources (for example: .aspx or .cs files). Assuming they are just .xml files or some other non-code format then there is no problem storing or generating them within the app.

    It is also possible to keep files in your project and not check them into source control. If you have files that are being dynamically generated (like cached image files) that is fine to-do underneath the app-root (although as an aside -- for security reasons you might consider a different location). If you don't check those in under source control then each developer will just have a private copy of their own image files and nothing will be checked in (which sounds like what you want).

    Hope this helps,


  • Thanks for all of this info. My top pick for your next post or whitepaper would be on your first item... best techniques to re-use control libraries across web apps. I assume these are user controls and not server controls, so I can actually maintain the look &amp; feel of a control with an ASCX document instead of Controls.Add() everywhere in code.

    I am also interested in the best way to deploy a website in ASP.NET 2.0 with the root directory and multiple embedded virtual directories using the same membership state. I believe I just need to point it to the same database and set the application name to match, but there may be more advanced topics which could be covered here, like using a different Profile provider with each VDir while using the same Membership provider to allow for a clean separation of Profile data but still a common membership state.

    And anything you can offer on MSBuild and Team integration would be appreciated.

    And I would like to know how MS intends to approach third-party version controls systems like Subversion which is a great system, but would it mean if I choose it I have to choose it for every project, or I can I mix some with VS Team Server and some with Subversion. One realistic need here would to be to have the creative department (Mac desktops) use the Subversion repository to manage the image archives while VS.NET 2005 can still pull those updates as a VDir. I do not want to run 2 version control systems just because the creative department does not run Windows, although Mono may provide some solution in this case.

  • Hi Brennan,

    Having multiple apps share the same membership (or roles, or personalization) store is actually pretty straightforward -- just make sure that each of the providers points to the same backend system or database and you should be good to go.

    With regard to Subversion and other non-MSFT source control systems, you should be able to use them just fine with VS 2005. I believe the granularity of source control can be done on a per-project basis, so in theory you could have a solution with 1 project in source-safe, 1 project in the new team foundation source control, and 1 in subversion. I've never tried that out actually, but in theory it should just work.



  • Thanks for the detailed post, Scott. Great info. I totally get the scalability issues with project files that list all pages in a web site - for very large sites, the old model has some major issues.

    My biggest complaint about the change is really the cognitive disconnect that now exists between the different project types in VS2005. In VS2003, there were projects. Now there are projects, and there are web sites, and they work differently, and they require the developer to think differently.

    That inconsistency is what I like the least. Why not have a project file that simply doesn't list the files in the project, but exists only for storing project settings? Even in VS2005, there's still the notion of project specific settings on web sites (things like project references) - they've simply been pushed up to the solution file.

  • Scott

    Your example might be more optimal from a performance point of view, but it certainly wouldn't be from a maintanability point of view. I would think you guys need to find a balance or provide the option of both scenarios being feasible.

    Aren't both of these scenarios &quot;less than optimal?&quot;

    Are you educating the developers that are creating projects with 5,000 aspx pages that their scenario is less than optimal? Because by the sound of things you have actually empowered them.

    If ScottGu says X is possible on his weblogs, then I guarantee some asp.net developers are going to take that as the gospel.

  • Well, I'll try the IISAdmin program (I recall having trouble with it before), but I still wish that MS had a native solution... Again, Either let the built in web server do root relative, or have IIS for XP allow multiple sites... Even if they are &quot;localhost&quot; only, or current subnet only. It's got to be a common scenerio for developers to work on multiple sites.

  • Hi Chris,

    It is definitely a common request to support multiple sites on XP with IIS. Right now we are planning to add support for this with IIS7 in LH. That is obviously still aways off -- but hopefully the IISAdmin utility might help until then.



  • Wow... renaming files (appending .excluded) to exclude them seems pretty drastic to me. The files are there for a reason and just renaming them seems weird to me. I think we all agree that project files were a major source of contention, but couldn't something like excludes be stored in a single config file?

    Personally, I'm using the telerik controls on my site and they include a huge folder of files (.aspx, .ascx, images, xml, etc) in a folder called RadControls in my website. When that folder is included in the project it generates a ton of error messages because they don't include the source for their code behind files. All of the code behind files and other source files are already pre-compiled and placed into my /bin folder of the website. I still need all of the RadControls\* files and folders in my website, but I really don't like seeing a ton of error messages and a warning about how the site failed to compile, but then I just ignore it and everything works fine.

    I realize that Telerik can and most likely will do something to alleviate this problem in the future, but it seems like a pretty simple and common usage scenerio to want to exclude files/folders from being included during compilation.

  • &gt;Can you clarrify the relative path issue you are having with the built-in web-server some more? I'm not sure I understand it 100%.

    In VS2003, one of the biggest problems with the web projects was that we couldn't just have the project in a subdirectory of my solution like we can with the other project types. That complicated a lot working on the same solution in different computers and with different people. One workaround was to force every developer to execute a script after checking out from the version control system that would create the virtual directory in IIS pointing to the desired directory.

    With VS2005 I though that problem was over, but when we create a web project and choose the File System, instead of specifying a directory relative to the solution, we have to specify the full path. That's really a no-no. That forces the project to always be in the same path, what's really anoying when working with version control. For example, If we want to have different revisions on different directories in the same computer, we have to go manually change the path in each one.

    Hope I have explained it better this time


    Gustavo Guerra

  • Hi Kevin Collins,

    If you are using the non-updatable build option (the one that removes all markup), then you shouldn't need to copy over the .aspx stub files when you make a change (unless you add a file in which case you should copy the new file over once).

    You should still copy over the assemblies in the \bin directory.

    Hope this helps,


  • Scott,

    I think you misunderstood my question.

    I am NOT interested in running my VS.NET 2003 1.1 app under the 2.0 runtime. I know that is possible. It's not useful.

    I want to compile and run my VS.NET 2003/ASP.NET 1.1 app under both VS.NET 2003/ASP.NET 1.1 AND VS.NET 2005/ASP.NET 2.0. i.e. I plan to dual compile the app with both versions of VS.NET, each targeting a separate runtime.

    Assume my production IIS server is using the 2.0 runtime. I can run either app on this server. I can deploy the 2.0 compiled app to the server, and if there is a 2.0 specific bug, I can deploy the 1.1 compiled app in its place. This is a nice safe back out strategy.

    However, it makes it very difficult for me to add features to my app. Best case, I need to add the features to my 1.1 app (using VS.NET 2003), run the VS.NET 2005 migration wizard, and recompile both. That prevents me from using the VS.NET 2005 IDE for development of essentially 1.1 compatible code, because I cannot &quot;back out&quot; the work of the migration wizard. In fact, I have to run the migration wizard over and over and over again anytime I add a feature that needs to be tested under VS.NET 2005. Not to mention the headache of keeping all these steps straight.

    When &quot;migrating&quot; a VC++ project from VS6 to VS.NET 2002, there were no code file changes, only solution and project file changes. When &quot;migrating&quot; a C# project from VS2002 to VS2003, there were no code file changes, only solution and project file changes. When &quot;migrating&quot; a non-web C# project from VS2003 to VS2005, there were no code file changes, only solution and project file changes.

    Do you see how you failed to meet my expectations here? To me, this feels just like the horrible migration from VB6 to VB.NET, although without the good excuse of the joy that is .NET.

    If I put a ASP.NET 2.0 app into production and eventually run into an ASP.NET 2.0 specific bug (imagine that the bug would be fixed in ASP.NET 2.1 SP1, but I can't wait for SP1 to be released), I have to &quot;migrate back&quot; to ASP.NET 1.1 to get my production app up and running again and in fact it's very difficult to do it manually because ALMOST EVERY CODE FILE HAS BEEN MODIFIED TO BE INCOMPATIBLE - FOR NO REASON THAT IS DEFENSIBLE TO ME (the standard reason I expect is that you couldn't fit backward compatibility into the VS.NET 2005 time frame). Why does the migration wizard force me to use partial classes? Why does the migration wizard delete my fully functional existing project file? etc.

    Why did you not seem to think about this scenario? Do you think ASP.NET 2.0 will be so bug free that everyone with production ASP.NET 1.1 apps will migrate to ASP.NET 2.0 once and forget it?

    I don't know what else to say. Hopefully this is clear enough.

  • Hi Liehos,

    The exclude file functionality is designed for excluding files (.cs, .vb, .aspx, etc) from compilations and builds -- so for static files like .psd's or XML files there is no need to exclude them.

    In addition to excluding individual files, you can also exclude file-extensions using the new web project system. For example, to exclude .psd files from being deployed you could add a section like this into your web.config file:



    &lt;add extension=&quot;.png&quot; type=&quot;System.Web.Compilation.IgnoreFileBuildProvider&quot; /&gt;



    This will then cause the file to still show up in your solution explorer, but to not be copied at all when you publish or deploy your app.

    Several people in previous questions have asked about techniques for blocking &quot;temp generated&quot; or &quot;user cache&quot; content from being published. The above technique is a fairly useful one that you might want to look into -- you can apply it to any file type or extension.

    Hope this helps,


  • Scott can you also tell us if the icon of an exclude will be 'disabled' in the project list?

  • Scott, can the IgnoreFileBuildProvider be applied to all files (of ANY type) in a particular subfolder, as well as all files of a particular type in the project as a whole? How about all files of a particular type in a particular subfolder?

  • Hi Stuart,

    The IgnoreFileBuildProvider can be registered at the application level -- and will then apply to the entire app. So if you register to ignore .psd files (which are photoshop files) there, then they will be ignored everywhere in the project. So to answer the second part of your question -- yes they can be applied to all files of a particular type in the project as a whole.

    Unfortunately you can't vary it by sub-folder, so that part won't work.

    Hope this helps,


    P.S. I'm slowly crawling my way through comments (I'm trying to get answers for each). I see you have one in the queue -- I will get to it this afternoon and publish it then.

  • Hi Paschal,

    The icon in the folder list is greyed-out/disabled when exclude is used (I think it just uses the same icon as the exluded items for other project times).

    Hope this helps,


  • Hi Chris,

    I just tried it on a more recent build and it seems to work fine -- maybe this was a bug with the CTP. Note that you can't modify the code while you are currently in a call-stack (which might be the other issue you are running into). Instead, you should hit continue, let the request finish, then modify the code, hit save, and hit refresh again.

    Hope this helps,


  • Scott,

    Thanks for the comprehensive post. Even as a long time ASP.NET developer, I'm struggling a bit to figure out all these new compilation options. Was doing some migration work over the weekend and have a couple questions related to your post.

    1. Now that &quot;Exclude&quot; is back, will the Upgrade Wizard now make sure files excluded from a VS 2003 project are excluded in the converted VS 2005 project?

    2. I somehow messed up my configuration on a migration I'm doing and now I'm not getting partial compilation any more (can't just build a page and view it). I think it has something to do with the &lt;compiler&gt; element in web.config. could you explain what web.config changes affect how the project is compiled? or are there things you can set in VS (I can't find anything in options or properties).

    3. What is the proper way to have a class file in a web app that any page can reference? Does it have to be in App_Code?

    Have a couple other related questions, but that's enough for now.


  • Hi Eric J. Smith,

    You should still be able to do what you are describing about with the telerik controls. We support having already compiled pages/code-behinds in the project in a sub-folder -- so you shouldn't get errors from that. Note that because the VS and runtime build semantics are unified, any errors you see at build time in VS will be the same you see at runtime.

    Send me an email at scottgu@microsoft.com if you are seeing errors and I can help identify what the problem is.

    Hope this helps,


  • I know that the poor XHTML rendering and CSS support drove me way from VS development for ASPX sites. (Including the evil done when using the design surface.)

    Issues like that are effectively big productivity knocks. The tool/system doesn't live up to my standards, so I can't use it.

    I notice, with some concern, that you only mention DreamWeaver and FrontPage as alternative tools. Both tend to support the &quot;wizard driven&quot; developer, not the person who wants valid XHTML and CSS everywhere it can go.

    Not having tested ASPX 2.0 yet, how does it shape up on this important front?

  • Hi Mike,

    We've spent a lot of time in VS 2005 trying to make it a great web development tool -- I definitely agree with you that VS 2003, while a great dev tool, struggled in many dimensions with web development.

    VS 2005 by default generates XHTML compliant markup both in design-view and source view. It also ships with XHTML intellisense and schema validation -- so that you can find and fix in real-time all XHTML compliance issues.

    Note that when I mentioned DreamWeaver and FrontPage as alternative designer tools I was using them simply as two examples. One of the big goals with the new web project system was to make sure it worked well with *all* tools that use the file-system, and not require other tools to have an intimate knowledge of how VS stores and uses files (which is what VS 2003 does today). The benefit of this new approach is that we can work with different tools out of the box without them having to do anything special, and as a result have a much richer and more flexible system.

    Hope this helps,


  • Hi Gustavo,

    [This is in regards to your comment on relative vs. absolute paths above]

    I checked with the dev who owns this code, and apparently he stores both the relative and absolute paths to the web projects in the .SLN file. The relative path is used with VS 2005 when the solution and project are on the same disk drive -- so this will give you the behavior you are looking for (and should fix the issue you are seeing with VS 2003 webs today).

    The reason the absolute path is also stored is for cases where the solution lives on different drive or build location. In these cases, relative paths break -- which is why this value needs to be stored as well.

    Hope this helps,


  • Hi Scott,

    Thanks for the feedback on XHTML / CSS. I heard this was fixed, wanted to be sure. (If you look carefully at VS 2003, the infrastructure is pretty sound for XHTML, but some things built on top of it let the side down.)


  • Hi Curtis,

    To answer your questions above:

    1) The upgrade wizard doesn't exlude existing items during the project upgrade process, because we've seen a few advanced scenarios where developers are still using excluded files in their projects -- or have two separate projects that point to the same directory. Instead, as part of the upgrade wizard we flag the excluded files in the new &quot;todo&quot; section of the MigrationReport -- that way developers can choose the right semantics based on their specific scenario.

    2) Can you send me an email with the error message you are hitting (scottgu@microsoft.com). I can then help you figure out how/what the problem is.

    3) If you want to share classes accross all the pages in your web project there are two approaches you could take: a) put the class under the app_code directory, or b) put it in a separate class library project that the web project links to.

    Hope this helps,


  • Hi Michael Maddox,

    [this is in response to your question above about wanting to build the same source base with both VS 2003 and VS 2005 and run it simultaneously on ASP.NET V1.1 and ASP.NET V2.0]

    I understand what you are trying to-do now, and unfortunately I don't have a great answer for you. There are changes between the two versions that will make using a single source base that works simultanously on two different runtime versions with two different versions of the tools difficult. To be honest with you, if you want to achieve this I'd probably recommend stay using VS 2003 for awhile and then try running the binaries under ASP.NET 2.0 until you feel confident enough to switch over for good (at which point you could take advantage of the new features).

    There are a couple of reasons I say this:

    1) The main motivation to upgrade to VS 2005 is to take advantage of new features. If you want to run your source base without modifications on both V1.1 and V2.0, and load it both in the VS2003 and VS2005 designers, then by definition you can't take advantage of any new functionality without making it impossible to run on the older version.

    2) The compilation output generated by all compilers with VS 2005 will contain V2.0 specific metadata that will not work with the V1.1 runtime. So even if you do not use any new APIs, but still recompile your binaries using VS 2005, you won't be able to run these on older versions of the runtime.

    3) The project and solution file format for all project types (not just web projects -- but also client and class library projects which now use MSBuild) has changed. This means that while you could keep the same source code in a lot of cases, you would need to store and use different projects to maintain it. Keeping these in sync while doing changes in both tools will be pretty challanging.

    Having said all that, if you really want to try, you could make it happen by doing the following:

    1) Create a new VS 2005 sln file that will manage the V2.0 based solution. This should be separate from your VS 2003 sln file.

    2) Migrate over your class library and non-web projects to use the new MSBuild-based project format (this will happen when you try and open their projects the first time) and add them to the solution.

    3) Migrate over your web project not as a web project but as a class library. You should do this manually by creating a class library project with a project file that lists all of your existing code-behind files and misc classes and compiles them into a single assembly like VS 2003 today. You can then open up the project and compile it without having to change any code. You won't get the new web project system benefits, and the WYSIWYG designer probably won't work. But you will get intellisense and be able to edit, update, and compile your code.

    I'm not sure if the benefits you get are worth the pain of keeping the two solutions in 100% sync, but the above 3 steps should allow you to make it work.

    Hope this helps,


  • Hi

    &gt;I checked with the dev who owns this code, and apparently he stores both the relative and absolute paths to the web projects in the .SLN file. The relative path is used with VS 2005 when the solution and project are on the same disk drive -- so this will give you the behavior you are looking for (and should fix the issue you are seeing with VS 2003 webs today).

    &gt;The reason the absolute path is also stored is for cases where the solution lives on different drive or build location. In these cases, relative paths break -- which is why this value needs to be stored as well.

    I just checked, and it works. Great! That solves my problem. But I would never guess that is possible. When we create the web, we should be able to specify a relative path, and the default should be that, like on the other project types. In the other projects we can also specify a full path if we want, but the default is relative to the solution, and in the solution explorer only appears the full path in the case of other drives. It's a little anoying to always see a full path in the solution explorer when on most cases it could appear only the directory name

    Thanks for the info.

    Best Regards,

    Gustavo Guerra

  • Scott,

    I didn't mean to come across as combative. I see your point about making the code scale well for 9,000 pages, because 90 will most likely scale well also.

    I think there will be some initial pain, and most of us are working with a pretty old version of the IDE at this point. I think you guys are handling this the right way, by communitcating with the community so openly and I appluad Microsoft for it.

    I don't agree with all the decisions you guys made, but I appreciate the effort nonetheless.


  • Hi Scott,

    Thanks for the clarification!


  • Hi Ben,

    VS 2005 for web projects also support copying over the dll into the \bin folder at compile-time. This allows you to avoid checking in any binaries, and should give you the same workflow you are looking for.

    So you should be fine continuing with the approach you are using today.

    Hope this helps,


  • This is a great blog. We have been using .net 2.0 for more than a year now and have built www.edirection.com, ground up using 2.0 and all it's cool features like master pages, themes et al..

    Many thanks to this team!

  • Hi Scott,

    Thank you for your responses regarding item check-in.

    Maybe we're talking about different versions of the IDE (I got the June CTP), but when you open a project and try to check in your solution (because you want to check in all the changes you've made over several items or new file additions) all new items, including any temporary files that were generated, will show up in the check-in dialog. This also includes the /bin folder (which I would imagine you're going to exclude going forward).

    Maybe you can maintain a list of files/directories NOT in a project in some kind of .webexclude file? This way there will be alot less contention for a shared file, since most people will be adding relevant content to the project.


  • Hi Alexey,

    The final release of VS 2005 will automaticlaly filter out \bin items and everything associated with Project to Project references when you pull up the pending checkins dialog.

    Unfortunately with visual source-safe it will still show other items not currently under source control in the pending checkins dialog as potential files to add. You can uncheck these and ignore them if you don't want to add them (and instead just keep the files you do want to check-in selected), but it will still prompt you on them when you pull up the checkin dialog each time (note: the selection is hierarchical -- so you can at least uncheck a directory to deselect things).

    It turns out VSS has a hidden file (it is actually not stored using a project file but another file with a custom format) that it generates with some non-web projects to avoid asking the developer this every-time -- but I just checked and we don't honor this in the web path.

    We are following up with the VSTS source control team to see if they can honor this with the new source control system coming out next year. I haven't heard back yet, but will see what we can do there.

    One simple trick in the short-run with VSS if you want to avoid having to click ignore on these files on each check-in is to mark them as hidden or store them under a hidden directory. This will hide them and cause them not to show up in VS (even though if you have &quot;show hidden files&quot; selected in the file-system it will show up there). This might be useful for scenarios where you are generating temporary files at runtime and storing them in a directory (caching images, etc).

    Hope this helps,


  • About not using project files to keep file lists including exclude files...

    Why not use file properties / metadata, to tell VS2005 for example wether the file is excluded? There is more to a file then name and content, and properties used right could help in a lot of different problems.

  • Hi Gil,

    Applying meta-data on a file is something we've looked at in the past for some things. The biggest challange we've seen is that file meta-data is sometimes lost (for example: some FTP clients end up loosing it) which can sometimes make this a little brittle.



  • Is there an option to Automatically generate deployment webpage after every publish using MSBuild? This option is required to Automate the build process.

  • Hi Van,

    Can you clarrify what you mean by automatically generate deployment webpage after every publish using MSBuild?

    If you mean can you automate a compilation and copy operation using MSbuild, the answer is yes. But I'm not 100% sure if that is what you are asking.



  • Hi again, one more question...

    Is it possible to have a Web Reference to a Web Service project running in the built-in development web-server of VS, instead of IIS? This would be very handy during develpment.

    Best Regards,

    Gustavo Guerra

  • Hi Gustavo,

    Yep -- you can absolutely have a web reference to a web-sevice hosted by the built-in developement web-server. This can be a very useful technique.

    Hope this helps,


  • Scott,

    Do you know if the issues with the spnet_compiler changing compiled assembly names will be addressed in RTM? In particular, in beta 2 you can specify -fixednames to keep the generated assembly names consistent, but doing so creates one assembly per-page (as opposed to the one assembly per directory that is generated without the -fixednames option). As an ISV, I obviously have to have fixed files names so I can install the product, but one-assembly-per-page has a lot of overhead, and I would image has to have some scalability issues.

  • &gt;Yep -- you can absolutely have a web reference to a web-sevice hosted by the built-in developement web-server. This can be a very useful technique.

    But how? I can't sppecify the url of the vs server, as the port number is always different, and in the &quot;add web reference&quot; wizard I don't see any more options. Can you give me a hint?

    Best Regards,

    Gustavo Guerra

  • Hi Kevin,

    Right now the only way to get a fixed assembly name is using the fixednames option -- which generates an assembly per page. I'm following up right now on ways to enable this per-directory.



  • Hi Gustavo,

    If you look select your project, and then look in the property grid, you'll see a &quot;Use dynamic ports&quot; property for file-system webs. If you set this to false, you can then hard-code a port to launch the file-system web under.

    Hope this helps,


  • Hi Kevin,

    I have good news for you -- we have a utility now that will allow you to generate a fixed name for your web library or web project, and merge all of the page assemblies together into a single file you can version and deploy.

    I'll post more details on this later this week.

    Hope this helps,


  • &gt;If you look select your project, and then look in the property grid, you'll see a &quot;Use dynamic ports&quot; property for file-system webs. If you set this to false, you can then hard-code a port to launch the file-system web under.

    Thanks. That's a life safer

    Best Regards,

    Gustavo Guerra

  • Hi again

    Is it possible to instruct the built-in web server (via a registry key or machine.config) to accept connections from outsise the local machine?

    I'm developing a Smart Device application that uses a Web Service, and the connections from the Pocket PC Emulator are considered as coming from outside. That forces me to use IIS directly for the Web Service while I'm testing.


    Gustavo Guerra

  • Hi Gustavo,

    Unfortunately (or fortunately) for security reasons the local-only request limit is hard-coded in the code. So for your mobile device scenario you'd need to use the IIS option instead.

    Hope this helps,


  • (Yet) another question.

    I don't know if this is a known bug/feature, but when we create a bew application in IIS using the copy web site form/wizard, the site is created with ASP1.1 bindings, even if we copy a 2.0 site. Is this a known issue?


    Gustavo Guerra

  • Hi Gustavo,

    When you open a web-site using VS 2005, if the app doesn't currently have ASP.NET 2.0 configured it will prompt you to upgrade it to 2.0.

    For most remote scenarios (where you are using copy-web), we don't have admin access to see what version is being used.

    The version picked up on the remote site will end up being determined by how ASP.NET is configured on the box. You can configure ASP.NET to be the default for the root site and new sites, but keep old apps locked back to V1.1. Or you can configure so that some apps run as V2.0, but that new apps still get V1.1 by default.

    Hope this helps,


  • Scott,

    That's great news about the assembly merging tool. I look forward to more information on the topic. Do you know if the new tool is included in the August CTP?

  • Hi Kevin,

    The tool isn't in the August CTP drop -- we are actually just working on it now. Basically it uses some of the ILMerge.exe capabilities that recently shipped on the web to merge multiple page directory assemblies into a single one. You can then name, sign and version this single assembly however you want. We are planning on shipping a web download that provides both command-line support for this, as well as a MSBuild task. That way you can fully automate it within your build environment.

    Hope this helps,


  • Is this assembly merger a tool that will ship as part of VS2005? Or will it be a separate download entirely? If the latter, will it ship concurrently with VS, or follow after the release?

  • Hi Kevin,

    The assembly merger tool will ship as a separate download concurrently with VS. The plan is to have a GUI tool, as well as a command-line utility and MSBuild task you can embbed in your projects. This will allow you to perform the merge process as part of your standard build operation.

    Hope this helps,


  • Scott,

    Great, thanks for all of the info. And thanks for being so responsive to all of the questions. It's been very helpful.

  • Building resource files should not be dependent on the use of Visual Studio.

    I do not speak Mandarin Chinese or French for example so where am I supposed to get the native language skills to localize projects? I would outsource this of course.

    Being compelled to license a copy of Visual Studio for a single task such as building a resource file is wrong.

  • Hi Clinton,

    Yep -- totally agree. The good news is that you don't need VS at all to localize resource files or ASP.NET applications. All resources are stored in XML files (with a .resx extension). ASP.NET now supports dynamically compiling these if you want. ASP.NET also ships with a command-line compiler to localize these. You don't need to have VS installed at all to-do this.

    Hope this helps,


  • Hi,

    I want to know what are the new features are in vs2005.

  • Hi Thomas,

    Unfortunately when you connect with FPSE it needs to pull down all of the files I'm afraid. This is probably the reason for the slow loading delay. When I was building above I was using a local file-system to connect.

    If you want to send me email directly (scottgu@microsoft.com) I can help suggest a few optimizations you might want to make.

    Hope this helps,


  • Scott,

    I'm noticing that a lot of the familiar parts of a web service project just aren't there anymore. The Global.asax file for instance is not there. I was keeping my AES encryption keys here as well as other code. Is there a guide to using the VS2005 to develop webservices as opposed to the VS2003 way?

    HArry Simpson

  • Hi Harry,

    The Global.asax file isn't added by default anymore. However, you can add it by choosing "Add New Item" and selecting the "Global Application Class" option.

    Hope this helps,


  • Hi Scott
    You mention about being able to compile up a web project into a single .dll for deployment without .aspx/.ascx files. Can you tell me would this enhance the performance of Page.LoadUsercontrol(), would this mean the .ascx is already compiled at runtime?
    Many Thanks

  • Hi Kieran,

    This wouldn't improve the performance of Page.LoadControl() significantly. The reason is that after the first time the control is loaded the Type is cached by ASP.NET - so subsequent loads are just as fast either way.



  • As an SCM/release engineer, I don't like certain parts of the new way. I can't just copy source code to a build area and commandline build. Why? Because the referenced dll's aren't in the bin directory, and there's no way short of a refresh file to tell where to get the reference. So (using ClearCase), I can't just create a view then build because the csproj file no longer exists. So there's no HintPaths that can be pointed to the appropriate reference automatically (using relative paths).

    Also, no cleans for web projects. How can I be sure I'm not compiling against old reference dll's? If I delete them from the bin, the build fails unless I add a refresh file.

    I also dislike that it keeps wanting to add compiled code into source control. Maybe in VSS that was okay (which was dumb, why consume storage space for reproduceable files?), but it shouldn't happen by default.

    I also dislike having to keep checking out web.config files, web references, etc., especially if I have no intention of modifying them. This makes version trees huge as developers keep checking them out (default behavior) then checking them back in even if nothing changed (identical versions). It makes it very difficult to track real changes to them if I have to wade through 100's of different versions when most of them have no changes.

    I also don't like web references. Everything seems geared to using the GUI to build, making it very difficult to do commandline automated scripted builds. Why should I have to update a webreference prior to building? Why not just reference some dll or just automatically use the URL? It also makes it difficult to track down if there are any potential circular references.

  • Hi Marc,

    If you prefer having a project file approach, I'd recommend using the VS 2005 Web Application Project option: http://webproject.scottgu.com.

    This has the same semantics as VS 2005, and is also fully supported by Microsoft. It will also be built-into VS 2005 SP1 (currently it is a separate download).

    Hope this helps,


  • How do I set the CopyLocal property to True for GAC assemblies I've referenced???

  • Hi David,

    Can you send me an email with more details on the scenario you are after? I can then help loop someone in to help.



  • I will go on record here to *bitterly* complain about the changes to the exclude functionality.

    I have a webservice that logs diagnostic information in a subdirectory under the virtual directory. These log files *MUST* be somewhere in the virtual directory because I support accessing them through a browser page.

    VS2005 *INSISTS* on adding these log files to VSS. Your solution of renaming the file to .exclude is worse than pointless in this situation. My webservice will diligently create a NEW log file, and then I'm right back where I started, but with this orphaned .exclude version of an old log file kicking around.

    I REALLY NEED the ability to exclude files and ENTIRE FOLDERS from both VS8 and VSS. Your current software doesn't support that. I hate it when engineers think they know better than the users how things should operate, and remove or break critical functionality in the process.

  • Hi Bill,

    Have you looked at using the VS 2005 Web Application Project model? This was introduced about 6 months ago and gives you the same project model format that you had in VS 2003. It specifically supports excluding files and folders using a project file approach.

    You can learn more about this project option here: http://webproject.scottgu.com. Included on the site are details on how to move a web site project model to it.

    You can download the web application project model separately with VS 2005 RTM, or get it with SP1 (where it is built-in).

    Hope this helps,


  • I have a question. I'm trying to decide what's the best approach to managing a Web site that has both classic ASP and ASP.Net. I'm trying to move away from FPSE and also allow a handful of developers to work on the Web site (there are several but let's start with one here). We're using VSS 6.0. We have a central development server with the Web site in question. The same server houses the VSS install. Traditionally, we've used the usual VS projects and relied on FPSE's source control settings to govern working folders and the like. Now, without FPSE, I'm trying to understand what the "best practices" way to manage the code and source control might be. Do we have everyone set their working folder to be a share of the development site's Web directory? We have a central DB that the site ties to (and it's completely data driven). We use exclusive check out as well. What I want is to enable the developers to work on the dev server's version of the code (which is also stored in VSS). Sure they can use the local IIS option in VS 2k5 but then they're working off a version that's local and might not include changes another developer worked on. I'm starting to look at TFS and it's SCM but everything seems to be more app dev based rather than Web dev based (i.e. the SCMs all seem to want to assume that the developer can have a full working environment locally that can be merged later which isn't necessarily true when you're working with a large SQL Server database). Thoughts?

  • Hi Ken,

    Any chance you could send me an email with this question? I can then connect you with someone on my team with more experience in this area who might be able to help.



  • We are going to separate a large web application into multiple modules for team development. I know we can create a .NET Web Application, and then create a separate project for each 'module' within that Application. Does Web Project System support this?

  • Hi Liche,

    You can use the approach outlined here: http://weblogs.asp.net/scottgu/archive/2006/08/16/Tip_2F00_Trick_3A00_-Creating-Sub_2D00_Web-Projects-using-the-VS-2005-Web-Application-Project-Option.aspx to enable sub-web projects, which allows you to componentize your application across multiple projects.

    Hope this helps,


  • Hi, Scott:
    Many thanks...
    It is really helpful.

  • Scott,

    here's another vote for adding greater control over whether a file should be added to the check-in list each time it changes. This is not the same as whether or not it's part of a project. In our projects, for example, app.config and web.config, once we have a base set of settings as desired, can still require additional tweaks on each developer's machine, but it causes problems if these per-developer changes get inadvertently checked-in. Adding a file property would be a partial solution. Adding an attribute tag might also be a good partial solution, at least for text files. Otherwise, adding an optional special text file to list check-in exclusions would be nice. Note: the check-in exclusions should be explicitly overridable.

Comments have been disabled for this content.