I made glimpse defaultRuntimePolicy Off but it still shows an error like this
Unable to define EFProfiledDbProviderServices class of type 'GlimpseDbProviderServices'. Please check that your web.config defines a <DbProviderFactories> section underneath <system.data>
shouldn't glimpse be out of asp.net mvc pipeline after making it off?
Update :
I also commented all the glimpse related part in web.config but I still get the same above error
The reason is that even when you disable Glimpse completely through the web.config, which makes sure Glimpse is not collecting any information during request processing, that there are still assemblies, like Glimpse.Ado and Glimpse.EF*, that have a PreApplicationStartMethod attribute defined, which means that some hooks are being put in place, even though they are not going to do anything when requests are being processed.
The solution is to remove the Glimpse.EF* assembly, and maybe the Glimpse.Ado assembly as well, from you bin directory.
Related
I have written an ASP.NET MVC App that is running on a Google Compute Engine. The app is getting a 500 Error on the main Index page that does not occur when running on my local machine.
I am trying to get the complex error page to show from the server, as it is much easier to view them on the web page for hotfixing issues than to delve into the Google Cloud Console to retrieve them. I do not want custom errors, just the same amount of depth that gets shown when running on my local machine.
I have tried:
Removing the existing HTTP Global Filter
Adding <customErrors
mode="Off"/><compilation debug="true"/> to my System.Web in
Web.config
Adding <httpErrors errorMode="Detailed" /><asp
scriptErrorSentToBrowser="true"/> to my System.WebServer in
Web.config
Publishing as debug
Ideas? I'm sure theres a publish setting I'm missing somewhere.
Adding a constructor to the page controller finally provided the detailed error log. If you have taken all of the steps above to get the log, and it still has yet to show, ensure there are constructors for all view controllers involved. Even if the constructor is blank.
I still need to delve into my particular crash issue, but at least I can get an idea where to start.
Basically any place that a MVC resource is needed in my application, it is being listed in the error list (234 errors, almost every single one is the exact same error).
I am able to get intellisense when I type System.Web.Mvc., and add a Controller, but after building, the line which the Controller was added to shows in blue font, but it is underlined.
I have literally tried so many solutions from Stack, most often discussed is:
Remove reference to System.Web.Mvc and re-add. Set copy local to true.
Screenshot of subset of errors below.
I am surprised that it is being flagged here, when it is recognizing Controller in the inheritance.
Here too
This is never the nice answer... I recreated the solution, and very carefully chose all of my options when configuring. I built to the browser after all changes, and so far everything is working out.
Let's say I want to completely disable Glimpse.
Glimpse now registers itself using the assembly activation method. So even if I comment out all the glimpse stuff in web.config, it will still try to load.
I prefer to manually register Glimpse in Application_Start, if I need it.
Is there any way to override the default behavior to allow me to register it manually? (Which means I can disable it completely if I need to.)
Glimpse has been built around the philosophy to have it run with the least amount of additional config or code for users to add or write themselves. Granted this comes with the additional drawback that if you want to disable it completely, that changes from your side will be required and some changes are easier than others.
I answered a similar SO Question Why is Glimpse still running indicating why commenting Glimpse specific config inside web.config is not enough for assemblies using the PreApplicationStartMethodAttribute.
In short, you'll need to make sure that the Glimpse.EF* and the Glimpse.Ado assemblies are not deployed in addition to commenting your web.config. Not deploying these assemblies and commenting out those config sections can be automated one way or the other (web.config transformations, custom build tasks...)
I have an MVC 5.x app which has had its views precompiled and merged into a single assembly. Even after all this the first request to a view after AppDomain startup is slow, it does not matter which view is requested as they are all slow the first time the view is requested. Digging in with MiniProfiler I can see it is the "Render" time on the view which takes the majority of the time and upon additional requests to the view the Render time is reduced by about 90%. So to be clear it is this first-time Render that is taking allot of the time. I was not expecting to see this bit of slowness due to the fact all of views have been precompiled and I do not believe it is the JIT that is causing this massive slow down...anyone have any guesses or insights?
Please note, this is not the very first request of a web application, this is the first request of a particular view/page. For example, for the test below the app had been running for hours and was taking requests constantly but the test captured the first request for this view.
First Request
Second Request
Strange! In order to be 100% sure what exactly happens, however, I'd do the following:
I'll redirect the run-time compilation (yes, there'll be one since at
least Global.asax needs to be compiled) like this:
<system.web>
<compilation debug="true" targetFramework="4.5" tempDirectory="c:\temp\asp.net" />
...
</system.web>
I'll investigate the contents of the folder before and after the
first run. Maybe it'd be even better to have a copy of the original.
From your description of the problem it seems like everything should be just fine and there would be no differences between the runs. Still comparing contents of the folder before and after may reveal some difference.
Another cause might be some caching but I can guess you have already sorted this up.
I struggled with the exact same issue for months: It happened to me in some views only.
Apparently, the rendering of the views is not that straightforward as I thought, since MVC needs to run a couple of operations to determine the exact .cshtml to use for an action, its partial views if you have any, etc etc.
What did the job for me is to use Razor Generator which processes Razor files at design time instead of runtime. (if you wanna give it a shot, I suggest first trying it with a view you know takes time to load at first attempt).
From the website:
One reason to do this is to avoid any runtime hit when your site
starts, since there is nothing left to compile at runtime. This can be
significant in sites with many views.
The downside of implementing the Razor Generator is that you no longer need the .cshtml files: so if you want to change a view, you have to recompile the project. But that's not an issue necessarily, at least not for me.
Install the Razor Generator from the VS extension gallery first (like it's explained on the website) and then the nuget package.
Trust me: you are gonna be so relieved you're gonna cry ☺
I'm trying to get an ASP.NET MVC 3 site running on IIS 6.0.
Currently when I request a page from the server it gives the following error:
Parser Error Message: This method cannot be called during the application's pre-start initialization stage.
on this line:
<add name="MyMembershipProvider" type="NS.MyMembershipProvider" connectionStringName="MyDatabase" applicationName="/MySite"/>
I'm completely stumped and don't have much of a clue about the ASP.NET application lifecycle, let alone the differences between 6.0 and 7.0. Reading through the MSDN pages on it hasn't seemed to help much.
Does anyone have any insight or any good links for investigation? :)
Add this in your web.config (in the appSettings section):
<add key="enableSimpleMembership" value="false"/>
<add key="autoFormsAuthentication" value="false"/>
EDIT:
For the ones who ask why, it is a known issue described in the mvc 3 release notes
More details here
After upgrading some of my applications from ASP.NET MVC3 to MVC4 I was getting this error. It was a result of the WebMatrix assemblies (WebMatrix.WebData.dll and WebMatrix.Data.dll). I removed those references and assemblies from the /bin directory and that took care of the issue.
#Ek0nomik is right. We migrated from the MembershipProvider to the new ExtendedMembershipProvider allowing us to take advantage of some of the new functionality offered in the WebMatrix namespace. By default Simple Membership is enabled for some reason so we had to disable it explicitly since we didn't want to go as far as using the SimpleMembershipProvider.
All we had to do was add this to the web.config:
<add key="enableSimpleMembership" value="false"/>
Having Simple Membership enabled caused the Provider initialisation code to execute before the Application_Start handler. Our app structure requires App_Start to be the first thing to execute. Personally I would always expect this but Simple Membership changes this behaviour. Beware.
Well, I just got this error, and it resulted from having accidentally copied a .cshtml into the root of my project. It wasn't even included in the project. Deleted that and the error went away. This was with MVC3 on IIS7. I imagine some of the people getting this problem are in the same boat.
This is caused by any of a number of Reflection calls being made too early in an Application. It just so happens the Web.Config suggestions in other answers prevented one such Reflection call from being made. In my case however:
I'm using Entity Framework, and ran update-database. I got:
This method cannot be called during the application's pre-start initialization phase.
As it turns out we had code that used a library which was recently modified to get all code in all namespaces/projects. Specifically, it called:
System.Web.Compilation.BuildManager.GetReferencedAssemblies()
Kaboom. That caused this obscure error. EF Migrations run in a weirdo zone where the application is half running and half not, meaning the above method can never be called by any code Migrations would call on.