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...)
Related
With assumption I cannot simply get rid off antd (but definitely going to at first opportunity) is there any way how to keep antd from polluting global css with as little code modifications as possible or with code modifications which could be done with any mass code edit tool (search and replace, rollup plugin)?
As you could have guessed if you follow official guide on how to use antd you will pollute your global styles which becomes problem when you have routes in your app each using different ui framework like having /admin route or something similar and whenever you navigate from non-admin to admin route the admin app will load with polluted global styles.
There are many people with this exact problem, multiple issues, multiple proposed solutions which all have any combination of: not working, uses webpack (vite uses rollup), written in Chinese, links to dead repo, or requires you to modify basically every file you have.
I don't think you could link me to any existing google search hit I don't know about so I would really like to get an answer from someone who has this solved in some reasonable way with up to date dependencies and so on.
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 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.
There must be a better way to update links inside the layout/master page when publishing, I need to do this since I host my static contents in CDN and it should be linked differently since I have a shared CDN folder between many applications for some static contents and another part is only used by the app. that are used than on local machines. I don't want a to put server code to test anything as its useless to add code that test that on production, I was thinking is there a way to make layout pages like web.config where you create one file with debug added to layout name which will be picked locally while the release one is the one that get published.
performance is very important to me and i do no want any extra call that can be eliminated.
I don't want to be running a code that never be needed when you move the app to production.
Basically i hope there is a way to publish a different version of the layout page that point to the correct static contents since this will be the best way performance wise, MSBUILD should have that but i can not find the info.
Do you means static file like Javascript,Css & Images.
In your MVC app just make a global variable called CDN_Path. Define the appsetting in web.config so you can define the CDN path through web.config.
use this variable like this
#(Globals.Root_Path)Images/Test.png
Now anytime you move your CDN from Amazon S3 to somewhere else you can use it without any headache. Just change the value in web.config (when you change CDN) make it work everywhere in your site.
I have a windows service that loads multiple "handlers" written by different developers. The windows service exe has it's own app.config which I need.
I'm trying to make it so that each developer can provide their own app.config along with their handler code. However, it seems an exe can only have one app.config. However, ASP.NET seems to support nested web.config... That's not exactly what I want, but I don't even know how I would get that to work in a windows service.
Anyone come across this before or have any ideas?
I've not tried it, but I think you may be able to use the Configuration Manager to create separate Configuration objects for each of the handlers. Specifically, this page details a method for loading Configurations from "custom" filenames.