Quick Web Project System Post

I've been on vacation the last few days in Mexico (and fly back Sunday night), so am just catching up on all the web project system threads that have been flying the last 48 hours (serves me right for finding an internet cafe to check my email when I'm not supposed to).

I'm planning on posting a blog post on Monday or Tuesday when I get back that goes into the web project system in more detail and why we've made some of the changes we've made.  My sense in reading some of the recent comments is: 1) we haven't done a good job of explaining all the new capabilities that the new web project system provides (and there are a lot of good new features), and 2) we haven't done a good job of clarrifying people's concerns about the changes and what they might worry about loosing in terms of functionality as a result of them.

One thing I wanted to clarrify before my uber-post about the web project system is that the Beta2 release was a beta -- and one where the code was frozen way back in February (this is when teams forked to work on the RC code-branch).  A lot of changes and improvements have occured since then (thanks in large part to feedback from the community), and most (if not maybe all that I've seen recently) of the "missing functionality" that has been called out as part of these discussions is now fully supported in post-beta2 builds. 

Specifically, the 5 "functionality is missing" concerns I've seen called out that I want to clarrify and hopefully allay people's concerns before my more detailed post next week:

Concern #1:  Source control checks in binaries in the \bin directory.

Update: Just to clarrify -- this behavior was never by design (since it makes source control extremely painful to use), but was rather a late-regression in the beta2 tree that wasn't caught in time to fix before beta2 was released. This has been fixed since then and will not occur in the final product.

Concern #2: Lack of exclude file support.

Update: This was something we origionally thought wasn't needed because of a new feature in web compilation that allows projects to skip and continue over compile errors (a very useful feature actually when working on large projects with lots of pages where you don't want to constantly exclude pages that are temporarily broken -- a new feature not supported in VS 2003). The feedback after beta2 clearly indicated we were wrong so we added it back in and it has been in builds for a few months. It will be supported in the final product.

Concern #3: Web projects don't support file-based assembly references (the Copy-Local flag feature in VS 2003).

Update: This was a missing feature in Beta2 that we've also added support for and is in recent builds, and will be supported in the final product.

Concern #4: In Beta2 a separate assembly was created for each page when using the "Publish Web" wizard in VS.

Update: The web project system supports a granular level of assembly creation. In Beta2 it supported lots of different levels at the command-line level, but the Publish Web wizard was hard-coded to use the option that generated 1 assembly per page (useful for new patching scenarios not previously available in VS 2003, but also something that generates a lot of assemblies). This could be overrided using MSBuild, but wasn't very discoverable. The Publish Web Wizard now allows developers to choose the granularity they want in the dialog -- and the default is now 1 assembly per page directory (which still provides good granularity -- but a lot fewer assemblies).

Concern #5: Is there still a way to compile user controls or standalone pages in a project and then re-use the resulting binaries in multiple web projects?

Update: This was actually supported in Beta2, but is not very discoverable (note: it was also not that discoverable in VS 2003 and not something that VS 2002/3 actually "officially supported" and tested even though it works).  If you use the "fixed names" compilation option in web projects in VS 2005 you will be able to create a web project with user controls in them, compile and publish the project, and copy and re-use them in other projects (where no code-behind source code is deployed -- instead these are compiled into assemblies you deploy in your \bin directory).  We'll be posting a white-paper that will walkthrough the steps on how to-do this, as well as instructions on how to create MSBuild scripts that automate this from the command line for enterprise build environments.  As with the VS 2003 option (where you needed to be careful not to add a Global.asax to the project, etc), there are a set of "things not to-do" when building these types of project.  But you will be able to accomplish the same scenarios.

As I mentioned in the beginning of this post, there are a lot of new features that are enabled by the new project system (I will go into these in more detail in my post next week). 

Some have argued that these are primarily for "small app developers" -- I'd argue that isn't the case (although ceretainly there are a lot of advantages in there for small projects too).  A few of the new enterprise scenarios now supported include: much better tool scalability for large applications projects involving 1000s of .aspx pages (whereas previously build and project load time made these scenarios impractical), support for patching compilation binaries (allowing you to hot-patch user control or page binaries without having to replace the .dll containing the code for your entire project or app), much better error detection (which is much, much deeper and more accurate than VS2003 compilation -- including compilation detection for errors in web.config and .aspx syntax markup that previously would be ignored by VS 2003 and only be discovered at runtime), richer levels of pre-compilation support (including allowing you to completely remove all run-time compilation from the equation and compile everything including the .aspx markup at build-time -- something not supported by VS2003 and ASP.NET V1.1 today), much richer command-line compilation support with MSBuild integration, and many more that I'll elaborate on next week.

The web project system is also fully integrated with the new VSTS and Team Foundation features -- so you can now automate nightly builds using the new VS build server (no need for someone to build from the IDE), run automated class unit tests, run automated web UI unit tests, calculate both block and arc code execution coverage of code, and perform performance tests and code analysis profiles against the built apps. 

I'll go into more details about the web project system on Monday or Tuesday when I fly back to Seattle (where my laptop is), but wanted to quickly address some of the concerns going around.

Thanks,

Scott

Published Saturday, August 13, 2005 2:38 PM by ScottGu

Comments

# re: Quick Web Project System Post

Saturday, August 13, 2005 8:30 PM by Sean Chase
Are all assemblies in the \bin folder going to automatically be referenced in the final version? Any way to exclude them (for example if I'm using Assembly.Load and don't want the auto-reference and intellisense to show up for that assembly)?

# re: Quick Web Project System Post

Sunday, August 14, 2005 12:58 AM by John Walker
Thanks for the update, Scott. Much appreciated and looking forward to trying it all out.

# re: Quick Web Project System Post

Sunday, August 14, 2005 4:38 PM by scottgu
Hi Sean,

The new web project system using the <assemblies> section within your web.config file to control references and assembly load behavior. One nice aspect of this is that it unifies the development time and runtime settings into one so that you always get consistent results.

By default (since ASP.NET V1) there was been a reference in the root machine.config to * compile and load all assemblies in the \bin directory. You can override this behavior, though, in your app's web.config. Just clear this entry and manually specify the assemblies you want VS 2005 and ASP.NET to reference and use automatically. You can then use Assembly.Load to manually load others based on your own algorithm.

Hope this helps,

Scott

# re: Quick Web Project System Post

Sunday, August 14, 2005 7:34 PM by Snorrk
Clear and concise, great post.

# re: Quick Web Project System Post

Monday, August 15, 2005 6:51 AM by Martin Naughton
Hi Scott,

From your entry:

'If you use the "fixed names" compilation option in web projects in VS 2005'...

Can you explain the "fixed names" feature a bit more (or point me to documentation on the feature)?

Would this feature help me with the following issue I encountered after conversion:

I'm looking for a way to obtain a meaningful Build Version, for on-screen display. In ASP.NET 1.1, I could interrogate the CallingAssembly (which was the CodeBehind DLL). That code in ASP.NET 2.0 returns a value of "0.0.0.0" as the version string.

Any ideas?

Thanks,
Martin

# re: Quick Web Project System Post

Monday, August 15, 2005 11:25 AM by Brennan Stehling
I am anxious to read that white paper on "fixed names" compilation option in web projects so I can share page fragements across web projects. That will save me a lot of time on these web projects!

# re: Quick Web Project System Post

Monday, August 15, 2005 11:32 AM by Bob Archer
Another concern I've seen voiced, and also have personally is how do you deal with Nested virtual directories / applications?

We have a 2003 project that is actually designed for modular deployment. We have a Root solution that handles login/menu. This gets a virtual directory localhost/WebRoot. The default.aspx page here creates a framed interface.

We then have applications that plug into this root. One example is a Config application. This is a web app that allows the user to set up system users, databases, etc. The virtual directory for this system is internal to the above, so it's Virutal path is localhost/WebRoot/Config.

With 2003 since testing/debug uses the IIS virtuals, even though the apps aren't physically nested since the virtuals are I can refer to the top level pages at will. For example, if I have a page in localhost/WebRoot/Config that has a Cancel button on it, we cancel to ../TodaysPage.aspx.

How would that work in dev mode since there are no virtual directories?

Another thought, I could do a simmilar modular app without frames by creating a master page in the root app. Then using that master page in my sub-apps/modules. I'm not sure if this is possible. Since the dll changes names with each compile, how could I refer to a master page in a seperate web project? I don't see a way with the current structure.

So, the main expectation here is to have a framework that allows the addition of modules without neededing to deal with the code from the root solution. Simmilar to DNN or other modular portals. The problem with DNN is that everything is in one huge solution.

I want each application in our system to be it's own solution.

BOb

# re: Quick Web Project System Post

Monday, August 15, 2005 2:31 PM by Adham Shaaban
Great post, thanks for the clarifications Scott. Looking forward to your follow-up post soon.

# re: Quick Web Project System Post

Monday, August 15, 2005 4:19 PM by Tyler Carver
Scott,

I'm sure you, your team, and Microsoft put in a ton of last minute work to push these changes through. Thanks!!! It is very much appreciated.

Tyler

# re: Quick Web Project System Post

Tuesday, August 16, 2005 9:36 AM by Jeffrey Palermo
This addresses some of my concerns, thanks. I'm curious where project information is being stored if there is no project file. I've heard that some information might go in the solution file. If so, how do scenarios where the same webapp resides in multiple solutions work?

Also, will RTM have pre and post-build events in web projects, or is that feature really being taken away (I use it extensively in VS 2003).

My company (Pluck) is doing all development with .Net 2.0 Beta 2 now, so we're using it in real-world projects. Using a class library for web projects is a tempting workaround, and I've verified that it works (with a few quirks), but it may be a necessity if that's the only way I have pre and post-build events.

I'm hoping this will make it back in before RTM as well.

# re: Quick Web Project System Post

Tuesday, August 16, 2005 2:11 PM by Alex Odintsov
Scott,
1. Would you advise to switch from Beta2 to the latest CTP release? The (deployment/publishing issues are critical for my project)

# re: Quick Web Project System Post

Tuesday, August 16, 2005 4:02 PM by Nick Jones
Scott,

Is there an indication from the team around the User Interface Process block MVC - in particular there seems alot of uncertainty around whether this is going to be the recommended model or whether the new navigation and state management features of 2.0 + 2005 might suggest an alternate path. Sorry, have been looking everywhere for an answer on this, and you seem responsive!

any guides appreciated
nick

# re: Quick Web Project System Post

Wednesday, August 17, 2005 12:07 AM by scottgu
Hi Alex,

I haven't used the latest CTP so can't quite say what is in it versus isn't. If you want to send me mail directly (scottgu@microsoft.com), I could get you access to a more recent build for you to try out. That would be higher quality than the CTP and will have all the concerns I addressed above implemented in it.

Hope this helps,

Scott

# re: Quick Web Project System Post

Wednesday, August 17, 2005 12:16 AM by scottgu
Hi Nick,

You will still be able to use a UIP MVC-like pattern with Whidbey, and I believe the PAG team plans to fully support this going forward.

Having said that, there are a lot of additional site navigation + state management controls that aren't "pure" MVC patterns that are pretty darn useful (and architecturall very clean -- even if some of them aren't 100% clean on the MVC purity test).

My sense is that people will continue to debate back and forth what is the "one right way" to implement UI patterns till the end of time. Our plan is to support all of them so that regardless of which you prefer you have a great story with ASP.NET...

Hope this helps,

Scott

P.S. One of the areas we are looking to invest a lot in with ASP.NET Orcas is workflow and providing ways to orchistrate both site and page workflow using a common workflow design that will also be supported in other scenarios like web-service and messaging flows. We will likely be talking about this more at the PDC this September.

# re: Quick Web Project System Post

Wednesday, August 17, 2005 12:34 AM by scottgu
Hi Jeffrey,

We store web project information in the web project directory itself -- using a directory based model for things like classes, resources, etc. and using the <compilation> section of web.config for compiler specific settings (debug vs. release, language support, assembly references, etc). One beneift of using the <compilation> section is that unifies the runtime+design-time settings, and avoids a lot of the messy issues people run into today with VS 2003 (as an example: 1 out of 2 of every customer apps we typically help investigate through PSS are compiled as "release" apps in VS 2003, but deployed with the "debug=true" flag still set in web.config). Net summary: you shouldn't have any problem having a single web-site referenced in multiple solution files.

In terms of pre-post build events in web projects, this is one area where we don't have as great a support as I would like. Ideally we'd have full MSBuild support that you could store and run in the actual project. Unfortunately we won't have this until Orcas (note that C++ projects are also in this category).

What you can do, however, is create a "build helper" project as part of your solution with your web project. In this scenario you build and store your web app in a standard web project. You then store all your MSBuild rules in the "build helper" project -- which is just a class library project without any classes in it. With this MSBuild file you can do pretty advanced build customizations -- for example, copying user control libraries into your web, compiling and publishing your web app, code-signing, etc, etc. You should be able to completely control the order of any of these "tasks" (so for example: you could do a pre-step, then build 3 separate user control library projects, then copy them into your website, then build the website, then code-sign the output).

Because MSBuild is extensible, I'd expect/hope the community (or maybe Microsoft as samples on the web) to build additional tasks for things like grepping web.config files to verify there are "development settings" left, potentially checking for section 508 compliance as a build step, etc, etc.

You can then run these MSBuild rules both in the IDE, or also from the command-line. This isn't as ideal as storing the rules in the web-project directly, but hopefully the added flexibility that comes with this is worth the workaround cost of creating the extra project.

Let me know what specific scenarios you use pre-post steps for right now in VS2003 and I can see if I can get you a sample that shows how to-do them using MSBuild and one of these "build helper projects" in VS2005.

Hope this helps,

Scott

# re: Quick Web Project System Post

Wednesday, August 17, 2005 2:06 AM by scottgu
Hi Bob,

When you choose the "Open Website" menu option in VS 2005 you'll see 4 tabs -- one for file-system, one for Local IIS, one for FTP, and one for FrontPage Server Extensions (FPSE). You can use any of these tabs to select your project target and open it up as a web project.

If you are building something that relies on IIS v-dirs (or any other IIS specific configuration option), then you will want to open/edit the project by opening the project in VS 2005 using the IIS, FPSE or FTP connection option.

Connecting using the file-system open option will cause the project to run under the built-in web-server, which will not setup the vdirs and allow cross-vdir mapping like you are looking for.

If you connect and run using the other three connection options (anything other than file-system), then VS 2005 will run the app using IIS at development time -- in which cases the Vdirs will work just fine.

In terms of project layout, you can (and in fact must) have a separate web project for each non-physically contiguous vdir in the project (I believe this is the same as in VS 2003). So this should meet what you are looking for. You could have these projects either share a single solution file -- or live in separate ones.

Like VS 2003, you will need to think carefully about how you deploy the applications you build. ASP.NET V2.0 -- like ASP.NET V1.1 -- handles scenarios differently depending on whether a vdir is marked as an "application" or whether it is just a standard vdir. "Applications" can have their own \bin directory and global.asax files. If you don't have these vdirs marked as applications, you will need to copy the \bin directory contents up to the root directory (which is also what you need to-do today). If you can mark them as "applications" under IIS I think you will find this easier to manage/deploy (note: it is perfectly acceptable to have mysite.com/fooapp/login/ be a separate app from mysite.com/fooapp/ -- even though in the namespace hierarchy they are logically part of the same namespace).

Although the VS WYSIWYG designer won't work for some scenarios if you ".." your way up the vdir into a separate vdir or root directory outside of the project, you shouldn't have any runtime issues -- this will work similar to how it does today.

Using Master-Pages is definitely a cool new feature that I'd recommend checking out to use instead of frames for common UI layout. Master-pages do, though, need to live in the application that they are running in to work. One approach would be to have a separate project that you create for your solution that contains "shared UI" like your master pages, and then build a MSBuild rule that automatically copied this into all your web projects anytime you built that project. This would allow you to automate updates of it.

Hope this helps,

Scott



# re: Quick Web Project System Post

Wednesday, August 17, 2005 5:28 PM by Brad
Scott,
I would like to see a clear explanation - perhaps a white paper - of how a developer will manager nested web application projects in VS2005 and the handling of other web folders which should not be included in a project. I know you mentioned some of this in the response to Bob, but I think I and many others are still confused by the concept.

In present day methodology A developer can create web applicaitons at different levels of a web site: example app A is a root web app, app B and C are under the root, app D and E are under C. Typically this is done when there is a logical heirarchy to applications; a root application with others under it is .
obvious
A (a root web .Net project)
|------B
|
|------C
| |
| |--------D
| |
| |--------E
| |
| |--------F (not a .net project...part of C and managed outside of project C)
|
|------G (not a .net project and managed outside of project A)

In VS2003 and earlier, developers typically created and managed their web project via IIS: in other words when they create a web app it is likely created under c:\inetpub\wwwroot (developers who work with many web sites might event have multiple local web sites, but that's complicating things more for the moment). If a developer creates nested web app they basically just specifiy the path within the IIS web site and, voila, they have a nested web application. In VS2003, or earlier, everything is nice an compartmentalized: in the above example project A knows nothing about project B, C, D, etc. And those projects in turn know nothing about the projects above, below or next to them.

After all these years a development team may have a web heirarchy that includes dozens or more of web apps which they've developed and support. Now comes VS2005 which does away with web projects which. Now when you open one of those IIS projects in VS2005 (at least in my beta 2 testing) it is aware of all folders under it, which means it is now including all those iis web projects under it.....again in the above example project A now includes all the files and folders that are/were part of project B,C,D,E,G and G, project C now includes all of the fildes and folders that are/where part of D,E,F (and note: F and G weren't even .Net projects and are managed by different software.

So I'd like to here how, we should be creating, managing these projects under VS2005 and, if possible, a concept on how we might possibly migrate this heirarchy of project we've established under IIS (which may or may not be .Net webs).

(you can probably guess that I'm one of those who whined and pleaded to keep web projects + the exclude folder/files option)

# re: Quick Web Project System Post

Wednesday, August 17, 2005 5:54 PM by scottgu@microsoft.com
Hi Brad,

Based on the fact that two of you have already asked about this, I can definitely see a whitepaper coming in handy on this!

Here is a quick answer:

There are two ways you can map the logical structure you defined above into a physical hierarchy with IIS and VS 2003 today.

Option #1:
--------------

Have a single physical root like c:\inetpub\wwwroot, and then have the sub-applications nested physically underneath it. So for example:

c:\inetpub\wwwroot
c:\inetpub\wwwroot\app1
c:\inetpub\wwwroot\app2
c:\inetpub\wwwroot\app3

Although nested under wwwroot, you still need to mark all three of these directories as "applications" within IIS for them to be interpreted as apps and have ASP.NET support them (otherwise things like the \bin directory and app settings in web.config won't work).

Option #2:
--------------

Have multiple directories on the file-systemm that are peers, and then map their logical hierarchy together using IIS. So for example:

c:\inetpub\wwwroot
c:\inetpub\app1
c:\inetpub\app2
c:\inetpub\app3

Note that from the IIS+ASP.NET perspective, each of the two options are basically equal. The code you write with each of the above two solutions should be the same -- each approach results in multiple ASP.NET applications, and the runtime behavior would be the same (relative paths for frames+images+scripts all key off of the virtual path -- so the physical layout is never looked at).

The dev experience would also be the same -- with probably one master solution and a separate web project to manage each app (like you are doing today).

VS2005 Notes:
----------------

With VS2005, if you want to have separate isolated apps that are not shared within a single web project context (which is what you are asking to continue above), then you'd need to use option #2 to structure your physical directory layout with IIS.

You can then open each separate web-site using VS 2005 (just use the File->Open Web Site option and click to the IIS tab to enumerate and browse them).

With your root application (or any app that has a sub-app or vdir) you'll see all your root content (as expected) in the web-project folder, and you'll see special nodes show up in the web-project listing for each of the non-physically contiguous vdirs/apps in your logical namespace. The code/content within these vdirs/apps *ARE NOT* included in your parent project though -- instead the marker in the hierarchy is there only to let you know that a new app starts at that logical point. So you can build and manage this app separately just like you do today, and maintain the isolation you are looking for.

So, assuming I am understanding your scenario right, you should be able to move your existing VS 2003 physical layout to use option #2 above and not have to change any code. You'll then be able to use both VS 2003 and VS 2005 to open and manage them the same way.

You could also (if you wanted to), have some of the apps map to use ASP.NET V1.1+VS2003, and others use ASP.NET V2.0+VS2005 if you wanted to migrate the projects one at a time.

Hope this helps. Let me know if I've misunderstood your scenario or need to clarify anything more.

Thanks,

Scott

# re: Quick Web Project System Post

Thursday, August 18, 2005 11:06 AM by lynn eriksen
Thanks Scott!

That about does it for me. Looking forward to the final release.

:)

# re: Quick Web Project System Post

Thursday, August 18, 2005 1:57 PM by Bob Archer
Scott,

I am looking forward to the white paper, but just to attempt to make the issues clear, I don't see a difference between this:

c:\inetpub\wwwroot
c:\inetpub\wwwroot\app1
c:\inetpub\wwwroot\app2
c:\inetpub\wwwroot\app3

And this:

c:\inetpub\wwwroot
c:\inetpub\app1
c:\inetpub\app2
c:\inetpub\app3

For me the issue is the IIS layout. We already seperate, at least in dev mode, the apps as seperate physical folders as above. It is the IIS virtuals that are nested:

localhost/approot (c:\approot)
localhost/approot/app1 (c:\app1)
localhost/approot/app2 (c:\app2)

Each application is it's own solution with a web/BLL/DAL projects. We also make each virtual an application so each app has it's own bin. (Although I have been rethinking this due to un-shared session issues this causes.)

My concern was that when I am developing app1 and I try to run it I am pretty sure it will run in isolation, but there are times that app1 redirects to it's virtual root.

I think Brad had the opposite problem as me. He has organized his physical directories to match his virtual directories. So, when opening a file system web site VS 2005 things all folders and files are part of that single web site.

But, it sounds like in both cases the answer is, do NOT use a file system based web app, but an IIS based web app. This will cause the web project to first respect the IIS application boundaries and second to run in IIS so the virutal directories will still exist.

Do I have it right?

My other question is, if I move to using the profile provider rather than session then all apps will see the same data. Is the profile data cached in the application in any way which will still thwart things. Basically the use case is if the user changes there "current" login date in app1, we want app2 to also see this change without having to do an inter module events or use SQL service broker or anything.

Thanks again...

BOb

# re: Quick Web Project System Post

Thursday, August 18, 2005 9:05 PM by scottgu@microsoft.com
Hi Bob,

From your description above, you are using the approach #2 that I described above -- where you have apps stored in separate physical directories that are different from the logical organization:

localhost/approot (c:\approot)
localhost/approot/app1 (c:\app1)
localhost/approot/app2 (c:\app2)

This means you can use the same layout approach with VS 2005 and you do today with VS 2003.

You can continue to have each application have its own solution with web/BLL/DAL projects.

In terms of how to open the site and run it, I'd recommend setting up the webs as IIS configured webs in VS. That way when you run you'll automatically map to the logical layout defined within IIS (no work required).

If you open the web apps up as file-system web, it will default to using the built-in web-server instead of IIS when you run then. This web server won't have knowledge of the IIS mappings -- and so you won't get the logical virtual paths you are looking for, and you'll run into problems.

On your other question -- all of the new application services in ASP.NET 2.0 can be run either isolated per-application, or in a shared store that can be used across multiple applications. So for example, in your case above you can easily have all of the applications configured to use the same Profile store and so be able to share profile data between them. Just make sure that the profile section within your web.config file is configured to have the same connectionstring in each app web.config and you should be good to go.

Hope this helps,

Scott

# re: Quick Web Project System Post

Wednesday, August 31, 2005 2:48 PM by Bob Archer
Scott,

As a follow-up to the above question on Master Pages vs Frames issue. A co-worker makes these comments. I'd have to agree with him. Is there a way to mitigate this issue?

"So you end up sending the menu, header, footer, etc with every page? Normally this ends up looking and performing worse than frame based stuff (since each page totally refreshes) - you also have more problems with plugging in different applications which don't use the master page (such as what we did with XXXX and putting so it looks like its part of the application). I'd need to see it and understand it in more detail before I'd agree with this."

Thanks,
BOb

# re: Quick Web Project System Post

Wednesday, August 31, 2005 10:03 PM by scottgu@microsoft.com
Hi Bob,

Some people love frames, some people hate them. The good news is that you can either choose to use them or not with the above approach. An alternative to using frames would be just to have a master page (note: another alternative would be to use a master page that also contained a frame). My guess is that most people will end up using a master page w/ ajax callbacks within it in the future for handling payload optimizations.

Note that regardless of whether you choose a frame or masterpage approach, you would still want to use the Site Navigation and Navigation control features -- these will work with both frames and masterpages and would help integrate an application much more easily into your overall site structure.

Hope this helps,

Scott