I am trying to use mini profiler with WCF.
I keep getting a 404 error:
http://website/mini-profiler-resources/results
There are no results being returned.
I am using two versions of the mini profiler. The NUGET version which doesn't include support for WCF works just fine.
I downloaded the git version so that I can use the WCF integration.
I note that if I run the test project included in the sources 'Sample.Mvc' the same error occurs when the home page is executed, but not for some of the links. I cannot seem to get results for any of my own web site pages. The same 404 occurs.
I have downloaded the master version. I am using .NET 4.0 and studio 2010.
I have the following in the config file, I have tried with and without the handlers.
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="true" />
<handlers>
<add name="MiniProfiler" path="mini-profiler-resources/*" verb="*" type="System.Web.Routing.UrlRoutingModule" resourceType="Unspecified" preCondition="integratedMode" />
</handlers>
</system.webServer>
I am definitely calling the start and stop methods.
StackExchange.Profiling.MiniProfiler.Stop();
I have read this: MvcMiniProfiler results request giving 404 in Asp.Net MVC app
It did not help.
I have found a clue as to the problem
The following code in miniprofiler is returning NotFound
The profiler is expecting some kind of guid value to be present, and it isn't.
private static string Results(HttpContext context) {
// this guid is the MiniProfiler.Id property
Guid id;
if (!Guid.TryParse(context.Request["id"], out id))
return isPopup ? NotFound(context) : NotFound(context, "text/plain", "No Guid id specified on the query string");
temporary fix
I took out the code above, and just collected the first guid out of storage, and this fixed the problem. I think this code needs cleaning up. I need to learn GIT, and then try and clean it up myself.
var id = MiniProfiler.Settings.Storage.List(10).FirstOrDefault();
Can you see .../mini-profiler-resources/results-index ?
Handler not required btw. There is a comma in your link but assume that is just a question typo.
Are you calling start last thing in the Application_BeginRequest() and stop in Application_EndRequest()
Have you set GlobalFilters.Filters.Add(new ProfilingActionFilter());?
and are you using WebActivator with a MiniProfilerPackage and MiniProfilerStartupModule
Think I need to tidy up my own implementation as looks like I have some unnecessary cruft.
Related
I have an ASPNET Core project that is running a set of RESTful services using C# and Newtonsoft.JSON 11.0.2 which I incorporated using NuGet. When I run everything locally using Visual Studio 2017 and IIS Express, things work fine and my JSON Deserializer efforts work with no issue.
When I publish the solution in a Web Deploy package and then install that application in IIS 10 on a Windows Server 2016 instance in AWS, the deserializer fails. The error is:
Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: <. Path '', line 0, position 0
It does not matter if I publish in Debug or Release mode.
I ran Postman calls and the JSON being returned is both validate and produces the correct objects. I did see that, in the Solution Explorer, the version is 11.0.2 but in the assets JSON file, the version is pointed to 10.0.1. The .CS project file, when viewed in a text editor outside of Visual Studio, does show 11.0.2.
When I look in the deployed application's folder on the server, I do not see any NewtonSoft DLLs but I do see other NuGet-obtained DLLs. This might not be an issue given how JSON.NET deploys but I thought it was worth mentioning.
I then included a logger and sent the incoming JSON to a file and, again, it all validated as expected.
I have tried everything, ensured CORS is properly implemented both in the application and in IIS. I am at a complete loss as to how to proceed.
Can somebody please help?
Thank you!
I had the same problem and solved by this code in web.config
<system.webServer>
<handlers>
<remove name="WebDAV" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
<modules>
<remove name="WebDAVModule" />
</modules>
</system.webServer>
I sometimes browse old question that has no/accepted answers and check if they are still in need of some help, or if something can be done to close the cold case.
This post has already been solved, but the cause and the solution were left only in the comments.
If the first character encountered when parsing is <, you can be sure
that is not JSON. Something is probably sending XML or HTML to your
code in the deployed environment. I would look at that angle. This
doesn't seem like a version conflict to me, otherwise you would be
getting a much different error about not being able to load the file
or assembly. I think this is solely a data problem.
Brian Rogers
#Brian Rogers - Thank you SO MUCH for this last comment. I ended up
opening Production to my development machine and then running
Wireshark to see the communications. Turns out that IIS had "GEWT"
instead of "GET" in the allowed methods web.config for the host
website and I was getting rejections in the cloud instead of the JSON.
Every test I ran which generated output was LocalHost but, of course,
none of the real production work used anything local. Once I fixed
that error, everything worked great!
Ken Tola
#ken-tola, can you please self-answer the question and then accept it to close the case.
I need to log errors for an asp.net mvc windows application which also uses entity framework and for doing this i thought of using ELMAH.
My App.config file contains the appsettings for providing folderpath and other file related details.
Now when I try to add the configuration (elmah...../elmah) for ELMAH after installing it in my project it throws an exception "Configuration system failed to initialize".
But when I remove that code then it works fine.
Please provide me the solution to log errors for MVC windows application.
And the final question is ELMAH.mvc free to use or not?
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="folderpath" value="~PA\FileImport"/
<add key="XMLFolderPath" value="~\FileImport\XML"/>
</appSettings>
<connectionStrings>
<add name="####" connectionString="############"
providerName="System.Data.EntityClient" />
</connectionStrings>
<elmah>
..........
</elmah>
</configuration>
It sounds like there's a problem with your ELMAH configuration, since ELMAH and EntityFramework normally doesn't interfere with each other. I would recommend you to follow a tutorial like this: ELMAH Tutorial. There's a ton of tutorials for ELMAH outthere, why a simple google search will find a lot of resources.
If following a tutorial doesn't work, you should probably add some additional information and web.config code in this thread, since figuring out your problem from the amount of information, is almost impossible.
To get some diagnostics for our MVC4 application (with an WebRole for Microsoft Azure) we installed Glimpse through NuGet.
Everything went fine, but when I enable Glimpse through the ~/Glimpse.axd page our application is completely unreachable. On every request we get the message "This Webpage is not available" (Chrome).
In the output window in Visual Studio 2013 I saw an error message which suggests to disable async support through the web.config:
<appSettings>
<add key="Glimpse:DisableAsyncSupport" value="true"/>
</appSettings>
Unfortunately this is not helping. When we turn off Glimpse everything is just fine.
How can I find out what the problem is?
Update
The logs shows me this warning:
WARN | Unable to locate '</body>' with content encoding 'Unicode (UTF-8)' for request. The response may be compressed or the markup may actually be missing a '</body>' tag.
Found my solution on the troubleshooting page of Glimpse.
In short, url compression was applied so had to disable this in the web.config:
<system.webServer>
<urlCompression doDynamicCompression="true" dynamicCompressionBeforeCache="false" />
</system.webServer>
I have an ASP.NET MVC 4 application running under IIS 8.5. My previous understanding/experience of these scenarios in MVC is that if a static file exists, it will be served. If it doesn't exist, the path will be sent through MVC routing. This is the desired behaviour, but doesn't seem to be happening.
By default if I create a catchall route at /blah.html and no corresponding static file, IIS serves up a 404 (courtesy of the StaticFile handler). The MVC route is never hit. If the file exists, it is served.
So, I did some Googling and chatting to colleagues and came up with the answer as posted here:
https://stackoverflow.com/a/14327897/1043198
In goes the handler:
<add name="ApiURIs-ISAPI-Integrated-4.0" path="*" type="System.Web.Handlers.TransferRequestHandler" verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" preCondition="integratedMode,runtimeVersionv4.0" />
Great! The request now hits the MVC app and my dynamic content is served as expected. Except now, when I put a physical file in place, I get an error again. An uninformative 500 error with the following information (and nothing else):
Module: ManagedPipelineHandler
Notification: ExecuteRequestHandler
Handler: ApiURIs-ISAPI-Integrated-4.0
Error Code: 0x800703e9
What's going on? Why does IIS not fall back to my MVC app when static files don't exist and how come when I fix that, the inverse occurs and static files are no longer served properly? I'm fairly sure this has always been default behaviour in the past.
App pool is running in Integrated mode, CLR v4.0.
After finding various answers and blog posts suggesting enabling runAllManagedModulesForAllRequests, it seems that this - while it works - isn't the right approach.
RAMMFAR does exactly what it says on the tin and runs all requests (including those for "unmanaged" static resources) through all managed modules, which has a performance overhead and can also cause unusual side-effects depending on the modules enabled and the requests run through them.
Turns out the only module required to solve this problem is the UrlRoutingModule which, when the precondition is removed, causes all static resources to be run through MVC routing (when no static file exists):
<remove name="UrlRoutingModule" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule"
preCondition="" />
I have an MVC 4 application built on top of EPiServer 7.1. EPiServer uses StructureMap as it's IoC framework, which may be related to my problems. Anyhow, this is what I have done:
Via "Manage Nuget Packages...", added "Glimpse Mvc4" to my project
Verified that web.config was updated as expected
Restarted my application
After adding Glimpse, all requests fail with a NullReferenceException, e.g., like this:
I have tried enabling Glimpse logging by commenting in 'logging level="Trace"' in the Glimpse-section of web.config, but can't find any logging in neither Windows event logs or log4net log files.
Ideas on how to troubleshoot further, or hints to a solution?
A workaround (thanks to #avanderhoorn!) is to add this to the "glimpse" section of web.config:
<glimpse defaultRuntimePolicy="On" endpointBaseUri="~/Glimpse.axd">
<tabs>
<ignoredTypes>
<add type="Glimpse.AspNet.Tab.Routes, Glimpse.AspNet"/>
</ignoredTypes>
</tabs>
<inspectors>
<ignoredTypes>
<add type="Glimpse.AspNet.Inspector.RoutesInspector, Glimpse.AspNet"/>
<add type="Glimpse.Mvc.Inspector.ModelBinderInspector, Glimpse.Mvc4"/>
</ignoredTypes>
</inspectors>
</glimpse>
This disables the two parts of Glimpse that break with EPiServer. As far as I can see, you still get the most useful parts available!
+1 the same here. What I found so far is that by adding Glimpse it augments all routes and replaces with it's own proxy classes for intercepting calls to routing.
EPiServer (and UrlResolver in particular) seems that don't like this case. The root cause for this exception is following method:
UrlResolver.GetVirtualPath(ContentReference contentLink, string language, RouteValueDictionary routeValues, RequestContext requestContext)
What it doesn't like is fact that there is no route of type ContentRoute in the routing table:
foreach (RouteBase base2 in from r in this._routes
where (bool) (r is ContentRoute)
select r)
{
...
if(...)
{
return virtualPath;
}
}
return null;
And after returning null to the caller NullReferenceExpcetion occours in:
UrlExtensions.MapUrlFromRoute(RequestContext requestContext, RouteCollection routeCollection, string url)
Seems like patch from EPiServer should be awaited.