I have a WebApp with an upload section.
To upload the files to a sql database I'm using a Ajax Toolkit Fileupload control.
I always get a similar error as in this post, but after hours of testing, I figured out what is causing my Problem.
My upload control is located on the SidDetails.aspx page and if open the page directly
with
foo.com/Pages/SID/SidDetails.aspx
I'm able to upload files.
but if I access the page via the route
foo.com/SID/My/1
I get a 500 internal server error
So I checked the link of the page that is causing the exception
foo.com/SID/My/1/?contextKey={DA8BEDC8-B952-4d5d-8CC2-59FE922E2923}&done=1&guid=BD327457-2013-1E97-6ADE-28612D63758E
For me, it looks like that is the problem, but I don't know how to fix this.
I already tried adding a route with query value
But i don't know if this is how you would approach it.
Could not find a part of the path 'C:\Windows\TEMP_AjaxFileUpload\E0E386A6-F5B5-1012-F6E5-1872E4D6EF69'.
Thats the exception that is thrown by the upload control.
I would like to keep the routes but how can I fix the problem?
I'm using Visual Studio 2012, .net 4.5 and AjaxControlToolkit 7.0930
Kind regards
CarnVanBeck
I run into this too, and after going crazy I fixed it.
Download the ajaxtoolkit source code project and open it.
Change the following row:
this._uploadUrl = 'AjaxFileUploadHandler.axd';
to:
this._uploadUrl = '/AjaxFileUploadHandler.axd';
Rebuild the project, get the new .dll and copy it to your /bin directory.
This will fix the issue, giving the right path to the handler.
PS: I came to this as:
I noticed some strange duplicated calls to the handler, happening only in routed paths
(like www.site.com/projects/edit/mypage), where uploads failed.
I noticed that in a test page, placed in the home dir of my site, the uploader was working fine.
Then I came to this page and noticed the mentioned row.
If your app is running in Integrated Mode pool, you have to add this lines in the web.config file:
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<handlers>
<add name="AjaxFileUploadHandler" verb="*" path="AjaxFileUploadHandler.axd"
type="AjaxControlToolkit.AjaxFileUploadHandler, AjaxControlToolkit" />
</handlers>
<validation validateIntegratedModeConfiguration="false"/>
</system.webServer>
Related
I am trying to teach myself an IIS handler on Windows 10, IIS 10. Naturally, I started with a tutorial
MS Tutorial
It's old, but I can find nothing newer that is this comprehensive, and has the information gathered into one place.
The simple class and function is this:
using System;
using System.Web;
namespace IISHandler {
class MyHandler : IHttpHandler {
public bool IsReusable
{
get { return true; }
}
public void ProcessRequest(HttpContext context) {
DateTime dt;
String useUTC = context.Request.QueryString["utc"];
if (!String.IsNullOrEmpty(useUTC) &&
useUTC.Equals("true")) {
dt = DateTime.UtcNow;
} else {
dt = DateTime.Now;
}
context.Response.Write(
String.Format("<h1>{0}</h1>", dt.ToLongTimeString()));
}
}
}
I created the assembly in VS 2015, and everything looks fine. Until I tried to "deploy" it. Then everything falls apart.
I've been digging for three days now. None of the information is in a single place. I will cover what I have done.
First thing, is to copy the DLL into the /bin folder of the web application. That's fine.
Then Use the "Add Module" option in IIS Manager. Well, at the default level it gave me this:
Okay, I'm not adding this to the General assembly. All I want is a custom handler in my Web App.
Next, paying closer attention, I am adding it only to one Web App.
The tutorial says that the Add Module will discover it. Well, that didn't happen. I've got a list of things that appear to be "Built in", but not the DLL I created from the tutorial.
So I manually just typed in the name "IISHandler.MyHandler", which is the namespace (assembly) and the class name. Then IIS Manager tells me this:
No amount of web searching has given me any clue how to deal with it.
Next up, I decided to dig into the web.config file. Of course the MS page tells you that you can get all the detailed information... sometime in the future.
(This was published in 2008. But I've got such low expectations from MS doc, nothing surprises me)
I did manage to find a few other resources on the web.config. So while attempting to get a masters level degree in IIS XML Config files, I have zeroed in on the following file contents:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="MyTest" path="example.time" verb="*" resourceType="Unspecified"
modules="IISHandler.MyHandler" preCondition="integratedMode" />
</handlers>
</system.webServer>
</configuration>
All this should do is intercept a page request "example.time", and return the current time according to the original C# code in the tutorial.
The response has been perpetually this:
It's not telling me it can't FIND the module, only that it's bad. But with Microsoft, there's no telling what the real problem is.
I tried (unsuccessfully) to just set module="IISHandler" even though that wouldn't make sense, as something still needs to know the class to invoke. I was right, it still didn't work.
And continuing to search, all over the web there were suggestions to execute this command (which didn't make sense as the "features" were already added through the control panel):
%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i
That gave me an error:
(Telling me to install .NET 4.5 on my IIS 8 is just another MS deficiency)
My Add/Remove features for IIS 10 doesn't show 4.5 But it does show 4.8
Is that significant? I have no idea, and can't find any documentation.
I have also insured that the AppPool is set to "Integrated", and this Web app is in that pool
But my choice is only .NET 2.0 or .NET 4.0... And yet the Add/Remove offers me 3.5, and NOT 2.0? My assembly is build in .NET 4.8 (I retried in 4 as well... no luck). And there is no 4.0 as an option in the Add/Remove under IIS 10.
What is the kludge of 2.0, 3.5, 4.0, 4.5, 4.8??
But the real core on my question is:
What is the process to get IIS to recognize my C# assembly and simply process a simple custom handler?
I hope this is enough information that someone can offer some assistance.
TIA
-SpacemanScott
Ironically enough, a fellow (remote) worker was trying to solve this same issue. He informed me he got it working a few hours after I posted this.
Here is the web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<modules>
<add name="MyModule" type="IISHandler.MyModule" />
</modules>
<handlers>
<add name="MyHandler" path="example.time" verb="*" resourceType="Unspecified" type="IISHandler.MyHandler" />
</handlers>
</system.webServer>
</configuration>
Although I still do not have the masters or PhD degree in IIS XML config files, the specific difference is that the <module> was added, and the "type" attribute was added to the <handler> to indicate the specific handler function.
Also the "module" attribute was removed from the <handler>, although this page seemed to indicate that was how the server knew where to find the module that provides the handler. Apparently not.
The <module> is used to handle all requests during the processing sequence, and since that ability was not desired, it was not hand entered. But apparently it is still necessary to tell the configuration that you will be using that assembly module.
If anyone runs into a similar problem, perhaps this will help.
We have created an Azure web app. We want to use this app to enable our site visitors to download appxbundle of our UWP app. We are able to put the files on the folder and can see them through FTP. However as soon we try to access the files by just typing the resource URI in the browser it throws an error at us stating:
The resource you are looking for has been removed, had its name
changed, or is temporarily unavailable.
I tried putting the file in the root directory as well but the error remained the same. From this blog we know that it can be done but somehow we are not able to make it work. Any idea how can we make it happen?
Turns out that MIME types need to be explicitly copied into the web.config file. You can check for these in the Visual studio as well but if you want to configure it manually then make sure you add the following lines to your web.config
<system.webServer>
<staticContent>
<mimeMap fileExtension=".appinstaller" mimeType="application/xml" />
<mimeMap fileExtension=".appxbundle" mimeType="application/vns.ms-appx" />
<mimeMap fileExtension=".appx" mimeType="application/vns.ms-appx" />
</staticContent>
</system.webServer>
Adding this snippet got us through the access error mentioned above.
Yeah, that's a regular case of MIME types.
Add the following to the section of your Web.config:
<staticContent>
<mimeMap fileExtension=".appxbundle" mimeType="application/xml" />
</staticContent>
Alternatively, try it with mimeType="application/octet-stream", depending on whether you want it to be downloaded or "inlined" (which for .appxbundle, i don't know what it means, maybe kick off install/open Windows Store?)
More on mimeMap here.
I have been working on a new intranet site for a few weeks now, and everything has worked as expected. If I made any changes whatsoever (added raw text, new controls, etc) to my .aspx pages, and then tested them in VS(F5), all changes would be reflected immediately in the browser. Anything as simple as adding a <br> tag or as complex as adding a set of nested controls would show up upon a debug restart.
Earlier today, everything was working. Then I decided I wanted to play around a bit with some of the AjaxControlToolkit goodies. I ended up installing the SP1 Update 2 for VS that was released today (http://www.microsoft.com/en-us/download/details.aspx?id=38188) while I was at it, as well as updating NuGet and installing the AjaxControlToolkit from there.
I added a couple tools, including a ScriptManager and an UpdatePanel, and everything worked as I expected. I then went to make a few changes, and added a second ScriptManager accidentally. When I went to debug/run, it of course failed because you cannot have more than one on a page, so I removed the extra one and ran again. It again gave the same failure. I went through and made sure I didn't accidentally add another one somewhere, did a search on all files in my project and it was the only instance of it, so I commented it out and ran it again. Same thing. I tried a few things and ended up restarting IIS and VS and then the page behaved as expected.
Since that point, any changes I make in ANY of my files in the project no longer update without exiting IIS and restarting it. New, very basic aspx or html files in the project do the same thing. I then reverted to the restore point before updating VS, and used a backup of my site from earlier in the day before I added the AjaxControlToolkit, and still, the problem persists.
What is going on here? I feel like its related to the VS update, but that doesn't really seem to make sense. I can't see such a major bug being overlooked? Why isn't IIS serving the updated page?
Ctrl+F5 in browser does not reflect changes. Rebuild of entire solution does not reflect changes. Closing and reopening browser does not reflect changes. Changing my web.config does not reflect changes. Creating a brand new empty web site and the problem persists. Change to Visual Studio Development Server instead of IIS, problem persists.
The only way I have found to force the correct, updated page to serve correctly is to "Stop Site" in IIS and then restart, which is simply way too much of a hassle to check minor changes to anything in my page.
I am using Visual Studio 2012 Express, IIS Express, .NET 4.0, C# code-behind, files are on an intranet file system (mapped to x:), separate from my actual production hosting server.
Just in case (though I don't think it matters since the problem is now occurring even with a fresh web site) here is my web.config (which is very basic):
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.0" />
<customErrors mode="Off" />
<httpRuntime />
<pages>
<controls>
<add tagPrefix="ttw" src="~/Controls/CustomerInformation.ascx" tagName="CustInfo" />
<add tagPrefix="ttw" src="~/Controls/CircuitInformation.ascx" tagName="CktInfo" />
</controls>
</pages>
</system.web>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-UA-Compatible" value="IE=EmulateIE9" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>
Any suggestions would be greatly appreciated, and I hope a solution will aid others who may be experiencing the same issue after this most recent update.
Sounds like a permissions issue. Either the mapped network drive is using credentials that don't have adequate permissions or the IIS app pool identity doesn't have permissions to the folder.
I have a project that works with bundling when you run it from within visual studio. However, after you do a deployment, the bundling handler never seems to pick up the route. It ends up going to the static file handler instead, which returns a 404 response.
Any ideas? I see the optimization assembly in the bin of the website under IIS.
It's using the 4.0 app pool and integrated mode.
I'm wondering if anyone has any ideas or suggestions?
Thanks
----- update based on questions -----
VS2012
targetFramework="4.5"
I also added some code into the view to show which modules were loaded and I can see the bundle module listed there.
BundleConfig is the default provided when using the Internet Application MVC4 project template.
The site is being deployed into the root. It's odd as when I set EnableOptimizations = true (due to running in debug mode via visual studio F5), it works perfect! I can navigate to content/css and it spits out the combined css.
I deploy it over and everything else works, but bundling!
I've just hit (and solved) this problem.
Make sure your bundle's virtual path can't be confused for an existing directory or actual file name. In my case, I'd coded it as:
bundles.Add(new ScriptBundle("~/bundles/main.js").Include( ...
But when I changed it to
bundles.Add(new ScriptBundle("~/bundles/main").Include( ...
it all started working.
Updated Answer on 11/17/2013
This is caused by the fact that the default MVC routing only handles * instead of * . *, i.e. IIS or IIS Express's applicationhost.config has the following:
<add name="ExtensionlessUrl-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" responseBufferLimit="0" />
So to workaround it, we can add the following to the web.config:
<system.webServer>
<handlers>
<add name="UrlRoutingHandler"
type="System.Web.Routing.UrlRoutingHandler,
System.Web, Version=4.0.0.0,
Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"
path="/bundles/*"
verb="GET"/>
</handlers>
</system.webServer>
For more information, you can reference the following:
http://weblogs.asp.net/owscott/archive/2013/01/16/handing-mvc-paths-with-dots-in-the-path.aspx
ASP.NET MVC Url Route supporting (dot)
Old wrong answer:
Basically, DOT is generally not allowed in virtual path when IIS parse URLs.
This a Link mentioned the following URLScan AllowDotInPath parameter:
By default, this option is set to 0. If this option is set to 0, URLScan rejects any request that contains multiple periods (.). This prevents attempts to disguise requests for dangerous file name extensions by putting a safe file name extension in the path information or query string portion of the URL. For example, if this option is set to 1, URLScan might permit a request for http:// servername/BadFile.exe/SafeFile.htm because it interprets it as a request for an HTML page, when it is actually a request for an executable (.exe) file with the name of an HTML page in the PATH_INFO area. When this option is set to 0, URLScan may also deny requests for directories that contain periods.
Even I got the same error.
Adding <modules runAllManagedModulesForAllRequests="true" /> under <system.webServer> in web.config file solved the problem.
I had the same problem even with sample MVC application. I saw the default template bundles the style-sheet with css name which i guess IIS does not likes resulting in 404 error.
Changing the bundle name from css to APPCSS will resolve the issue for me.
I'm trying to figure out how to use MiniProfile to see why some webpages are going so slow.
I've added it in, and have added Steps around Application_BeginRequest, Application_EndRequest and around my Controllers action (in the image below that is the CanManageOrganization and GenerateTreeDataSource). But as you can see below those two methods run relatively quickly. After that there is a large gap until GetVaryByCustomString is called. How would I go about trying to figure out what is going on (where the time is being spent)?
My understanding is that the actual rending engine is what would be going on in that section? Am I incorrect here? Any suggestions on how I can figure out what the time in-between is spent doing?
I would recommend you to install the MiniProfiler.MVC3 NuGet which will give you more specific details about MVC. Yoju will see time spent for finding and rendering views as well.
Here's a sample of what you might see:
Remark: with the latest version of the NuGet if you are hosting your application in IIS7 Integrated pipeline mode or IIS Express locally you might need to add the following handler to the <system.webServer> section:
<handlers>
<add name="MiniProfiler" path="mini-profiler-resources/*" verb="*" type="System.Web.Routing.UrlRoutingModule" resourceType="Unspecified" preCondition="integratedMode" />
</handlers>