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>
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.
In my ASP.NET 5 application, I generate a drop-down list thanks to the HtmlHelper. Anything works fine in localhost except in production, we have a 500 server error.
I was able to find the cast which is performed, on github, and it's performed into the MVC lib, precisely into the DefaultHtmlGenerator class :
This cast is performed when we want to render a drop-down list depending on the SelectList we pass in parameter.
We can see that the comment specify we have to use at least the version 4.5 of the framework. At the end of the stacktrace we see the version of the framework which is used in production :
However, the version 4.5 is installed on our server, and I tried to insert a web.config file into the wwwroot of the projet to force the target framework :
But it doesn't work, and we indicate correctly the framework we want to use into our project.json :
So my question is : can we use compilation targetFramework="4.5" and httpRuntime targetFramework="4.5" to force IIS for using the version 4.5 ?
NOTE
You are trying to run in IIS managed code. You can't do that. IIS doesn't manage the process anymore. Basically, IIS is going to run an EXE and is going to forward requests to it. That's it.
Check the procedure bellow to properly deploy a DNX application to IIS. Or better, read the documentation right here: http://docs.asp.net/en/latest/publishing/iis.html
Requirements
Windows 7 or better
Windows Server 2008 R2 or better
Have IIS installed
Procedure
First, make sure you have the HTTP Platform Handler installed in your IIS (x86 / x64).
Publish your application to the file system and take the content of the \artifacts\bin\MyWebApp\Release\Publish folder and copy it into your IIS Server.
When configuring your application, target the wwwroot folder that you copied over.
Now you'll need to unlock the system.webServer/handlers section which can be found in IIS Manager on the server node under Configuration Editor. Search for the right section and unlock it from the right action pane.
Make sure that the App Pool is set to No Managed Code. DNX is being run as an external process. IIS doesn't need to know about what it's currently running.
Finally, create a web.config with the following content:
<configuration>
<system.webServer>
<handlers>
<add name="httpplatformhandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" />
</handlers>
<httpPlatform processPath="..\approot\web.cmd" arguments="" stdoutLogEnabled="false" stdoutLogFile="..\logs\stdout.log" startupTimeLimit="3600"></httpPlatform>
</system.webServer>
</configuration>
It should be running at that point.
Source
We are currently using VS 2013 to develop asp.net (silverlight) applications for multiple environments (dev/test/quality assurance/prod), and are currently using web transformation functionality when we publish builds.
We have some lines that are extremely long in the master web.config (as in 400+ columns). We realize that for readability sake the proper approach should be to split these into multiple lines, but in our particular case we would prefer that they remain long as they are.
So, the problem is that if you publish and point to one of the publish profiles utilizing a web transform, the resulting Web.Config file will not retain the one long line. During the transformation it is automatically split (word-wrapped) across multiple lines for easier readability. I understand why Microsoft does this, but I thought for sure there would be a simple setting somewhere where we could disable any "automatic formatting", "auto word-wrap", etc.. However I have not had any luck finding it.
Another way to see the behavior without going through the trouble of a full publish would be if you right-click, for instance, Web.Test.Config, under the main Web.Config entry in solution explorer, and select "Preview Transform". Here you will be able to clearly see how the transformed version is auto-formatting and putting line breaks in place for lines in the main Web.Config that goes past a certain number of characters. We would like to turn off this behavior if possible...we only want actual values changed/transformed, not the formatting.
Does anyone know if this is possible, and if so, how to accomplish it? Was it just some simple setting we missed?
Finally - a couple of quick examples. If I run a "preview transform" to preview changes when transforming from our main Web.Config to our Web.Test.Config, I see the following behaviors:
this line in the main web.config:
<add verb="*" path="Reserved.ReportViewerWebControl.axd" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=XXXXXXXXXXXXXXX"/>
gets turned into this in the final published web.config:
<add verb="*" path="Reserved.ReportViewerWebControl.axd"
type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=XXXXXXXXXXXXXXX"/>
and this line in the main web.config:
<sessionState timeout="300"></sessionState>
gets turned into this in the final published web.config:
<sessionState timeout="300">
</sessionState>
thanks in advance for any help at all you can provide.
You can disable automatic formatting/line breaks in Visual Studio 2013's Web.config transformation by adding the following attribute to the element in your Web.config file: xml:space="preserve". This will preserve the white space in your Web.config file during a transformation.
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>
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.