How to fix ASP.NET error “The file 'nnn.aspx&#

Question

I have a VS 2005 web site that I publish using "Publish Web Site", and I clear all the three checkboxes. I also have a deployment project that picks up the published files and creates an MSI. I then install the package on a separate test server.

In other words, the whole site is pre-compiled. However, when I go to any .aspx file in a specific subfolder named "Services", I get an HttpException:

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

If I go to an .aspx file in an other folder, be it the root or other subfolder, it works properly.

The contents of mypage.aspx itself is: <%@ Page Language="C#" AutoEventWireup="true" CodeFile="mypage.aspx.cs" Inherits="Services_mypage" %>"

In the /myapp/bin folder I can see a mypage.aspx.989dc2fb.compiled file. The content of this seems to point to a certain assembly that is also present in the bin folder.

Why is this error occurring? The .compiled file is there, and the assembly is there, and the type in question is present in that assembly (I can see it in Object Browser). Is it something about the name or the content of the .compiled file? Do I have the wrong version somehow? What does the seemingly random number in the .compiled filename mean and is it important?

I also want to mention that this issue appeared suddenly, and I'm not sure what changes there can have been done since it worked properly a few days ago (but to the best of my knowledge, none).

Answer 1

For me, I had a script that deletes the production folder and then copies up the new files.

The script failed to delete the production folder properly leaving that the old and new files were mixed in together causing the error.

I manually deleted the entire folder and redeployed successfully...then updated the script.

Answer 2

Just as a footnote to all of the above answers that resolved the issue via republishing to replace a missing assembly... While i have solved this issue previously with that same solution, i have just encountered another reason for it's occurrence which may assist others.

The AppPool that my site was running under had it's "Enable 32-bit applications" setting set to false. By changing this to true via the "Advanced Settings" dialog of the app pool i resolved my issue.

Hope that helps some other poor sucker.

Answer 3

I know the error is complaining about something else but I promise in my case the problem was just the insufficient Access permission(Network Service or Application Pool identity or IUSR) for asp.net account to work with that specific file.

it was due to unusual deploying and mixing bin files with new published ones in our VPS environment.

solution:

that specific file permissions need to be replaced with correct Bin folder permissions like other files that are working correctly(and wo that error) inside Bin.

Answer 4

I've not had that error, but after a little Googling I came across this link, I'm not sure if you've seen it yet: http://forums.asp.net/t/956297.aspx

Edit (adding the key text):

This error will come when a reference is specified in web.config and deployment folder/site does not contain these dlls installed in the system or bin folder does not contain them(if they are private assemblies). For Example: (add assembly="Namespace1.NameSpace2, Version=x.x.x.x, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/) if your web.config contains any assemblies like this and deployed server doesnot contain these assembiles in bin or GAC, then this error will occur.

People were reporting that missing assemblies on the destination server ended up being the root cause, in their cases, but they had the same error as you. Weird.

Maybe that's the problem?

Answer 5

I ran into the same issue. My problem was fixed by deleting the files in the temporary asp.net files folder in this map:

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root 

Answer 6

In case of a update and then recompile. copy all the files from bin folder again and also the particular file updated from its respective folder.