Hi

Can someone explain me the sense of the precompilations model in Visual Studio 2005?? What is the advantage to compile each Web Form separately  (and have for each Web Form a separate DDL) instead of having one global DLL?  I did not read anywhere, what the advantage should be...

Thanks!

Mainly to stop that annoying delay you experence with <2.0 framework.

There are several reasons to consider the pre-compilation tool for ASP.NET

1. In-place pre-compilation means that the site will be primed and can therefore avoid the first time hit penalty in regular conmpilation

2. Pre-compialtion for deployment means that you have 2 new scenarios or potentials for site deployment or packaging. In these 2 modes, you can create a target that can be deployed that has both source and markup files 'removed', or just the source 'removed'. If for example you are shipping an applkication to a 3rd party, then most likely you

'll want to protect source nad markup. If you are simply deploying to production, then it is likely you'll not want actual source code out on the production server. In this case, the markup could remain and allow specific changes, without modifying backend source code, or code behind source code.

Does this make sense?

Simon.

yes, this makes sense...

but, (I don't know how I could explain this correctly), why is now each web form separately compiled? in vs.net 2003, I have one single DDL with all my source code (code behind). in vs2005 I have for each web from a DLL (and for the app_code classes a DLL).

VS2005 uses dynamic compilation because it improves development time scenarios significantly.  At the same time we also provide precompile/publish to address build and deployment scnearios.

At development time, having dynamic compilation provides several benefits:

1) Fast iterative development style.  Developers can now edit a ASPX page or code behind file, hit save, and refresh in the browser.  A user does not have to build the entire web project to run a single page.  With very large web apps and repeated iterations, this becomes a noticeable productivity gain.

2) Better team development scenarios.  Multiple users can now work on the same web site in an easier fashion.  As an example, if certain pages in the website contain errors, a developer isn't blocked on editing, running and debugging other pages in the website.  In contrast in VS2003, you were always blocked from testing any pages until all compile errors were fixed.

In terms of build & deployment and precompile we provide several options:

1) Full compile vs Updateable.  Updateable is similar to VS2003 where ASPX pages are not compiled but code-behind files are.  Full compile provides further benefits of hiding all ASPX code as well.

2) Batch vs. No Batch.  In Beta2, the precompile option does "No Batch" meaning each ASPX page is its own DLL.  We will be changing the default setting to do "Batch" compilation in final release to be more consistent VS2003, where all webforms in a folder get compiled into a single DLL.  NOTE - you will still get multiple DLLs, but they will be per folder, not per webform.  VS2005 doesn't provide UI to control the Batch/No-Batch option, however you can set this via the command line precompile tool.

Hope this helps.

I meant to post this yesterday, but I see Omar has replied too.. :)

In VS2003, the code-behind files and other class files were compiled to a single assembly. There were several drawbacks to this that the new compilation model (outside of the pre-compilation tool) removes. For example:

• Any changes to code behind files required a full recompilation of the assembly and an app-domain restart.
• Team development on separate files or sections of the app was hampered, by the requirement for the assembly
• Aa 'pre-compilation' step that required all code-behind files and class files to be compiled before any pages, independantly of the aspx pages or app
• Development scenarios are quicker
• The new model for code-behind means that the tool does not perform code spit to the code-behind, but is handled automatically during compile time by asp.net. This removes the brtille form of the aspx->code-behind linkage for control ID's and event handlers.
• If you still require the 'pre-compiled' code behind type model, with their results assemblies in \Bin, but their code files removed in the app, then you can resort to the aspnet_compiler, pre-compilation tool as described above.

In the new compilation model in v2, you don't get a single assembly per page either, rather batching of files occurs. There are many inputs however to the algorithms used to drive the batching process.. App_code means that you can abstract out your business objects/classes from the pages and be able to work on this independantly. Also, asp.net performs automatic compilation on this folder for you, without your need to perform a compile. app_code can also be subdivided, if you need to separate languages for example, or have teams working on separate portions of these types. The assembly(ies) generated from app_code do cause app_domain restart and will be linked to all pages in your app too.

hi

thank you both for your detailed post.... now, I understand the whole thing a little bit better.

>>>Batch vs. No Batch.  In Beta2, the precompile option does "No Batch" meaning each ASPX page is its own DLL.  We will be changing the default setting to do "Batch" compilation in final release to be more consistent VS2003, where all webforms in a folder get compiled into a single DLL.  NOTE - you will still get multiple DLLs, but they will be per folder, not per webform.  VS2005 doesn't provide UI to control the Batch/No-Batch option, however you can set this via the command line precompile tool.<<<

Hello Omar and Simon,

Well the default Batch compilation seems to be also necessary for VS 2005 projects.  Make a project that has folders for different groups containing files that have the same name (a fairly common scenario).  Without Batch build you have in the BIN:

App_Web_default.aspx.cdcab7d2.dll
App_Web_wf1.aspx.14a5f0e2.dll
App_Web_wf1.aspx.8940f0e2.dll
App_Web_wf2.aspx.14a5f0e2.dll
App_Web_wf2.aspx.8940f0e2.dll

Now I change and recompile.  Which App_Web_wf1.aspx.xxxxxx.dll belongs to the page I changed?  I have found no way to tell other than trial and error! There is no reference to xxxxx in the deployed aspx page.  If that option is there, is seems to be undocumented.

With Batch build I would at least have a file for each Subfolder.  I would like to test this, but I haven't found the option to enable batch build on the command line.  We are talking about the aspnet_compiler.exe aren't we? 

At any rate, I do not believe that the option to change this behaviour belongs outside of the IDE.

Alle

Pre-compilation in the command-line tool defaults to a batched compilation, (unless using the in-place pre-compilation which uses that defined in configuration). The tool takes a "-fixednames" flag to turn off the batch compilation to provide a one to one page to assembly compilation, and the assembly name is a fixed name from compilation to compilation. The Visual Studio tool in beta2 currently applies that flag.

When using -fixednames, the assembly names are constant, but are given a hash (based on folder structure) to make them unique, rather than trying to use a readable naming structure, as these names can become long and unweildy. You can determine the original file that maps to the assembly by looking at the .COMPILED file in the code-gen directory which exists under your install folder "Temporary ASP.NET files\<appName>\<XXXXX>\<XXXXX>

These preservation (xml) files will show, for the particular page in question, e.g. App_Web_default.aspx.YYYYYY.compiled, where the value YYYYYY is the has in the assembly name too, which originating file it refers too.

If you omit the -fixednames command-line option using aspnet_compiler, then batching will potentially create different file names under each compilation. However, you can still use the preservation files to determine what constitues that assembly.

Hope this helps!

SimonCal wrote:

When using -fixednames, the assembly names are constant, but are given a hash (based on folder structure) to make them unique, rather than trying to use a readable naming structure, as these names can become long and unweildy. You can determine the original file that maps to the assembly by looking at the .COMPILED file in the code-gen directory which exists under your install folder "Temporary ASP.NET files\<appName>\<XXXXX>\<XXXXX> These preservation (xml) files will show, for the particular page in question, e.g. App_Web_default.aspx.YYYYYY.compiled, where the value YYYYYY is the has in the assembly name too, which originating file it refers too.

Simon, thanks for your reply but now having learned this I have to ask a bit more.

Having found the "Temporary ASP.NET" files I see that I have to open each one to find the entry correlating to my directory / file combination.  The old way (rebuilding the entire app and deploying the dll for a small change) was for large sites not nice but this sure isn't very friendly either.  I don't see anyone doing this. The moral of the story is NEVER use files with the same name anywhere in an ASPNET project.

Aside from that, obviously a complete "Temporary ASP.NET" directory, with all files (including debugging PDB files) as large as the compiled project is generated with each publish of a changed project.  Why??  And then why hidden in the Installation Folder.  Obviously, over time this is going to become a space problem where you would least expect it. At least my projects and published projects are where I decide to put them. 

So then I tried the command line aspnet_compiler:

1.  I find the error message "error ASPRUNTIME: Object reference not set to an instance of an object" very misleading when the -f switch isn't used and the target directory is not empty.

2.  After the "batch" complilation I infact only have three dll's (as expected one per folder).  However all of them have the same name (ha, ha) App_Web_xxxxxx.dll where xxxxxx is ......again a hash whithout any reference to the directory.  So now I am really lost and again can redeploy the entire app for changes to one file since according to your description (and my experience now) there are no xml files with the correlation.

3.  Of course I could use the -fixednames switch, but then we're back to the starting point aren't we?

I do not feel this compilation model is "finished & ready" yet.

Alle

Simon,

just to beat you to the punch -

I have just found  that when the site is published as not updateable, then the same xxxxx.compiled files are in the bin directory of the published site and these files specify the path (i.e. folder/folder/filename) and the full name of the dll with hash.

So it's not quite as bad as I wrote.

Alle