New Compilation Modes in ASP.NET 2.0

May 14, 2005 @ 12:20 am

The default deployment model in ASP.NET 2.0 is to compile pages in place. In other words if you specify a CodeFile and the CodeFile exists ASP.NET will compile this file on the fly the first time the page is loaded.

This is the default when Visual Studio creates a new projects and adds pages to the project. So you will have an ASPX page and a .cs or .vb source file that is the partial codebehind file that contains your event and page handling code. The other half of the partial class then contains all the control declarations and event hookups. I talked about this in more detail in my post yesterday. While this sounds a lot like V1.x of ASP.NET there is at least one major advantage here:

The control declarations are generated at compile time not at design time which means they are always in sync – no more issues where a control exists in the ASPX page, but not in the source code.

This also has an impact on compile time behavior. An ASPX page with this new model consists of a base class containing two (actually three) partial classes, and then the actual ASPX class itself which inherits from the combined partial classes. Note however, that the Control and Event Hookup partial class is generated by ASP.NET at compile time so both classes require compile time generated code!

This means it’s not possible to separate out just the compiled code from the ASPX page code as was possible in the ASPX 1.1. Note though that the ASP.NET 1.1 model still works – you can still use the old codebehind syntax just as before, but Visual Studio doesn’t support it by default. If you are using the new model with the compiled partial classes and ASPX inheritance based on them you get basically two compilation options:

In place compilation
Site Pre-Compilation

In place compilation

In place compilation is ASP.NET 2.0’s default which compiles each page in place when it’s accessed for the first time. This applies both to Inline code (ie. Code and HTML markup in a single document) or for ASPX + .cs/.vb source files specified with the CodeFile= attribute. ASP.NET compiles both the ASPX and CodeFile when the page is first accessed.

This model works well for development because in order to run a page you don’t have to recompile anything. If a change is made to the ASPX file or the CS file ASP.NET automatically recompiles both and the page runs.

But there are problems with this approach as well:

Deployment
You probably don’t want to deploy your .cs/.vb source code files on your Web Site. Yet with in place compilation you don’t get a choice.
Checking for Errors
Because pages are compiled at run time, it’s very easy to have errors slip by. To really catch errors beforehand you need to compile the entire project. VS.NET 2005 provides this functionality using the Precompiler along with all the issues that go along with that (see below)

Pros:
Easy to use
Change and run – no compilation whatsoever

Great for development

Cons:

Requires that source code is present and deployed

Security risk
Unwieldy to deploy - you have to make sure ASPX and source file are in sync

A variation of the In Place compilation is Batch Compilation which works by using directives in web.config to automatically compile the site when the first page is hit. This makes the first hit very slow, but all subsequent requests should be a lot faster, as opposed to each page having a first time startup hit. This behavior is essentially the same as ASP.NET 1.1.

Site Pre-Compilation

You can also precompile sites completely by using a new utility ASPNET_COMPILER. You can compile a site in place which basically compiles all pages in to the ASP.NET directory, or you can compile a site for deployment. The former is of dubious use unless you can somehow conincide that with the startup of your application or Web Server. The deployment pre-compilation is what’s interesting.

Basically what this tool does is run through the entire site and build a deployment directory for the entire site. A precompiled site removes all ASPX code and all codebehind code and leaves only a couple assemblies and marker files for each of the ASPX/ASCX/Master files etc. in the /Bin directory. The ASPX pages are stripped of all markup leaving only an empty shell.

The process copies ALL files of the Web into the deployment directory. This includes images and subdirectories. The command line looks something like this:

aspnet_compiler –f –v /whatsnewinaspnet c:\temp\deploy

where –v is the name of the virtual directory on the local Web Server. –f is force overwrite an existing directory. You can also specify a directory or an IIS ADSI virtual directory path (/LM/W3SVC/1/ROOT/WhatsNewInAspNet). The output generated looks something like this for a real simple site:

The root directory and subs contain all the ASPX pages but the pages are all empty except for this notice:

This is a marker file generated by the precompilation tool, and should not be deleted!

Basically ASP.NET requires a file to be present as the ASPX ISAPI scriptmap is marked to verify file existence so the file must exist but all the content is contained in the compiled assemblies in the BIN directory. As you can see there’s one assembly for each page and control/master page etc. plus at least one assembly for the main application.

The compiled files go into the BIN directory. In the image above the compiled assemblies are App_Web.xxxx.dll. ASP.NET splits files up although I’m not sure I see exactly how the splitting occurs. In my simple examples all ASPX pages ended up in one assembly with the master pages in the other. For each page that was compiled there’s also a .compiled file that gets created. This file is another marker file that contains some XML identifying the file as compiled.

</filedeps>

</preserve>

This file serves as a map between the actual ASPX file which contains no information about the class inheritance and the actual class that services the request.

I personally think that this secondary file approach is ugly as hell. This means you have to deploy the ASPX file, the large compiled assembly files plus these Compiled files. Because there are going to be a lot of these there’s a good chance this will cause problems with updating large sites where the assembly might get updated on the site but the Compiled file not until a bit later which is likely to cause failures on the site, if users are accessing files that haven’t been updated yet. Ugggh…

On the upside once the ASPX files are deployed you never have to touch them again. So files to update are localized in one directory unless you add new files.

What’s in the pre-compiled assemblies

The assemblies created are split. I didn’t test with complex scenarios at this point, but in the simple project all the ASPX pages ended up in one assembly and user controls and master pages in another. If you look at the assembly with Reflector you can see the inheritance structure of the I described in my last post. Default_aspx inherits from the _default class which is made up of the two partial classes. Default_aspx contains the page related code which is basically the page parser and any script code embedded on the page. The _default class contains all the control properties and event code. Each page also generates a factory method in the FastObjectFactory class which ASP uses to instantiate the class.

Once compiled the page logic doesn’t look all that different from ASP.NET 1.x which is reassuring. The main difference seems to lie in how the assemblies are compiled until we get to this point.

PreComilation is for full deployment

It seems pretty clear that precompilation is essentially geared at deploying a site in full – it’s not really geared towards a partial redeployment. It’s different than what my scenario in 1.1 typically looked like. In 1.1 I was usually re-uploading just the compiled CodeBehind assembly (and support assemblies). With precompilation, because the filenames are dynamically re-generated for each build you will have to redeploy all files!

Pros:

Secure (you can configure the app to be non-updateable)

Command Line accessible – you can add it to a daily build
No Source code at all on the site
No ASPX code on the site

You can hide your intellectual property

Cons:
All or nothing approach

Creates deployment of Everything
Creates potentially a lot of files to be deployed

Must deploy all at once

Can cause continous service problems as large assemblies are swapped

Can’t compile application that have sub virtuals

CodeBehind Assemblies still work

Actually, there’s a third model which is the ASP.NET 1.x model of ASPX file with a compiled CodeBehind assembly. This of course still works, but VS.NET doesn’t directly support building applications that way. You can still use the same mechanism of pure inheritance just by creating an ASPX page and specifying a Inherits clause to a class that you manually create. Although this is not hard it’s unlikely many people will build applications that way.

You have to make choices

So if you want to use ASP.NET 2.0 approaches you can see there are two very distinct compilation models in ASP.NET 2.0 and you have to make some hard choices over which model to choose. Personally I think both approaches have some serious drawbacks, but if I have to choose between the two pre-compiled deployment is probably the way I have to go on this.

If you find this content useful make a donation

Feedback for this Weblog Entry

# re: New Compilation Modes in ASP.NET 2.0
by Bob Archer May 15, 2005 @ 10:19 am

Rick,

Excellent summary of the two "options". Bottom line I think the "In Place" compilation was strictly for two things:

1. Development cycles. This compilation mode allows you to test page changes without building the solution again. I think this make code / test /fix cycle alot shorted. In addition, I think they had to do this to support edit and continue debugging. Not sure but I tend to remember hearing this.

2. Internal web sites. As you said, if you are selling a web app, you probably don't want them to have all your code. But, I see no problem deplying using this method on internal web sites.

As far as pre-comiling I'm still not sure if I understand what you are saying.

If every time you pre-comile a site the DLL's have different names, won't you start building up alot of dll's that aren't needed in the folder?

As far as the .compiled files, why don't they put that info in the .aspx files so they don't need this extra file. That's pretty weird.

Anyway, I think the bottom line is that many if not all these changes were made to make dev time easier. Since deployment is generally done with a build script (nant, msbuild) and an installer build the over head of having several dll's instead of one and the aspx files being stubs is probably not considered significant.

As always, good information.

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl May 15, 2005 @ 11:49 am

Bob,

I think the pre-compilation is as I said an all or nothing thing. It compiles EVERYTHING and apparently they want you to blow away what you have and copy the new assemblies and marker files in there. From what I see here the filenames for the dynamic assemblies changes on each pass with ASPNET_COMPILER. The part that's also scary is that the compiler failed a lot of times while the VS.NET 'project' appeared to compile fine. The compiler apparently is very finicky about locked files or files in use etc. (like just being in the compile directory).

I think the idea of the marker files is that they need to be updated on every build where the ASPX pages are essentially static. That way everything is in one directory and can be copied in one place. Still I think those markers should be optionally compiled into the assemblies or something especially if the site cannot be updated. The purpose for those is likely to allow modification of individual pages - with precompiled you have to option to update a site.

I'm not sure how much of a problem the marker files are - it'll show once I have some apps to deploy that are more than a few files. I think there will be timing issues with that many required files and files being out of sync while the site is running. While ASP.NET detects changes to these files if they're not there all at once this can potentially cause problems. I had enough problems with this deploying V1.1 apps when you send up 10 assemblies and the site would fail for a few requests while the files where copying and ASP.NET would pick up some of the files

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl May 16, 2005 @ 3:19 am

As a followup it looks like you can get sort of 1.1 compile behavior from the ASPNET_COMPILER by using the -u (updatable) switch which leaves the ASPX page intact:

aspnet_compiler.exe -f -v /virtual d:\temp\deploy\virtual -u

This compiles batched assemblies for the ASPX pages for each directory, plus a separate assembly for master pages plus seaprate assemblies for ASCX files and one assembly for the App_Code files and global.asax.cs etc. Lotta stuff.

Using the -fixednames switch doesn't batch assemblies but creates one assembly for each file.

# re: New Compilation Modes in ASP.NET 2.0
by L.Sorour May 22, 2005 @ 11:05 am

This article as all others I've found, only describes deploying an app to a virtual directory. That's not what should be on a production server. I want to be able to deploy directly to an IIS website.

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl May 22, 2005 @ 11:37 am

You can do that. The deploy mechanism that's built into VS.NET can compile the project into a separate directory, and the automatically FTP or HTTP (with FrontPage extensions) send the data up to a server.

I tried this last night actually to my live site for some demo apps, and well, it didn't go so well. The FTP transfer died about half way through. But I expect that will be fixed by the time they ship.

There are a number of open issues here though. Specifically how will the versioning work. The new compiler creates new dynamic file names each time so if you FTP up files multiple times you end up with dead files on the server.

This whole model has some serious issues IMHO, that weren't thought through all the way. It's a shame because it's close... hopefully some feedback can correct those final issues, but my experience with reporting several of these issues seem to be 'by design' or 'don't have time to change'... grumble.

# re: New Compilation Modes in ASP.NET 2.0
by Herbert Prinz May 24, 2005 @ 12:15 am

It seems the developer totally looses control over the assemblies. What happens if one needs to share an assembly between different applications?

Specifically, I have a web project that serializes objects into files and a C# console project that deserializes these files back into objects for further processing. To that end, both projects must reference the assmbly that contains the object definitions. Works fine in ASP.NET 1.1 and Visual Studio 7, but I can't figure out how I would do this in ASP.NET 2.0 using those "Express" tools that I downloaded.

Herbert Prinz

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl May 24, 2005 @ 12:43 am

Hi Herbert,

I'm still trying to come to grips what all of this means. Sharing of ASPX pages is pretty much gone with ASP.NET 2.0. Gone is any hint of visual inheritance which is definitely a step backwards.

I have to admit though other than the upgrade process working with new pages and apps, it doesn't seem a huge loss. You can accomplish most of this by using smarter design and create a page base class that others inherit from. That class can be reused. Unfortunately this kind of defeats the claim Microsoft makes for an 'easier' model <g>...

FWI, the ASP.NET 1.1 model still works perfectly - you just have to manually manage it as VS.NET no longer creates controls into definitions. You can design pages the same way side stepping the whole code beside model if you need the flexibility.

# re: New Compilation Modes in ASP.NET 2.0
by Edward Jewson June 05, 2005 @ 2:08 am

I'm not too pleased with this new way of deploying websites, I often do minor changes or fix some small bugs and I deffenetly don't want to upload millions of new dll files everytime, but I'm too lazy to go back to the 1.1 model and change things on each new page.

Well lets just hope that MS comes up with a better way of deploying sites.

# re: New Compilation Modes in ASP.NET 2.0
by Mamata Dash June 24, 2005 @ 3:00 am

Hi All,

I've used the Site pre-compilation process to deploy a web project. After pre-compilation I got the required .compiled and .dll files too. But I'm getting the following exception while opening the page:

System.Web.HttpException: The file '/trialWeb/Default.aspx' has not been pre-compiled, and cannot be requested.

The stack Trace is like this:

[HttpException (0x80004005): The file '/trialWeb/Default.aspx' has not been pre-compiled, and cannot be requested.]
System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(String virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) +680
System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, String virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) +1352
System.Web.UI.PageHandlerFactory.GetHandler(HttpContext context, String requestType, String virtualPath, String path) +216
System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, String path, String pathTranslated, Boolean useAppConfig) +3976
System.Web.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +392
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +728

Can anybody help me..

Thanks,
Mamata

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl June 24, 2005 @ 10:27 am

Mamata,

Make sure that a) you didn't get any errors during compilation and b) that you copy all files. depending on which compilation model you used the content of the ASPX file will vary and they are often be incompatibile.

+++ Rick ---

# re: New Compilation Modes in ASP.NET 2.0
by Mamata Dash June 28, 2005 @ 2:10 am

But I've copied all the files generated after pre-compilation. I'm elaborating, what I have done:
I've developed one web project on whidbey, then I've pre-compiled this. After pre-compilation I got the resulting dlls and .compiled files. The virtual directory is: /trialweb and I got all the required files here. Then I directly ran the URI http://localhost/trialweb/default.aspx.

Then why this error is coming???

# re: New Compilation Modes in ASP.NET 2.0
by Darcy Patel June 28, 2005 @ 7:32 am

I am having sort of similar problem as Mamta.
I pre-compiled the application for Deployment using this command: aspnet_compiler -v /MYTEMPDEPLOYSITE -f -p "C:\projects\TEMPSITE" "c:\Inetpub\wwwroot\tempsite"

On the server that I am trying to deploy to I only have .NET 2.0 June CTP compatible framework (v 2.0.50215.312) and all the prerequisites.
When I run the application I see below error...I get the same error through out the all pages that make use of ?.ascx controls
The file 'Temp.ASCX' does not exist.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Web.HttpException: The file 'TEMP.ASCX' does not exist.
Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[HttpException (0x80004005): The file 'Temp.ASCX' does not exist.]
System.Web.UI.Util.CheckVirtualFileExists(String virtualPath) +114
System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(String virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) +154
System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, String virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) +229
System.Web.UI.TemplateControl.LoadControl(String virtualPath) +85
ASPNetPortal.DesktopDefault.Page_Init(Object sender, EventArgs e) +1077
System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +13
System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +45
System.Web.UI.Control.OnInit(EventArgs e) +98

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl June 28, 2005 @ 11:17 am

Darcy,

You should only specify either a virtual or physical directory but not both.

I'm not sure whether anything has changed with the compiler or not since the CTP - I never got around to compiling a final project prior to Beta 2. I would highly recommend you move on to the beta as lots has been fixed and changed in Beta 2. November CTP especially was really unstable with many things broken.

# re: New Compilation Modes in ASP.NET 2.0
by Fritz Schenk June 29, 2005 @ 3:39 pm

I wonder whether you have heard of a problem I got into with the Beta2. I installed on an XP SP2 as required. However, when I rebooted, the CPU load went to 100% and stayed there making my machine unuseable. This apparently had to do with a new process that automatically runs ngen.

# re: New Compilation Modes in ASP.NET 2.0
by Mamata Dash June 29, 2005 @ 11:45 pm

I have
Microsoft .NET Framework Version:2.0.40607.16;
ASP.NET Version:2.0.40607.16.
I have precompiled the web project as follows:
aspnet_compiler -v /trialweb -p "C:\projects\trialweb"

But got the ERROR:
[HttpException (0x80004005): The file '/trialweb/Default.aspx' has not been pre-compiled, and cannot be requested.]

What I've followed is the exact way mentioned in the ASP .NET 2.0 pre-compilation process.

I'm not able to find the exact problem.

# re: New Compilation Modes in ASP.NET 2.0
by Rob July 12, 2005 @ 9:04 am

Hi,
I don't see an easy way to include the precompiled website dlls as part of a Web Setup project. I am using beta 2. The only option for including project output for websites are the content files, not the precompiled dlls. You CAN manually add the dlls to the setup project, but this is not convenient since the set of dlls would change as you add subfolders or web pages to the application. Any suggestions? Thanks!

# re: New Compilation Modes in ASP.NET 2.0
by Bob Archer July 28, 2005 @ 12:04 pm

Rick,

I just read a recent article by Scott Allen at http://odetocode.com/Articles/417.aspx .

It addressed some of your comments like:

"With precompilation, because the filenames are dynamically re-generated for each build you will have to redeploy all files!"

There is a "-fixednames" switch you can use on the compiler to get the same dll names each time.

Also, there is a "-u" switch which creates an Updateable precompile. The article implies that the *.asp? file contents remain in the file so you can updated them without a re-compile.

BOb

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl July 28, 2005 @ 12:50 pm

Bob,

Neither of these options provide a repeatable install. -fixednames produces fixed names for the DLLs but there are .compiled files that get generated new each time. those still have to be replaced. Updateable doesn't fix the precompiler options - other than the source file. The rest of the issues continue to apply except now you have to update both the ASPX and 50 assemblies.

Look at it any way you want.

The current deployment models suck! I'm hoping this will be changed again before release. I haven't looked at the recent CTPs, but I think we're stuck with this fucked up deployment model.

# re: New Compilation Modes in ASP.NET 2.0
by Alex Odintsov August 12, 2005 @ 3:49 pm

Hi guys,
How do I specify compiler's options when I use aspnet_compiler?
For example, option strict should on and in another project it should be off and etc.

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl August 12, 2005 @ 4:59 pm

You don't. Those are code/page options... Compiler options are limited and you can see what they are by running aspnet_compiler without arguments.

# re: New Compilation Modes in ASP.NET 2.0
by Tim Sinnott August 16, 2005 @ 5:59 am

Great information, Rick.
My general need is to develop web applications on my laptop using VS 2005, and then deploy them out to a hosted site. Instead of pre-compiling, as you've described here, I've been successfully using the menu command Build/Publish to deploy my finished apps out to a hosted site.

This has been working fine, very easy. My question is this: What is the advantage of pre-compiling as opposed to using Build/Publish?

Thanks

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl August 16, 2005 @ 10:08 am

Hi Tim,

The deploy feature works as long as your site is completely transferrable from development to live site and if you can deal with the overhead of completely redeploying all files from the local machine to the server. I don't think that most application will fit this model however - there's little reason to redeploy files like images etc. and more importantly if there are file differences like web.config you can't use Auto-Deploy.

# re: New Compilation Modes in ASP.NET 2.0
by Tim Sinnott August 18, 2005 @ 12:06 pm

Rick, it's true, I have only a dozen small images, but in all, they're very small compared to all the other files for the website. My web.config needs only two small changes between my development machine and the hosted server.

Perhaps it takes an additional 20 seconds to tranmit the images every time (I'm guessing). The Build/Publish menu item still seems like the more efficient use of programming time.

Thanks. And thanks for an interesting article here.

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl August 18, 2005 @ 2:51 pm

Tim, as I said this starts to be more of an issue if your site gets larger. I think it's not realistic to push all those files up again especially given slow uplink speeds of many internet connections. Most of my sites aren't very large, but even so the full content tends to be several megabytes. I see no reason to have to send all that up to make a change in one file! It's a waste of bandwidth and time.

Changed files like web.config are big issue too. Even if you're lucky enough to push updates up only once in a while, you still have to remember to make those small changes deploy, then change back. That's a big hassle and a screw up waiting to happen the first time you deploy and FORGET to change your web.config properly.

# re: New Compilation Modes in ASP.NET 2.0
by Tim Sinnott August 19, 2005 @ 6:11 pm

Good points. Thanks, Rick.

# Understanding Page Inheritance in ASP.NET 2.0
by Rick Strahl's WebLog September 12, 2005 @ 1:19 am

Here's an in depth look at the new Page Compilation model in ASP.NET that talks about some of the nice features of this new model as well as a couple of sticking points that may cause problems for applications that migrate from V1.x.

# Understanding Page Inheritance in ASP.NET 2.0
by Rick Strahl September 12, 2005 @ 1:14 pm

In ASP.NET 1.x the primary code model is based on CodeBehind, which uses inheritance and code generation...

# re: New Compilation Modes in ASP.NET 2.0
by Nick Nanson October 09, 2005 @ 4:03 am

Hi Rick. I have tried to precompile a couple of sites in 2.0. It works fine, but it seems like the first request takes a lot of time anyway.

After the first request the site is running fast for all users. But if the site doesn't get any requests for a while, the same problems occur with the "first request". It's take a lot of time.

I thought that the precompile should avoid this time-delay. Any suggestion about this problem?

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl October 09, 2005 @ 12:08 pm

Hi Nick,

No, precompilation merely assembles all the files and compiles the ASPX page source and code beside classes. ASP.NET still has to load the pages and JIT compile them into machine code - precompilation doesn't do an NGEN on the site <g>. It compiles on a per directory basis so if you have a lot of pages in a directory this can still take a long time. Add to that all the .NET framework stuff that has to load and that ASP.NET 2.0 contains 3x as many classes in the System.Web space and you probably have a good idea why startup is still slow <g>... Also make sure you turn off DEBUG mode on the server - that can make things drastically slower as debug information is generated during compile time.

I see no perf improvement in 'pre-compilation' and that's not a problem that this was going to solve...

ASP.NET loads an app into an AppDomain, so anytime the AppDomain gets unloaded - from a Web.Config update, a Web Server cycle, or IIS App Pool Timeout - your app cycles as well and has to go through this startup cycle again. The key is to minimize these app recycles by changing timeouts on the Application Pool (IIS6)...

Although I agree with you on the misleading nature of 'pre-compilation', I think it's not that big of a deal. If your site is not busy enough to trigger App Pool timeouts the start up time is not likely to matter much and if your site is really busy where it matters you'd probably never see a recyle...

# re: New Compilation Modes in ASP.NET 2.0
by Nick Nanson October 09, 2005 @ 12:44 pm

Thanks, this explained a lot.

Nick

# re: New Compilation Modes in ASP.NET 2.0
by Jan November 15, 2005 @ 11:44 pm

hi!

i have many problems with the new .dll files in asp.net 2.0.
first, i have a ComponentArt menue that i have bought in V1.1
i only have a .dll file which i want to take like a reference in my new project.
the application works but i get many errors in visual studio, that the ComponentArt is an unknown element on the .aspx site.

the second is that i have the same problems with old projects that i reference by the .dll in my new project.
because that in 1.1 there are no partial classes?
must i implement all the projects new in 2.0 or is there an other way?

have anybody an idea? or have you a good site which gives an overview about the new .dll compilation?

thanks, and sorry for my bad english.
Jan

# re: New Compilation Modes in ASP.NET 2.0
by Matt January 05, 2006 @ 9:57 am

Make sure the site works without precompilation first. I had a problem where some references were missing and was getting the "has not been pre-compiled, and cannot be requested" error.". I redeployed with updateable files and then got the error.

Microsoft does need to fix this though and throw proper errors.

# re: New Compilation Modes in ASP.NET 2.0
by Michael January 12, 2006 @ 3:20 am

Hey Rick, I have written a web service that I don't need to change that often. How does the pre-compile tool work with web-services vs just regular aspx's files if any?

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl January 12, 2006 @ 1:13 pm

ASMX works the same as ASPX files, so if you still need to precompile or else embed the code directly into the ASMX file and deploy that.

FWIW, that model still works and is the easiest way to deploy simple stuff to a site and now that VS.NET supports editing code directly in the ASPX/ASMX files with full intellisense support this is a viable option. The only thing to watch out for is the security potential...

# Web Deployment Projects
by Paul Wheeler January 18, 2006 @ 9:10 am

Web Deployment Projects (by Microsoft) fixes a lot of the ugliness of the .compiled files and multiple DLLs by allowing you to create a Build file that creates a single DLL for your website.

http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx

Now, if only I could get rid of those marker files...

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl January 18, 2006 @ 9:53 am

Paul,

Unfortunately not. If you compile into a single assembly with Web Deployment Projects you'll still end up with .compiled files, IF you build with complete compilation (ie. no ASPX file content). In that scenario you can kill the ASPX marker files if you don't require the files for Windows authentication.

If you leave content in the ASPX files, not .compiled files are generated, but you obviously have to ship the ASPX files in that scenario.

IOW, one way or another you'll have more than one file - either one ASPX file for each page or .Compiled file - for each page.

# re: New Compilation Modes in ASP.NET 2.0
by Luke Oglethorpe January 29, 2006 @ 11:53 pm

Great article and little app Rick. The new approach by MS is proving to be a real pain but this makes it a little easier and more understandable.

# re: New Compilation Modes in ASP.NET 2.0
by David Grey February 17, 2006 @ 9:57 am

Rick,

In your sample .compiled file there is a hash attribute and a filehash attribute. Do you know how the values in these attributes, particularly the filehash attribute, are derived?

We sell commercial ASP .NET applications and are obviously keen to protect our intellectual property once they are deployed on a customer's server. For this reason we're trying to obfuscate the precomplied assembly (produced by the Visual Studio Web Deployment Project AddIn) using a commerical obfuscation tool. When we run the assemblies through the obfuscator it creates new versions of each assembly and attempts to optimise the size of the assembly, thus changing any has value derived from it. When we deploy the obfuscated, precompiled apps we always get the following error when we access any page on the site:

HttpException (0x80004005): The file xxxxxx.aspx' has not been pre-compiled, and cannot be requested

All the precompiled assemblies work fine when we do not obfuscate them so my theory is that the obfuscated assembly has a different hash or filehash value to that specified in the attributes of the corresponding .compiled file. Do you know if this correct, and if there is any way to determine what the hash/filehash values are for an obfuscated assembly so that we can update the relevant .compiled file?

Examining all the .compiled files for the pages in our assemly reveals that they all have the same value for the hash attribute, but different values for the filehash attribute.

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl February 17, 2006 @ 10:46 am

Hi David,

I'm not sure where the hash comes from but I guess it's based on the file content and the name.

Your best bet is likely going to be using Web Application Projects with the single Assembly being created just as in vs2003. No hashing of that - it just runs.

# re: New Compilation Modes in ASP.NET 2.0
by Dominick Bush March 15, 2006 @ 11:17 am

In looking at the .compiled files that are generated when using the "not updatable" option, I see references to the virtual directory as it exists on the development machine.

I am concerned that the virtualPath is different on the production machine. Is this not going to be a problem?

Example:
<preserve resultType="3" virtualPath="/PLAgent/Agent/Regional/AgentRevenue.aspx" hash="77750bde" filehash="7e393d95a05a061d" flags="110000" assembly="App_Web_agentrevenue.aspx.74f0adb1" type="ASP.agent_regional_agentrevenue_aspx">
<filedeps>
<filedep name="/PLAgent/Agent/Admin/AgentRevenue.ascx" />
<filedep name="/PLAgent/Agent/Admin/AgentRevenue.ascx.vb" />
<filedep name="/PLAgent/Agent/default.master" />
<filedep name="/PLAgent/Agent/default.master.vb" />
<filedep name="/PLAgent/Agent/Regional/AgentRevenue.aspx" />
<filedep name="/PLAgent/Agent/Regional/AgentRevenue.aspx.vb" />
</filedeps>
</preserve>

# re: New Compilation Modes in ASP.NET 2.0
by Wojtek May 22, 2006 @ 4:13 am

Hi , I have precompiled web app; After I've updated the main assembly in bin (I have one assembly for all code behind) there are no changes in asp.net temporary files , Why ???
I don't have set "\" at the end of path in Virtual directory , any one can help me

# re: New Compilation Modes in ASP.NET 2.0
by Jeff July 31, 2006 @ 12:36 pm

if anyone is having the error stating the file ... has not been pre-compiled and cannot be requested error.. i fixed it by removing all unused references and re-publishing. hope this helps

# re: New Compilation Modes in ASP.NET 2.0
by Juan August 15, 2006 @ 7:49 pm

Hi. I've been working with ASP.NET 1.x and I made an application that uses reflection on the assembly that web application generates. Now, I do not have any more this asembly... and my application does not work. Any ideas?
(How can I make ASP.NET 2 compiles like its older version?)
Thanks and sorry about my English.

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl August 15, 2006 @ 10:42 pm

You can't - that just doesn't work any longer, unless you Web Application projects.

# re: New Compilation Modes in ASP.NET 2.0
by Larry August 23, 2006 @ 9:44 am

Has anyone been able to answer Mamata's question? I am in the same situation... I was able to deploy my applicaiton to an XP box but not 2003 Server. On the 2003 servier I get the error: xxxx.aspx has not been pre-compiled, and cannot be requested!

One difference between the XP box and 2003 Server is that the XP box has Visual Studio on it, which is not acceptable for a production server... Can anyone help?

Thank you.

# re: New Compilation Modes in ASP.NET 2.0
by abrar jatu September 21, 2006 @ 4:37 am

how Create dll in asp.net 2.0

# ASP.NET Forums - Master Pages
by Master Pages, Themes and Navigation Controls October 04, 2006 @ 12:09 pm

# Understanding Page Inheritance in ASP.NET 2.0 - Rick Strahl's Web Log
by Rick Strahl's Web Log October 16, 2006 @ 3:00 pm

# re: New Compilation Modes in ASP.NET 2.0
by CutKemist October 26, 2006 @ 8:59 am

UP

Has anyone been able to answer Mamata's question? I am in the same situation...

The error is:
the error: xxxx.aspx has not been pre-compiled, and cannot be requested!

THX a lot for answers

# re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl October 26, 2006 @ 1:11 pm

You shouldn't specify both a physical path and a virtual. One or the other. I suspect the compiler is getting confused on how it's referencing the page if both are specified.

# Каталог, куда VS2005 компилирует вебсайт?
by ASP.NET | Обсуждения @ GotDotNet.ru November 29, 2006 @ 10:10 pm

# ASP.NET Forums - Could not load file or assembly App_Web...
by Configuration and Deployment December 07, 2006 @ 6:14 pm

# New Compilation Modes in ASP.NET 2.0 - dudu - 博客园
by December 10, 2006 @ 8:30 am

# Slow load time after a period of no use - JodoHost Forums
by JodoHost Forums December 27, 2006 @ 8:37 am

We are running a piece of software on jodohost's servers, written in ASP.NET 2.0. When we first hit the website, there is the initial load time. This

# WSS.pl | Forum - ASP.NET i technologie webowe - ASP.NET 2.0 i kompilacja do DLL
by Portal użytkownikow Windows Server System - Aktualności January 12, 2007 @ 10:06 am

Portal społeczności użytkowników Microsoft Windows Server System (Windows Server, Windows SBS, SQL Server, ISA Server, Exchange Server, MOM, SMS) - aktualności, publikacje, webcasty, egzaminy, pliki, porady, społeczności, forum, kulisy...

# n-technologies - .net
by n-technologies January 31, 2007 @ 2:33 pm

n-technologies blog - ordina belgium

# n-technologies - Webdeployment Project in ASP.Net 2.0
by n-technologies March 05, 2007 @ 3:50 am

n-technologies blog - ordina belgium

# re: New Compilation Modes in ASP.NET 2.0
by Dimitry March 26, 2007 @ 6:31 am

Hi Rick,

I'm running into problems when I precompile the website. I left the updateable option intact for the .ASPX files and in some scenarios, I get the following problem:

Parser Error Message: Could not load the assembly 'App_Web_xo2eyvm2'. Make sure that it is compiled before accessing the page

That dll was never created though and does not exist. Most of the time this does not happen though. Can you provide some insight on this?

# wagnerblog.com » VS 2005 Build Options
by wagnerblog.com May 01, 2007 @ 6:51 pm

# ASP.NET Forums - Parts of the application not working after build...
by VS 2005 Web Application Projects May 07, 2007 @ 4:10 pm

# VS2005 Asp.Net senza compilarE? - microsoft.public.it.dotnet.asp | Google Gruppi
by microsoft.public.it.dotnet.asp Google Group May 14, 2007 @ 9:12 am

# Coding mixture: ASP.NET 2.0 - Web Site vs Web Application project
by Coding mixture June 05, 2007 @ 8:41 am

re: New Compilation Modes in ASP.NET 2.0
by John June 28, 2007 @ 1:11 pm

Can anyone please help? I have compiled a website built using VS Express using the ASP.NET compiler, and then uploaded all the files to my hosting provider's server. When I access the page, I get the following message

This is a marker file generated by the precompilation tool, and should not be deleted!

How do I get the site to work? Thanks.

re: New Compilation Modes in ASP.NET 2.0
by Rick Strahl June 28, 2007 @ 1:40 pm

Your application isn't set up to serve ASP.NET 2.0 content. You're either set to ASP.NET 1.1 or ASP.NET is not set up at all.

Don't forget all the files in the BIN directory are required as well.

# Could not load file or assembly App_Web... - ASP.NET Forums
by ASP.NET Forums June 29, 2007 @ 12:57 am

# Converting compile on demand aspx 1.1 to 2.0 - ASP.NET Forums
by ASP.NET Forums June 29, 2007 @ 7:28 am

# re: New Compilation Modes in ASP.NET 2.0
by gazeteler June 30, 2007 @ 10:31 am

Make sure that a) you didn't get any errors during compilation and b) that you copy all files. depending on which compilation model you used the content of the ASPX file will vary and they are often be incompatibile

re: New Compilation Modes in ASP.NET 2.0
by Nguyen Thanh Tung August 14, 2007 @ 5:26 am

I found another way to pre-compile: right click on the website and choose Publish Web Site (this should be good for deployment, it will pre-compile stuffs and remove all .cs files). Thanks a lot.

# re: New Compilation Modes in ASP.NET 2.0
by Trystan February 06, 2008 @ 3:23 am

I had the same error "The file '/(mypage).aspx' has not been pre-compiled, and cannot be requested".

I found this was due to a referenced .dll not being included in the bin directory of the precompiled site, I had to copy it in manually and then it all worked.

Hope this is helpful!

# owner finance contract
by owner finance contract May 06, 2008 @ 12:38 pm

(If you haven\'t left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won\'t appear on the entry. Thanks for waiting.)

# real estate appraisal
by real estate appraisal August 07, 2008 @ 5:16 pm

Posted at 05: 09 PM in Breaking Golf & WaterView Community News , Environmental, Green Golf Community News_

re: New Compilation Modes in ASP.NET 2.0
by Ram February 16, 2009 @ 5:16 pm

Is it possible to inherit a code behind from a different assembly?

The problem I am trying to solve is changing a single aspx file in production without interfering with other pages in the website.
I am attempting to create a new code behind assembly and just change the inherits value in the @Page directive of the aspx file. This does not work.

The following is the example of what I am trying to do and it is not working

The page is TestInherit.aspx
<%--<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="TestInherit.aspx.cs" Inherits="MyProject.TestInherit" %>
--%>

<%@ Page Language="C#" AutoEventWireup="true" Inherits=" TempCodeBehind.TestInherit,TempCodeBehind" %>

The following is the code in TestInherit.cs

using System;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;

namespace TempCodeBehind
{
    public class TestInherit : System.Web.UI.Page
    {
        protected global::System.Web.UI.HtmlControls.HtmlForm form1;

        protected void Page_Load(object sender, EventArgs e)
        {
            Response.Write("response from a new code behind");
        }
    }
}

Compiler recognises the code in a new assembly but gives the following error on a request to
TestInherit.aspx

Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately. 

Compiler Error Message: CS0433: The type 'TempCodeBehind.TestInherit' exists in both 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\esalary\74f57446\27290fd5\assembly\dl3\23bbd53b\5d0495eb_9990c901\TempCodeBehind.DLL' and 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\esalary\74f57446\27290fd5\assembly\dl3\77330854\b714e6eb_9990c901\ESalary.DLL'

Source Error: 

Line 104:    
Line 105:    [System.Runtime.CompilerServices.CompilerGlobalScopeAttribute()]
Line 106:    public class testinherit_aspx : global::TempCodeBehind.TestInherit, System.Web.SessionState.IRequiresSessionState, System.Web.IHttpHandler {
Line 107:        
Line 108:        private static bool @__initialized;

I know there are other ways to solve this problem with various other compilation model but I am very curious why this solution is not working.

I would also like to know why it is not possible to inherit from a class in App_code or what work around needs to be done .

Thanks
Ram

re: New Compilation Modes in ASP.NET 2.0
by Mike April 03, 2009 @ 4:09 pm

Hi,

I'm getting the same error as did David Grey in his post:
"The file xxxxxx.aspx' has not been pre-compiled, and cannot be requested".
I have a working DLL, then I use Dotfuscator CE, to obfuscated the DLL, and when the obfuscated DLL is placed back on the server I get the above error...

I also think it has to do with the fact that Asp.net can no longer find the refrences of the pages in the DLL...however many people do use Dotfuscator on asp.net pages and this dosen't seem to be an issue... rarelly have seen post like this..

Does anybody have an idea regarding this problem.
Bottom line is..How can I obfuscate the asp.net DLL and have the site working!

Regards,

# re: New Compilation Modes in ASP.NET 2.0
by pe3 December 17, 2009 @ 8:09 am

Hi,

I'm getting the same error that many people posted here:
"The file xxxxxx.aspx' has not been pre-compiled, and cannot be requested"

I can't find support on this, I would appreciate somebody's help.
Thanks in advance.
Regards