Quick Web Project System Post

23 Comments

• 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)?
  

• Thanks for the update, Scott. Much appreciated and looking forward to trying it all out.
  

• 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
  

• Clear and concise, great post.
  

• 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
  

• 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!
  
  

• 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
  
  

• Great post, thanks for the clarifications Scott. Looking forward to your follow-up post soon.
  

• 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
  

• 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.
  

• Scott,
  
  1. Would you advise to switch from Beta2 to the latest CTP release? The (deployment/publishing issues are critical for my project)
  

• 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
  

• 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
  

• 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.
  

• 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
  
  
  
  

• 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
  
  
  
  
  
  
  
  

• 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)
  

• 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
  

• Thanks Scott!
  
  
  
  That about does it for me. Looking forward to the final release.
  
  
  
  :)
  

• 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
  
  

• 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
  
  

• 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
  

• 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