I've been trying to configure a standalone ASP.Net application beneath a Sitecore web root (more or less as outlined here: http://sitecoreblog.alexshyba.com/2009/05/standalone-apps-under-sitecore-web-root.html). It's almost successful in that the virtual directory runs, but in the /sitecore folder, the rich text editor no longer works. Here is the error it throws:
'~/Telerik.Web.UI.WebResource.axd' is missing in web.config. RadScriptManager requires a HttpHandler registration in web.config. Please, use the control Smart Tag to add the handler automatically, or see the help for more information: Controls > RadScriptManager.
It works fine when I revert back to the original configuration.
Does anyone know how to properly configure this?
More info (1):
So, in the sitecore web.config, at the root, I added:
location path="." inheritInChildApplications="false" above the sitecore, system.webserver, and system.web nodes. The non-sitecore app I was attempting to run works great when I do this, but it somehow creates the Telerik.Web.UI.WebResource.axd I mention above, in the /sitecore folder, mostly when using the rich text box.
More info (2): This happens when I make these changes to the web.config in the sitecore root. While attempting to fix the problem, I did make a few changes to the web.config files in the /sitecore folder (including deleting them). but it made no difference. I've since restored the /sitecore folder to it's original configuration.
The standalone app is running as a separate app, immediately off the root, so: http://mysitecoresite/mystandaloneapp.
I had the same problem. After much searching, this fixed it for me (using v7.2 rev 140228): http://docs.telerik.com/devtools/aspnet-ajax/controls/scriptmanager/troubleshooting/overview#telerikwebuiwebresourceaxd-is-missing-in-webconfig-radscriptmanager-requires-a-httphandler-registration-in-webconfig
You have to set the EnableHandlerDetection property where it is declared on the Sitecore .aspx pages. I found it on EditorWindow.aspx and EditorPage.aspx.
<telerik:RadScriptManager ID="RadScriptManager" runat="server" EnableHandlerDetection="false"></telerik:RadScriptManager>
Related
I've opened an existing web application project from Visual Studio 2013 (which runs just fine), in Visual Studio 2015. When I run it from within Visual Studio 2015 I get:
Active Server Pages error 'ASP 0131'
Disallowed Parent Path
/blah/login.asp, line 1
The Include file '../includes/Security.asp' cannot contain '..' to indicate the parent directory.
My IISExpress applicationhost.config file already contains the entry:
<asp appAllowClientDebug="false" appAllowDebugging="false" errorsToNTLog="false" enableParentPaths="true" scriptErrorSentToBrowser="true" bufferingOn="true">
<session allowSessionState="true" />
<cache diskTemplateCacheDirectory="%SystemDrive%\inetpub\temp\ASP Compiled Templates" />
<limits maxRequestEntityAllowed="1073741824" />
</asp>
My web application properties are set to use IISExpress.
What could I be missing?
The 'applicationhost.config' has moved and is now located in the hidden .vs folder. Make sure you're updating the right file.
Here is a much clear explaination although the accepted answer is in the right direction.
Since VS2015, IIS Express has changed where it picks up your applicationHost.config file. This is presumably to simplify the distribution of projects. It has moved away from the traditional C:\Users\<profile>\Documents\IISExpress\config\applicationhost.config folder (although this file will still exist on your computer to support older VS installations).
It is now located in the application project's root folder as a hidden file. To save you hunting for it, here is how you open it quickly and easily:
Right click IIS Express from the tray icon and select Show All Applications.
Click on the URL entry of your application. The "Path" and "Config" values then are shown as hypertext links further down in the IIS Express window.
Click on the Config hypertext to open on your preferred editor. (e.g. C:\<Path-To-Project>\.vs\config\applicationhost.config)
Hope this helps.
I wanted to add my version of a very similar answer because I still had to do some searching to get the expected end results. Although the original question just really wanted to know why the current config that was being used was not working and it was in fact explained in the accepted answer, it did not help someone like me coming into the question. I needed to know everything to do in order to achieve allowing parent paths when debugging. So here is my answer in detail...
How to configure the IIS debug server in Visual Studio 2015 to allow parent paths:
First you need to find the IIS Express tray icon.
Next you need to open the IIS config currently running for debugging by right clicking on that tray icon. You will then see the following context menu. You will need to click on "Show All Applications".
This will then show you the configurations of the IIS debug server you are running. There will also be the project you are working on listed in this list.
Click the projects name (in this case "Web") under the Site Name column. You will then see the Path of the project and the Config file being use to run the debug IIS server. You will then click on the Config path to open the applicationhost.config in your default text editor.
This will open up the config file you are using when debugging your project. You will need to scroll down until you find the <system.webServer> section. Then look for the <asp> section. In my case it was <asp scriptErrorSentToBrowser="true">.
Then you just need to edit the asp section to include enableParentPaths="True" as shown in the image below.
The just save the file and restart the debugging process. Note: I only had to hit F5 in the IE browser to see the change. I did not have to close the browser and restart the debug process over again.
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.
I have a config file linked from web.config e.g.
<features configSource="feature.config" />
When I make changes to the "feature.config" file the IIS application appears to restart, is this expected behaviour?
Yes, this is expected behaviour by default as typically any changes made to the web.config will cause an application restart however this can be overridden for app.config files. From the msdn:
Saving a Web.config file restarts the
application. You can alternatively use
the configSource attribute of
individual section elements to point
to a secondary configuration file that
does not cause an application restart
when it is changed.
Although you have moved some of your configurations into a linked config file they are still effectively part of your web.config file and any changes made there will have the same effect as if you made the change directly in the web.config file itself. However you can specify a section to not restart the application on change by using the restartOnExternalChanges attribute in the section definition. See here and here for further details. However, according to the documentation this is not valid for ASP.NET applications which makes the above statement a little misleading.
I'm using a web deployment project in order to precompile my ASP.NET 3.5 web project. It creates a single extra DLL for the code in aspx and ascx files. And, for every aspx file there is a placeholder aspx file (empty) which needs to be copied to the server.
I'd like to simplify the deployment process. Is there a way (configuring the IIS site and adding some sort of http handlers etc.) to get rid of these aspx placeholders?
Also, I'd like to know if there is a way to get rid of the .compiled files in the bin folder. It would make the deployment process smoother.
Thanks!
I discovered it by myself. It is much easier than I thought (IIS 6.0):
In Internet Information Manager go to the property page of the site, then chose the tab "Home Directory" and click on the button "Configuration...".
Click "Edit..." for the .aspx ISAPI extension and uncheck "Verify that file exists". At this point, no aspx file is needed anymore.
Update
One important thing: I had to create an empty "default.aspx" file in the root of the application in order to allow the default document for requests like "http://www.example.com/" (without calling an aspx).
Update 2
Another very important thing: if you're using ASP.NET Ajax PageMethods, then you have to keep the aspx placeholder of that page. If you're omitting the file, a javascript 'PageMethods is undefined' error will be thrown on the browser.
IF it is possible, then it will require, at the least, the mapping in IIS of all possible requests to the asp.net engine. Not very difficult. Then, a HttpHandler should be possible to intercept all incoming requests. That handler should then be able to dynamically load compiled page classes and render them. You'd basically have a single engine DLL that serves page content.
But as you might have noticed from all the should's, it's not a simple thing to accomplish, and I doubt that it's really worth the trouble. What exactly is wrong with these placeholder files being present?
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.