A big part of the web site is precompiled and merged, since it's almost never going to change. The precompiled bits can be replaced in case of updates to the original. I want to continue development of new pages, but when I browse to a new page I get the following error:
The file '/Website/Test/Default.aspx'
has not been pre-compiled, and cannot
be requested.
Is there any way around this?
Edit:
If I remove the precompileApp.config file I get the contents of the marker files when I browse them:
This is a marker file generated by the precompilation tool, and should not be deleted!
Have you looked at the precompile with updatable UI option? This compiles all the source code and resources into a DLL but allows you to continue making changes to your .aspx pages after deployment.
Another option could be to precompile the website in place on the server instead of precompiling it then deploying it to the webserver.
Both options are addressed in this MSDN article:
http://msdn.microsoft.com/en-us/library/bb398860.aspx
Related
I am currently getting this when visiting my http:// websitehere.com/excelData.aspx page:
This is a marker file generated by the precompilation tool, and should not be deleted!
The file system directory on the server looks like this:
--mainDir
|--excelData.aspx
|--PrecompiledApp.config
|--Web.config
|--bin
|--App_Web_cuydkh1j.dll
|--exceldata.aspx.cdcab7d2.compiled
Not sure what I need to add/remove in order for it to display my page without that precompilation tool text on it.
The IIS server is version 6.1
One of the reasons for this problem is the file PrecompiledApp.config is missing from the root of your site (this file is generated by the publishing wizard).
Hope this help others.
Problem:
When you upload the web application, sometimes the most important files in the bin folder (e.g., the .dll files) will not upload correctly.
Solution:
Re-upload the bin folder. Remember to overwrite.
Make sure the site is configured as an application on IIS
I've inherited an ASP.NET project that uses a single Default.aspx file in the public_html root to do most of the work.
The changes I'm making are minor, but I can't seem to get them to stick. If I edit the Default.aspx file, the server will still serve the old version. Creating a new .aspx file will initially compile it and run it, but then it's stuck in its "original request" form.
I thought .aspx files were subject to "dynamic recompilation" if they were changed, but this isn't triggered in my case. I've tried updating the Web.config file but is has no effect.
I'm not using Visual Studio for this, yet. I'd like to be able to just edit and update the files, if possible (the changes are very minor and I don't have ready access to a Windows machine). The only access I have to the server is through FTP.
Seems the issue was with my host, who aggressively cache stuff. I have to do a "restart" from inside their control panel to have the changes reflected.
The host is Loopia.se, in case anyone else is using them. Use "Omstart av ASP.NET-applikationer" from inside the Customer Zone to restart things.
(Yes, I do feel kind of silly now)
If the site has previously been 'published' in visual studio as pre-compiled and not-updatable, then changing the aspx files will result in no change:
http://msdn.microsoft.com/en-us/library/1y1404zt(v=vs.80).aspx
In this case everything will have been pre-compiled into DLL's, and the aspx pages are just there as hooks for the .net runtime.
So I have a website project, which I precompile when I publish.
I have a question, when I need to make a small change to the deployed site, do I have to rebuild, re-publish and deploy the entire website structure again, or can I just copy the modified aspx page and the bin directory?
Please let me know!
Thanks guys!
It is going to depend on how you did the precompiling of the site.
According to MSDN, if you did a precompile for deployment, the process takes aspx files and processes any internal code in them, so you will need to recompile everything.
If you did a precompile for deployment and update, the aspx files are not taken into consideration, so provided all you did was some UI changes, you can push the updated aspx file up without issue.
You should be able to republish locally and then copy up the modified published pages and the bin folder.
You shouldn't need to upload everything.
If you pre-compile epending on the options you have chosen you may be able to edit the .aspx page i.e. HTML code, but not the code-behind..
If the .aspx pages become just placeholders i.e. they are empty inside except for a single comment, you cant.
Simple question. If you have a compiled and published ASP.NET web application running on a server and you need to update, say, a line in one of the codebehind files. Do you shut down the entire site, republish, then load the site back up? Or do you publish straight to your live site with users still using it?
For myself, place an app.offline app_offline.htm file into the site, then overwrite the entire website with the latest published build.
there are a few options when building a site -> one dll for the site or one per page. if u just updated one line in a code behind, and you have chosen the build option for one per page, then you can just copy/paste that new page dll.
i don't like that method personally. I find it simple to app_offline.htm the site.
If it is a single file and a simple site that uses that app_code folder to store the code behinds, I simply xcopy up the new files. If I use http expiration headers I may need to do some better scheduling to make sure things like javascript files and css sheets match the rest of the site that was updated.
For emergency patches:
If its just a codebehind file, I copy the entire /bin/ out and replace all DLL's (mostly out of habit)
If its an aspx, I just copy the aspx.
For actual deployments, I have an automated system that checks out the code from source control, builds a clean release build, takes the site offline, and then robocopies it out to the deployment target. Its a one click process (Thanks CruiseControl!).
I'm using a pre-compiled ASP.NET 2.0 site (i.e., copied to the server using the "Build->Publish Web Site" feature in Visual Studio 2005). I catch and log all errors which are usually quite detailed, but lately I've been getting the following error with no other information:
Could not load the assembly
'App-Web-rp2eml-j'. Make sure that it
is compiled before accessing the page.
Now, that 'App-Web-rp2eml-j' file should be a dll in my bin folder which was created for the pre-compiled site. My main question is, how do I tell what aspx page is looking for that dll? I've tried re-publishing the site, and even completely wiping out the site and re-publishing, but the problem does not go away.
When Googling the problem, most answers about this error message center around making sure IIS is set up to use ASP.NET 2.0 instead of 1.1. This is not my problem.
NOTE 1: The site all seems to work, but obviously there is (at least) one page that is broken which I cannot find.
NOTE 2: The file name above should have underscores instead of dashes, but SO's markup is changing the text between the underscores to italics.
Does the mentioned dll exist in your bin directory? You italicized that portion so I suspect that it doesn't. That could mean that the error is referring to a dll in the Temporary files folder.
This problem can occur if one or more of the dlls in the ASP.NET Temporary files folder are corrupted. Sometimes ASP.NET does not refresh files here if there are no changes in the dll residing in the virtual directory. It happens every once in a while on my server.
My solution is as follows:
Stop IIS services on the server for a minute or so.
Navigate to the ASP.NET Temporary files folder (usually located at "%windir%\Microsoft.NET\Framework\\Temporary ASP.NET Files\MyApplicationName") and clear all files within the folder.
Publish and upload my site to the configured virtual directory.
Restart IIS and other services.
This simple 4-step process has worked very well for me in the past and may be worth a try for you.
To answer your basic question, however, there are two ways to "reverse engineer" a dll:
Load it up in ILDASM and check the contained classes.
Use Reflector to save all the class files contained within the dll to a folder.
However, I doubt if this will solve your problem because each dll could contain many class files and you would not have a clue as to "which ASPX page is looking for that dll".
Maybe you can catch more detailed information on the error with the Global.asax event Application_OnError, so you can watch the stack Trace.