New Web Project Model Option Coming for VS 2005

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

 

One of the things that we’ve been working on the last few months is a new web project model option for Visual Studio 2005 that we are tentatively calling “ASP.NET Web Projects”.  Our plan is to have an initial preview web-download version of it available for people to install on top of VS 2005 sometime in the next few weeks.

 

The goal with this new project-option is to address some of the feedback we’ve heard from people who are finding migrating existing apps to the new web-site project model in VS 2005 more work than they’d like to-do (especially because of the new web site build semantics of compiling a web project into multiple assemblies).  The new project-type will also help enable some scenarios that web-site projects don’t handle as well today (for example: around sub-web projects where the sub-project isn’t an app in the ASP.NET/IIS sense, but rather feeds its generated assembly to a parent app’s \bin directory to run).  It also provides a model that will feel very familiar/identical for people who don’t want to change how they structure their web projects from VS 2003 today (for example: using a project file, etc).

                                                                                             

This new option does not replace the web-site project option introduced in VS 2005, which provides a lot of new features and flexibility for web apps.  Instead we see it as a companion project-type that you can optionally choose to use instead depending upon the specific requirements of your particular scenarios and your preferred development workflow.  Some developers will find the web-site project model more natural/easy and choose that.  Other developers will prefer a more explicit model and tighter control over their project and choose this new project model option.  Rather than force people into one or the other approaches, we are going to support both workflows and allow developers to choose whichever web project model works best for them, their app scenarios, and their code-base.

 

Some technical information on the new project option

 

The new project model’s project, build, and compilation semantics will be pretty much the same as with the VS 2003 web project model.  Specifically:

 

1) All code within the project will compile into a single assembly (that gets built and persisted in the \bin directory on each compile).

 

2) All files contained within the project are defined within a project file (as well as the assembly references and other project meta-data settings).  Files under the web’s file-system root that are not defined in the project file will not be logically considered part of the web project.  You will also now be able to define classes and types anywhere in the project structure (there is no longer a need to define them under app_code).

 

3) The compilation system uses a standard MSBuild based compilation process.  This can be extended and customized using standard MSBuild extensibility rules.

 

Two of the big changes/improvements we are making over the VS 2003 model are:

 

1) We will not use/require FrontPage Server Extensions (FPSE) in order to open and edit these web projects.  There also will not be any requirement to store your web projects under inetpub\wwwroot.  Instead, you can just define a standard project file for your web project anywhere on disk and add/open/manage it directly (this also means no more .webinfo files and hard-coded http:// paths in the solution file).  This should make organizing and managing your projects much easier.

 

2) We are adding the ability to optionally use the Cassini-based built-in web-server with these projects (alternatively you can obviously also use IIS).  You will be able to create a new web project using this model, add a few pages, hit F5 to compile the code-behinds and other classes into a single assembly, and automatically launch Cassini to run and debug it.  All of this will also work in a non-admin user account (so you can login to Windows and develop as a normal user). 

 

The new model will fully support all of the new VS 2005 WYSIWYG designer changes (no more html reformatting, master page/theme designer support, etc), as well as all the improvements made in the html source editor.

 

Migrating VS 2003 Projects

 

One of the big reasons we are introducing this new project option is to help make upgrades from VS 2003 based web projects much easier.  Because the compile-semantics between the VS 2003 and this new project model are identical (single assembly and project file based), developers should be able to upgrade their VS 2003 projects to this new project-type, do a clean compile, and have everything build without making code modifications or file-changes to their project (the file-layout and code structure stay exactly the same).

 

This will make it much easier to get started with ASP.NET 2.0 and migrate large code-bases quickly.

 

What about code already written for VS 2005?

 

One nice thing about the new project model is that it will also support easily moving individual pages back and forth between it and the built-in VS 2005 web site model. 

 

The code authored in code-behind files can be the same – except that in this new project model the control field declarations are persisted and updated by the tool in an associated partial class file in the project instead of being generated automatically from the .aspx file itself at compile-time.  The approach we are taking with the tool-generated partial class approach is similar to the way Windows Forms persists designer-generated code-spit in VS 2005 (inside an associated .designer.cs/vb file – so you don’t have to worry about the tool clobbering your code).  The good news is that this means that from a developer perspective, you learn one way to author pages and their code-behinds -- and can easily use both web project model approaches with it.

 

What is different is that all code in your web project with this new project model is compiled together into a single assembly – so you can directly reference any classes or types in it.  For example: a standalone class file could directly reference a page or user-control, like in VS2003 (note: this often isn’t a good practice – but now you will be able to-do it). 

 

What is the release plan?

 

Our goal with the new project model option is to make it available quickly for people to take advantage of.  It will be available as a free web-download that installs on top of VS 2005. 

 

Our plan is to have an initial public preview available for people to download and start using in the next few weeks.  This will be an early build that isn’t feature-complete.  Specifically control field generation in the code-behind class and event-wire-up will need to be done manually in this first release (like you do today with VS 2003 if you don’t switch to design-mode to generate these fields/events) – although the core project system, build/compilation environment, debugging, and WYSIWYG page designer support will be there.  We’ll then do refreshes of it as we finish fleshing it out and adding all features.

 

I’ll post more info about the download on my blog once it is available, but I wanted to give people a heads-up now about it coming. 

 

Hope this helps,

 

Scott

 

P.S. Below is a screen-shot of what the new project option currently looks like (with a default.aspx based on a appmaster.master masterpage, and a standalone class all building into a single assembly):

 

 

55 Comments

  • I appreciate not so much the invidual features your team is putting out, some work for me and some dont but the thing that impresses me of late is what appears to be a new found agility and market driven response.



    I am trying to figure out if you are implementing a very different model for introducing new features or are simply in draw down pattern and spitting out some things you wish could have made RTM.



    Right now it seems there is a rather informal discussion occurring through blogs and other mediums about what is needed, if this is simply a draw down phase then such communal conveyance of needs is good enough but if on the other hand this is the new way of doing things then I think we need a more formal and transparent way of pushing for changes.



    Regardless...thanks



  • Hi Scott,



    This new project will facilitate the developer's life. I noticed that the community was confused with new compilation model.



    The new form of compilation introduced on VS.NET 2005 and ASP.NET 2.0 (multiple assemblies), was very complicated for that already they know the "traditional" compilation form, like ASP.NET 1.x, but maybe, they aren't knowing of the benefits of ASP.NET 2.0 (pre)compilation.



    Att,

  • This is great news! I'm very happy about this addition!



    One question though -- what are your thoughts or plans on the designer for user controls in non web projects? In VS2003 you can have a web user control in a non web project and aside from some minor issues it works just fine (one minor issue being that you can't add it from the add item menu, but you can create one manually or copy one in from another project). But in VS2005, at least as far as I can tell, it handles it much less gracefully. For example I can't get it to "link" the ascx and ascx.cs files together so they appear grouped together.



    The reason we use such a project is for developing reusable user control libraries that can be plugged into other web applications. You posted a very nice blog on how to accomplish this with VS2005 but it doesn't feel right having to create a web app project to build a library. I was hoping VS2005 would have a project type (or something) specifically for this.

  • Good deal!



    Although I have many small vs2003 projects I can more easily port to 2005, this will make porting the larger projects much easier.

  • Hi Scott,



    This looks like a great addition...



    But I think you guys need to really think about your message with this. There are now so many options for deployment and project management that it's really hard to explain to anybody who's not familiar with this aspect or new to ASP.NET altogether.



    I just had a discussion with a developer who needed to publish a Web Service - project with just a Web Service, and he couldn't quite grasp how to actually create the actual files to deploy. And I realized, he's right - it's totally non-obvious how to deploy your Web app currently through VS.NET. In VS 2003 it was easy to figure out what needed to get deployed, even if it didn't help in the process of deploying. In 2005 what is on disk is NOT what goes out onto the Web site. There's a big disconnect there.



    Unless you have a good understanding of the new project models (and now potentially the Web Deployment Projects) you'll have to start reading the docs for quite a bit to figure out how to compile and distribute your application. Heck, even looking at a few ASP.NET 2.0 books now there's a single mention of deployment in those books!



    I believe that going back to a more traditional project style - with the nice additions you are mentioning - is the right way to go, because it puts everything into one place logically...



  • Oh wow. This is excellent, amazing, fantastic news and will save me a *huge* amount of work in the coming months. I take back all the curses I've ever heaped on the ASP.NET team over this issue ;)



    Particularly I appreciate the fact that you're using msbuild files for this; it will allow a vast improvement over our current setup which uses a C++ project just to add a pre-build code generation step and then a second class library project to contain the generated code.



    I have a few specific questions about the new (old) model[1], which I'm breaking down into two categories: things that would cause actual, if minor, pain if they were missing (albeit nothing compared to the pain of migration to the current 2.0 model) and things for "bonus points" which would be nice to have but we wouldn't miss if they weren't there.



    Potential Pain Points:

    - Will you be supporting all the same "build actions" as the 2003 model: "Content", "Embedded Resource" and "None"?

    - Will you be supporting the new 2.0 "non-updatable" build configuration with these projects allowing deployment of just the bin folder and web.config?



    Bonus Points:

    - Will Web Deployment Projects work with this setup?

    - Are web-project to web-project references supported? (eg, in your example of a "sub-web" that feeds its assembly into its parent's bin folder, could the sub-web reference the root project and other peer sub-webs (in the easy case at least: all projects in the same solution and no cyclic references)?

    - Does the Cassini server support that sub-web scenario?

    - Does the Cassini server support virtual directories, ie pulling in content from a folder outside the project directory? (If not we can get around this with Junction Points I think)

    - Does the Cassini server support custom error pages with the exact same semantics as IIS? (this on the other hand would stop us from using Cassini, although that's no big deal as IIS is working fine for us today)

    - If using non-updatable builds, can you arrange that *everything* including the ascx/aspx files are built at "ctrl+shift+B" time, thus eliminating most of the first-page-hit penalty after the build completes?



    Thanks again for listening to your customers and providing us with this option! Even if the answers to all these questions are "no", I'm still an extremely happy bunny tonight.



    Stuart (not actually a bunny).



    [1] hey, this is the opposite of Raymond's blog: "the new old thing" ;)

  • Just had a little thought on a possible way to describe the differences in use cases between the two models, especially for projects that are starting from scratch.



    It seems to me that the current 2.0 model is better for building "web sites", but the "new old" model is better for building "web applications". Would you agree with this distinction?

  • Ooh, thought of another question (sorry, when I see exciting news my mind tends to buzz with the possibilities ;) )



    This one may not actually end up affecting us at all (we'll probably be using msbuild tasks instead) but I'm still interested to know the answer. Does the "new old" model support the "Custom Build Providers" feature of 2.0 where the provider is specified based on file extension? And related to my previous questions, if so, can it be arranged that ctrl+shift+B invokes the build providers along with everything else? And if so, how does this integrate (if at all) with the existing VS2003 per-file Build Action dropdown?



    Thanks again,

    Stuart.

  • Hi Dave,



    The good news is that the above project library type will actually do exactly what you are looking for with that (the re-usable user control library).



    This new project type is a flavor of the class-library model in VS 2005 -- so has all of the features of a class-library. Unlike VS 2003, it doen't need to be tied to an IIS vroot via FPSE -- instead you can just save and use the project file like you would any standard class library (for example: include it in a solution with a web project that consumes it).



    It will also do the file grouping for you automatically (so that the code-behind file is grouped underneath the .ascx file).



    Hope this helps,



    Scott

  • Hi Stuart,



    Some answers (to your many questions! <g>):



    - Will you be supporting all the same "build actions" as the 2003 model: "Content", "Embedded Resource" and "None"?



    >>>>> Yes -- the exact same semantics as the 2003 model will be supported (allowing you to set each of these on each file).



    - Will you be supporting the new 2.0 "non-updatable" build configuration with these projects allowing deployment of just



    the bin folder and web.config?



    - Will Web Deployment Projects work with this setup?



    >>>>> Yes (although read carefully). The build semantic of this new web project will be the same as VS 2003 -- meaning it updates the \bin directory in place inside the projct. What you can then optionally do if you want further customization (including the ability to pre-compile the site further to remove the html), is to run the aspnet_compiler + aspnet_merge tasks or web deployment project library on this output to generate a new deployment directory with the bits and the html removed. This will give you what you are after.



    - Are web-project to web-project references supported? (eg, in your example of a "sub-web" that feeds its assembly into



    its parent's bin folder, could the sub-web reference the root project and other peer sub-webs (in the easy case at



    least: all projects in the same solution and no cyclic references)?



    >>>>> Yes, this will be supported.



    - Does the Cassini server support that sub-web scenario?



    >>>>> Interestingly, yes. I hadn't considered that until you asked the question, but it will actually work - provided the project structure is such that one project is underneath the other on the file-system (note: I don't usually recommend that file-structure -- but there is nothing technically to prevent you from doing it). If you want to layout the file-system structure of your solution as sibling directories (which I think is cleaner), then you'd want to use IIS virtual directories to be non-contiguous on the file-system.



    - Does the Cassini server support virtual directories, ie pulling in content from a folder outside the project directory? (If not we can get around this with Junction Points I think)



    >>>>> Cassini doesn't support virtual directories -- instead I'd recommend IIS for that, although you could use the junction point concept instead I guess to simulate it.



    - Does the Cassini server support custom error pages with the exact same semantics as IIS? (this on the other hand would stop us from using Cassini, although that's no big deal as IIS is working fine for us today)



    >>>>> Yes and no. Cassini supports the same ASP.NET custom error page semantics as IIS. But it would have a different way of handling custom errors for non-dynamic requests (static html, etc).



    - If using non-updatable builds, can you arrange that *everything* including the ascx/aspx files are built at "ctrl+shift+B" time, thus eliminating most of the first-page-hit penalty after the build completes?



    >>>>> Ctrl-shift+B will compile all of the code-behind and standalone classes (plus everything else you declare as a buildable resource) -- basically the same behavior as VS 2003. It won't validate/build the .aspx/.ascx files (since these are not part of the project's assembly) -- although you will get full intellisense in them (including C# or VB intellisense for inline code).



    - This one may not actually end up affecting us at all (we'll probably be using msbuild tasks instead) but I'm still interested to know the answer. Does the "new old" model support the "Custom Build Providers" feature of 2.0 where the provider is specified based on file extension? And related to my previous questions, if so, can it be arranged that ctrl+shift+B invokes the build providers along with everything else? And if so, how does this integrate (if at all) with the existing VS2003 per-file Build Action dropdown?



    >>>>> The Custom Build Providers in ASP.NET 2.0 will still work -- but not be included as part of the project assembly. So you can use them inside of pages, but they would be external to the actual code-behind assembly (logically the compile model is just like VS 2003). If you want to compile files into the actual code-behind assembly, it would probably be easiest to use MSBuild extensions for that.



    Hope this helps,



    Scott

  • Hi, this sounds like a good thing - its at least nice to have options of how to structure the projects.



    I do think the variety of names for these options is going to get confusing, as they all sound pretty similar - perhaps some pattern names could be created for the 'model' or structure of development that each one prescribes?



    Two questions... is it possible to target aspnet 1.1 from vs2005 by using a custom build provider which uses the csharp compiler ? and would this be simplified by the new project structure ?



    Thanks

    inoodle.

  • Thanks for listening Scott!



    I really, really can't believe this wasn't one of the original planned features for VS2005 but it's excellent to see you're giving developers the choice they have asked for.



    This is certainly the best post-release news I've had. Well done for listening to the community.

  • Hi Scott,



    You say

    "

    - except that in this new project model the control field declarations are persisted and updated by the tool in an associated partial class file in the project instead of being generated automatically from the .aspx file itself at compile-time."



    It sounds as if this might improve build (not necessarily rebuild) times making F5 quicker.



    Have you found this to be the case?

    Is a quicker F5 one of the reasons for this alternative model?



    Thanks





  • Scott, thank you very much for the answers; I think we'll be able to do some very cool stuff with this model.



    A couple of minor follow-ups:



    "[...] is to run the aspnet_compiler + aspnet_merge tasks or web deployment project library on this output to generate a new deployment directory with the bits and the html removed"



    Would it be possible to customize the project file to actually add these tasks as AfterBuild steps? And furthermore, if I understand the 2.0 model correctly, if I do that then I don't actually *have* to remove the aspx/ascx files (in the dev/testing environment) because they'll be ignored if the DLL exists, right?

  • Thanks for making this available. After going through a couple migration efforts it become rather clear to me that this process would never be simple -- unless for the simplest of the apps.

    Putting the effort to support the "old" class library model shows how comitted your team is to customer satisfaction, despite any personal beliefs or proposed advantages of the new model.

    Going forward I expect to have all my migrations use the class library model and the new projects to follow one or the other depending on the deployment circumstances. Being able to toggle from one to another like you mentioned will be of imense value.

    Again, thanks.

  • Hi Jason,



    When you build with this new option, it won't do the full validation of the .aspx files (which is what the web-site option does). It also doesn't need to parse and generate the partial field types from the .aspx at compile-type (which is also what the web-site option does).



    This produces a build experience like VS 2003 -- where only the code-behind class portion of a page is compiled. One positive affect of this is that it will make clean builds much faster - especially with very large sites.



    Hope this helps,



    Scott

  • This is extremely useful. Thank you for listening to our gripes. I can't say I've ever been more impressed with Microsoft...this was a huge problem for us.

  • Hi Stuart,



    -- Would it be possible to customize the project file to actually add these tasks as AfterBuild steps? And furthermore, if I understand the 2.0 model correctly, if I do that then I don't actually *have* to remove the aspx/ascx files (in the dev/testing environment) because they'll be ignored if the DLL exists, right?



    >>>>> I'm pretty sure you will be able to-do that in one project file (I haven't tried it yet -- but conceptually it should just work since we ship all of the web deployment project tasks as individual MSBuild tasks).



    You'd probably want to be careful to only do this as part of a "release" or "deploy" build configuration and not during standard debug builds (since doing the final compile+merge takes awhile). You can use the VS build configuration concept to control this.



    Hope this helps,



    Scott

  • I'm still studying your post and of course looking to this option's release.



    In the meantime, thanks to you and the team for some great work and paying attention to our pain even after the "final" release. Unfortunately, all these intensive options and differences will add to the training burden. And it will be awhile before the publications track this great stuff.



    So please keep it coming on the blogs!!!

  • Hi Scott, this is great stuff. Looking forward to working with the new project system!

  • Scott, this without a doubt has been the best news I've heard since the 2005 release. Like Allan, we have a large project in 2003 that we weren't even going to touch until June next year because of the complexity involved in migrating to the 2005 model.



    Although I really like the new 2005 model, It was hard to justify the time required to migrate. We'll use the new 2005 model for new projects and use the "new old" model - as coined by Stuart - for migrated projects.



    Your team's rating just when up several notches in my book! Thank you very much for your hard work.

  • Scott, great news, makes my life WAY easier!



    Question (sorry if I missed it somewhere): Do we get to keep edit-and-continue with this model?





    Thanks!

  • Hi,thank you and your team very much for the improvements, will make our lives much easier.



    I posted at asp.net forum asking about the 'copy local' feature and was told to come here and share my input.



    What we have been doing is we have a lot of these gac'd assemblies and they are stored at only one location. The web.config at the root of our website has all these assemblies referenced.



    In vs2003, we have always relied on 'copy local' so then sub applications under this root can reference these gac'd assemblies without having another copy of the same assembly in its bin folder, nor in the web.config.



    In visual web developer, the 'copy local' feature is gone. My impression is i will have to add the reference in each of these sub applications' web.configs. That will work but will add a lot of maintenance time whenever these assemblies are recompiled.



    Please Please put 'copy local' back in the new project model.

  • Hi Wysiwyg,



    Yep -- the copy-local functionality will be fully supported with this new model.



    Hope this helps,



    Scott

  • Hi Nolan,



    Edit and Continue won't work with the initial preview drop, and we will need to continue investigating whether we can make it work in the future. It unfortunately can't work in an IIS environment, since doing edit and continue on a NT Service with a native thread-pool, lots of concurrency issues, and dynamic app-domains is pretty hard/impossible. This is the same reason SQL Server projects don't support edit and continue either (note: VB6 didn't support it for server apps either).



    What might be possible would be for us to enable it for Cassini based projects -- since we have more control over the process then. We are going to look into this further to see if we can make it happen.



    Hope this helps,



    Scott



    P.S. Note that web-site projects do have the dynamic change behavior semantics of an edit-and-continue style development (that is one of the reasons why we introduced it).

  • Will you include nunit capability in vs 2005 professional - I think this is a glaring oversight - nunit functionalty shouldn't be only a part of a team system environment. TDD should be a part of VS 2005 IDE by default.



    Also - I've noticed my web projects want to include files under the web directory that I didn't add to the project. I hope this can be resolved - I have a huge directory of files not in the project that I tried to exclude from the project, but when I created a deployment package it wanted to include it anyway.

  • Hi Steve,



    Unfortunately the built-in unit testing infrastructure is only in the higher-end SKUs - this won't change as part of this new project model option. I personally agree with you that core TDD support should be in VS Standard and Pro as well, but unfortunately that is how the SKUs are currently structured.



    I believe that NUnit and other non-MSFT unit test frameworks will continue to work in those SKUs though. So you could use those with this new project model option.



    By default Web Site Projects (which ship as part of VS 2005) include everything underneath the web-root -- and then you exclude files you don't want to deploy under that (note: the web deployment project includes rich support for this -- including excluding directories as well as files that match a specific pattern like *.fileextension).



    This new web project model supports the inverse pattern where nothing by default is included in the project unless you specifically add it to the project file (this is the same behavior as VS 2003).



    You can the choose whichever model works best for your scenario. It sounds like from your description above this second model might be more appropriate for you.



    Hope this helps,



    Scott

  • Btw, where will you post info about the coming releases of this addon?

  • Hi Jason,



    Speed with both the VS 2005 Web Site project option and this new project option really depend a lot on the specific scenario being measured.



    One of the benefits with the web-site model built-into VS 2005 is that you can incrementally re-compile things at a much finer granularity, and that page code-behind changes do not require an app-domain restart. The scenario you referenced above (5000 pages) where a developer does a clean-compile and then makes changes to a few pages and re-compiles again will actually compile and launch faster with the VS 2005 Web Site Project than VS 2003.



    One downside to the web-site project model, though, is that clean-compile scenarios are slower than a class library project or VS 2003. This is partly because the web-site model is doing a lot more analysis on pages (which is good because it helps find more issues at compile time instead of runtime), which slows things down. Clean-compile performance of 5000 pages in a web-site project, for example, will be much slower than doing a compile with VS 2003 or with this new project model option. Note that a web-project will need to clean-compile anything one of its dependnecies changes higher up in the stack (so for example: a class library it depends on, or a class in app_code) -- so clean compiles can unfortunately happen quite a bit.



    Two settings that you can change to improve the performance of clean-compiles in a web-site project are to:



    1) pull up the properties of the web-site project, click on the "build" tab, and change the start action on F5 from build-web site to just build-page. This will avoid doing a full re-compile of all pages in a project on F5/Ctrl-F5 scenarios, and just recompile/validate those pages used by your current editing scenario.



    2) on the same build-property page of the project, unselect the "build website as part of solution" checkbox. This will change a ctrl-shift-b from recompiling the entire solution web-project (it will still build all class libraries though). You can then map ctrl-shift-w to mean "build-website", and ctrl-shift-p to mean "build page". You can then use these key combinations as you are editing to more granularly control the compilation scope.



    Hope this helps,



    Scott

  • Hi Johannes,



    I'll post more info about the coming release on my blog later this week (probably Friday).



    Hope this helps,



    Scott

  • Hi



    Sounds good , but should have been included in VS2005 by default, have you never had complaints on this in the Beta versions?



    The way it works in 2005 is really a mess for us and have costed us a lot of wasted time/money and you wonder if it's worth the effort.



    As I have a "hybrid" site with both some:

    * old ASP pages (Yes, I know, but there's alot of code to migrate and I can't do that in one day!)

    * Code-generated HTML pages

    * New ASP.NET pages

    * Alot of downloadable images and files

    (Totally + 50,000 non .NET pages spread out in many directories)



    It really is a mess that non .NET stuff is messing up my solution in VS2005.



    Sure, I can start hacking around with Virtual Directories , but that's a mess when I later try to setup the site on some other machines, more things to keep track of and that can break.





    /Andy

  • Thank goodness for the change. It's about time. Thanks again!

  • Hi,



    With the new web deployment add in, it seems we really have 2 serious options for deployment.



    Option 1. Precompile everything into a single assembly with the updatable option unchecked. This gives one dll, aspx stub files and lots of .compiled files (one for each page).



    Option 2. Precompile everything into a single assembly with the updatable option checked. This gives one dll and aspx files still containing code.



    Option 1 is very messy as the bin folder is full of .compiled files, on sites with large numbers of pages this can be impractical.



    Option 2 exposes aspx code and does not provide the benefits of a full precompilation.



    As far as I'm concerned, neither of these options have been terribly well though out. A better solution would be to have Option 1 but without the .compiled files. Then you simply have to deploy a single assembly plus the associated empty stub files.



    Any chance something like this is on the radar to be implemented?

  • Since the control declaration stuff is being changed, would that allow for hooking up Page events and setting properties via the Properties window in the designer?



    This is the biggest flaw in vs2005 for me at the moment. In 2003, you could view the properties and events of the Page (or your custom BasePage) in the properties window, letting you chain up event handlers and set properties without writing code. VS2005 took a step backwards for some reason so now I have to use AutoEventWireup or write code to hook up events with C#, and the benefits of a custom BasePage are reduced....

  • Glad to see this addition. The issue with Bin files being sucked into VSS was really annoying. Based on the blog posts here, it appears that there are many other issues with the web site project model beyond the VSS integration.



    Glad to see a solution is being worked on!

  • I'm very, very glad to see hear this. I am not a fan at all of the new project-less system in Visual Studio 2005...

  • We were really hoping for something like this as there are four or five very large 1.1 projects that need to be ported to ASP.NET 2.0.



    Thanks a lot!!!!!



    Now, I'll just be checking daily for any releases! Can hardly wait for the final version to arrive.

  • Hi Scott,



    Thank you and the rest of the ASP.NET team for all your great work. I had a question about the new project type. The new (old fashioned) single DLL compilation and deployment is not going to adversely affect performance at all, is it ?? The single DLL output of this new project type will perform just as good as the default VS 2005 ASP.NET build scheme, correct ??

  • Hi Rob,



    This new project model option shouldn't have any different performance characteristics from either the VS 2003 model (which is basically the same) or the VS 2005 web-site model.



    Note that this new project model option will also optionally support web deployment projects -- so you will also be able to take advantage of the new pre-compilation features as well.



    Hope this helps,



    Scott

  • Hi Scott



    I'm comming back to ASP.NET after a few years in the java world. I must say that things have changed somewhat from the first versions of both VS.NET and ASP.NET.



    I'm a bit lost with creating a VS2005 project from (origional) WebMatrix code. Previously it had been seperated to simple aspx and codebehind cs files.



    I thought "create project from existing files" would do the trick but I ended up with hundreds of errors trying to compile it for the first time with VS2005. it was having problems with references to classes like system.web.ui, etc.



    I'm obviously not "getting it" so can you sugest any docs on doing this: creating a 2005 project with existing code NOT in a 2003 project?



    thanx

  • Hi Roger,



    The .compiled files we generate are used so that we can map requests to the appropriate classes in the compiled assembly. On the positive side, their names are fixed -- which means they don't change on a per-build basis (so they are less of a deployment headache). On the downside, there can indeed be a number of them generated (although with this model you can delete the .aspx/.ascx files entirely -- so you would end up with the same or fewer number of total files to deploy).



    Like you, I would also like to see a model where you could have 1 .compiled file that contains a list of all refrences (so that you could deploy this in conjunction with the .dll). It is something that we are looking at for the future to-do.



    Hope this helps,



    Scott

  • Hi Scott,



    The new web project model helped to solve the nightmare I was having converting some of my VS2003 projects. However, i still do not get ASPNET_Compiler to work with the ASP.net Web Application. I keep getting duplicate name messages when using ASPNET_Compiler.



    Is it correct to assume that ASPNet_Compiler is not upgraded as yet to support ASP.Net Web Application type in the patch?



    mp

  • Hi Mrinal,



    Can you provide more details on the duplicate name message you are receiving?



    We haven't updated the web deployment project to also work with web application projects yet, but it sounds from the error message that you might be running into a solvable issue right now.



    Thanks,



    Scott

  • I have a feeling that you'd see the compile times go way down if somebody at Microsoft tried to figure out why aspnet_compile.exe causes my hard drive to thrash mercilessly even though I have 2.5 GB of RAM and am RAM optimized for disk cache... I have a suspicion that HD access times are causing much of the compile slowdown. Notice that normal cs.exe compilations cause very little HD access are almost instantaneous.

  • What I'd really like to know is if the "new" (VS2003) project style will support the ASP.NET 2.0 "precompilation" so that sites don't have that startup delay.



    Specifically, it would be really nice if people could drop a setting into their web.config file that would make precompilation happen automatically whenever the site restarts (file change, etc). That way the site is always running fast except for immediately after a change.

  • Hi Tony,



    The "new" (VS2003-style) project model will enable you to use the new ASP.NET 2.0 pre-compilation features. The next release of the Web Deployment Project download will also support the "new" project model as well -- meaning you can automate pre-compilation, as well as configuration setting deployment changes using web deployment projects in the IDE.



    We don't support pre-compiling in place on a server -- since as part of pre-compilation we end up removing the HTML and packaging things up. You also wouldn't get much of a performance win doing it that way -- since ASP.NET always persists the generated assemblies on disk regardless of whether precompilation is used or not (so ultimately the compile cost would be the same if you did it on first hit). Where we think pre-compilation makes more sense is at development time.



    Hope this helps,



    Scott

  • Hi Michael,



    aspnet_compiler.exe actually does a number of things more than standard compilation -- which is why command-line builds aren't as speedy. Among other things, it is generating multiple assemblies and parsing/generating output based on the control layouts on pages -- hence the reason it hits your disk pretty hard.



    Hope this helps,



    Scott

  • THANK YOU. This is the biggest thing I've been b*tching about since I saw the first alpha of 2005 before the PDC 2003. In fact, this is the biggest complain I've heard from every dev who's gone from ASP.NET 1.x to 2.0. THANKS for finally listening to us!!!

  • Oh, maybe I didn't make it clear with my last post. Thanks sooo much. You've returned me (and many others, I know!) to the state where we can't talk about ASP.NET/VS2005 without sounding like we've been paid off by MS. Yes, you've now sugar-and-honey coated our lips and we will once again sing ASP.NET praises!

  • Hi Scott,



    you said that web-project to web-project references are supported in VS2005, but it doesn't work for me... It only allow me to add references to Class Library projects.



    What am I missing ?

  • On Thursday, December 15, 2005 10:56 AM, Rob wrote: "Since the control declaration stuff is being changed, would that allow for hooking up Page events and setting properties via the Properties window in the designer? This is the biggest flaw in vs2005 for me at the moment. In 2003, you could view the properties and events of the Page (or your custom BasePage) in the properties window, letting you chain up event handlers and set properties without writing code. VS2005 took a step backwards for some reason so now I have to use AutoEventWireup or write code to hook up events with C#, and the benefits of a custom BasePage are reduced.... " Is it true? Is there no easy way anymore to set for example properties on a page which was inherited from a BasePage? In the properties window? Or somewhere else? It is vital for a solution we are working with. We have built in some functionality that will make it easier for our designer to just set properies on a page, rather than having to set it by code. Since we migrated to VS2005 we can't see the properties in the properties window anymore. Any solution? Help would really be appreciated, /Pernilla

  • Hi Pernilla,

    You can still definitely have properties on your BasePage that inherit to the page below.

    Here is a useful technique that you can use to have your designer set these: http://weblogs.asp.net/scottgu/archive/2005/08/02/421405.aspx

    Hope this helps,

    Scott

  • Hello Scott,

    I am just starting with 2.0, but I was surprise to seel all the rrors after conversion.
    I am pretty sure you are addressing the issue of partial classes and inheritance from different base pages. We have base pagess for different secions of the web site. So how do we change ineritance on a partial class? It was pretty easy to derive from our base page and make all the pages "Is a" base page, how can we do this with partial classes and do you have a good reference for conceptual definition of partial classes. Interface = "Can d", inheritance = "Is a" what does partial class is conceptually? and how can you program "is a" (inheritance) and "can do" in opartial classes?

    Thanks

    Luis

  • Hi Luis,

    Sorry for the delay - I've been on vacation the last week.

    There are two web project options in VS 2005: the "web site" project option and the "web application" project option.

    To make upgrading as easy as possible, I'd recommend using the "web application" project option. Above you were trying to use the "web site" one instead.

    You can get the "web application" project option either by installing VS 2005 SP1, or - if you haven't installed SP1 yet - downloading the separate "web application" project add-in. You can learn more about how to use this here: http://webproject.scottgu.com.

    Hope this helps,

    Scott

  • anyone working with it in regular basic?
    how does it work in real task?

Comments have been disabled for this content.