I'm writing a standard MVC 5 application, and set OutputCache tag on the controllers, also installed StackExange.Redis and RedisOutputCache. Configured the web.config accordingly.
The cache works perfectly when I Run this in localhost, however once deployed into an Azure WebApp, the cache doesn't work as I See the changes coming through. Also when debugging the App remotely, i see the breakpoint hits in the controller view action.
I have been looking for days for a solution, but I could not find any answer, not even something similar. I already raised a ticket on Azure Support.
So my questions is, is there something that could make the Azure WebApp behave differently from the local solution?
How could I debug Outputcache to check why it doesn't hit the cached version?
Additional info: I see in the Redis Cli the that Outputcache is storing the cached version, it's just it doesn't return it.
Thanks
Well, I finally found the issue.
I was using Thread.CurrentThread.CurrentCulture.Name in the VaryByCustomString() function in global.asax to create a culture based cached version.
However, once deployed to Azure WebApp this culture appears to be not set, so the check fails and the OutputCache thinks there isn't any version in Redis.
Related
My ASP.NET Core 6.0 website running in a container on Cloud Run is configured to log to Google Cloud Logging by way of a call to AddGoogleDiagnosticsForAspNetCore(...).
This works for my production Cloud Run website but not for dev-test. Both service accounts have the Logs Writer role.
The fault was mine. And yes, the question was unhelpful, though in fairness there aren't many moving parts to the problem*.
My code was negating the production check. I failed to spot the ! and was distracted by the fact that it works in production, and that when it originally didn't work in production it was because of IAM permissions.
It possibly works in production because a) the deployed code is older, different b) something about its configuration is enabling the console logger.
if (!this.HostingEnvironment.IsProductionLike())
{
AddGoogleDiagnostics(services);
}
Finding the fault involved adding a controller action to get and return an ILoggerProvider from the IServiceProvider which was null when called by curl, causing me to look again at the code which was supposed to register this type, the code above.
In conclusion: not many moving parts = probably developer error.
*I have this idea that if everyone always posted all their problems and then the solutions, however dumb it makes them appear, we'd have a great resource. Most of my stack rep comes from answering my own questions.
We have an asp.net Core application (that is running under .net Framework 4.8) which is deployed withing IIS on a Windows Server 2016 box. This application uses asp.net Core identity framework for roles based access.
Everything works great but when we update the "Site Bindings" (by way of an example config change) within IIS all the connected users get logged out upin the next page request, perhaps the cookie/sessions being reset?!
Whilst this might be the behaviour you expect this was not the behavious we had on a previous "identical" installation which was lost (all data was backed up etc etc but the server host died and we lost the exact settings).
I remember reading a while back (but can't find it now) that the session should actually persist as this allows for load-balancing (which we don't need).
Nothing has changed in the code base for this to now not work so this suggests it's an IIS setting.
Does anyone have a magic change we can make for the connections to persists and our users not to be sent back to the logon page on the asp.net core app?
Thanks.
Jim.
*** update ***
Changing the "Identity" property of the Appl pool entry to System Account seems to allow me to change bindings without the (app pool?) reset.
Somewhat annoyingly, this appears to be the only setting that doesnt reset the user sesions when changing the binding. The obv downside of using this are the security considerations which rule it out!
Anyone with a plan c?
To describe the app, it has an default page where it will be checking user role from request header then assign the user id into session and redirect to corresponding pages. In every other pages, it will check whether the session has value or not, if no then will redirect the default page.
This has been tested in my dev environment and its working without any issue. However, when I hosted it in IIS (AWS EC2 environment). It started behaving very weird. If the application's bindings is stick to default. I can browse it in the server using http://localhost:26943/ with no issue.
default bindings
However, when i change the bindings to hostname and browse using http://testing.com/, I found that the session containing user ID is empty.
hostname bindings
I have tried several methods including :
Add Session["init"] = 0 in Global.asax
Change cookieless=true in web.config
Change sessionState's mode to "StateServer"
Redirect to "~/page.aspx" instead of "page.aspx"
Only change cookieless method worked for me but it will show session ID in the URL which I doubt is the correct method.
Details of app:
.NetFramework 4.8
Uses WCF service
Current session state info is sessionState mode="InProc" cookieless="false" timeout="60"
Configured c:\Windows\System32\Drivers\etc\hosts to add 127.0.0.1 testing.com
Tested using IE 11
Since AWS is on a server farm?
Then in-proc sessions are going to be VERY flakey and problematic. Those massive cloud systems will spool out your web server multiple times - a WILD guess as to where the next page will come from. If pages are served across different instances of the IIS server?
You going to lose session values. As noted, even some un-handled code errors will cause a app-pool re-set. All of these issues add up to easy and frequent loss of sessions.
I would suggest you adopt SQL server based session management. This should eliminate a zillion issues that can cause a session() re-set. I like in- proc. Memory based is fast, and since your not writing the next Facebook, then of course typical server loads are next to nothing (again, this favors use of in-proc sessions). However, since you a have server farm, and some application errors will become problematic? Adopt SQL server based sessions, and 99 if not 100% of your session() re-sets and loss will go away.
this suggestion is MUCH more warranted since you using AWS and you have little control over the VM's they run and their behind the scenes "fabric" controller could for fail safe and redundancy issues be running multiple copies of your server. So, adopt SQL based session management.
HttpContext.Current.Session["myvariable"]
I have this .net core 2.1 MVC application that I've deployed to IIS.
Every GET request I do works fine.
The application has some javascript for doing POST requests and this fails with a 404. While all is fine on my development setup in VS Code running kestrel.
I've followed this guide for deploying: learn.microsoft.com on my Windows Server 2016 machine.
Checked the web.config and that looks exactly like the docs. I'm a bit clueless where to look next since it's working in kestrel. Rebooting the machine also does not help.
Must be some IIS configuration issue I guess..
EDIT
The application has only one POST controller method, and the app is basically a copy of this controller: githut upload example
Okay, found out what the problem is.
Turns out the request size is the problem, it is too big for the defaults.
This explains why it works fine on kestrel.
The thing that odd is the fact that IIS returns a 404. According to the documentation here it should return a subcode with the 404. I checked this triple times, but in my situation it surely does not. This mislead me a great deal.
We have a public website that is already exposed to the outside, although in reality there's really nothing there. Simply default.htm file with "Coming Soon" text in it. (http://vensuresoftware.com/)
We also have a WebAPI we've put together that we want to add to this website. When I publish locally to my IIS6, it works no problem. It's accessed as http://localhost/HRConnect/api/Claims just fine. I've used PostMan, a C# client, and Javascript AJAX to access this just fine. I can also load it in a browser at that URL, and I get the appropriate default controller and action.
However, I have been totally unable to accomplish this same thing on the website. Ideally I'd like to include it as a Virtual Directory to the http://vensuresoftware.com and access it as http://vensuresoftware.com/HRConnect/api/Claims but I've had zero luck doing so.
I have tried to add it as a Virtual Directory as well as an Application under that specific website, but when I access the URL, all I get is "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable."
I've ensure the Application pool is correct, with an appropriate user and the pass through connection test succeeds. But I just cannot access the service or the URL.
Any ideas or suggestions at all on what I can try? I'm not sure what else I can include here. Nothing special in IIS, nothing special in the service really. There's only 3 actions in it. As I said, it all works beautifully locally, under localhost though.
IIS 7 doesn't have built-in support for extensionless URLs which causes a lot of headaches trying to get MVC and Web API apps to run. I've gotten it to work using both these options. Pick the one that applies to you.
Install this IIS patch which allows IIS 7 to handle extensionless URLs.
If the patch isn't an option because you're worried about breaking other sites on the server, you can make the Web.config adjustment found in this answer. You'll have to do this for every MVC/Web API app you have running on the server.