I'm digging around with HttpContext and the OnInit event for a custom control, after realizing that a few checks are not responding in the desired manner.
Within the current context's items collection, I store an object (serialized) that I would like to interrogate once on every post back. The first time the control is rendered, will the items[] be null, it then gets populated somewhere down the line and the user clicks a button to post back data.
Now, within the button submit event, I set the items[key] to null to ensure that on the post back I don't have anything stored, but it always contains a value.
I'm assuming that the OnInit handler has a reference to the previous state, thus 'falsely' assuming that the items[] should contain a value. Is this something to do with the way OnInit works, or am I missing the bigger picture?
We're migrating an application to use IIS7 integrated mode. In library code that is designed to work either within the context of an HTTP request or not, we commonly have code like this:
if (HttpContext.Current != null && HttpContext.Current.Request != null) { // do something with HttpContext.Current.Request } else { // do equivalent thing without HttpContext.. }
But in IIS7 integrated mode the check for HttpContext.Current.Request throws an exception whenever this code is called from Application_Start.
System.Web.HttpException: Request is not available in this context
How can I detect whether the request is really available without wrapping these calls in an exception handler and taking action based on whether an exception is generated or not.
Looking at HttpContext in Reflector I see it has an internal bool HideRequestResponse field but it's internal so I can only get to it with reflection and that's fragile. Is there a more official/approved way to determine if it's ok to call HttpContext.Request?
This blog post about the subject says not to use HttpContext, but how, in generic library code, can you determine if it's ok to use HttpContext?
I'm using the work-around mentioned there which is to use Application_BeginRequest and an initialized field to only initialize once as part of BeginRequest, but that has to be done in every calling application whereas I'd prefer to make the library code more robust and handle this situation regardless of where it's called from.
I have been experimenting with code that will clear all of the cookies in an HttpContext.Response.Initially, I used this:
DateTime cookieExpires = DateTime.Now.AddDays(-1); for (int i = 0; i < HttpContext.Request.Cookies.Count; i++) { HttpContext.Response.Cookies.Add( new HttpCookie(HttpContext.Request.Cookies[i].Name, null) { Expires = cookieExpires }); }
this will error with an OutOfMemoryException because the for loop never exits - each time you add a cookie to the Response, it also gets added to the `Request.
i'm using an example in which i can fake the session.It's for use in a unittest of a mvc controller.In the test i create a controller and then i do this:
FakeHttpContext httpctx = new FakeHttpContext(null,null,null,null,mSessionItems ); ControllerContext ctx2 = new ControllerContext(httpctx,new RouteData(), target);
here mSessionItems is my session and target is my instance of a controller,and indeed, when i'm in a controller reading this.ControllerContext.HttpContext.Session, i have a session, great!but.... i also read the session outside the controller, and there i use HttpContext.Current.Session, and that is null (or actualy, the HttpContext.Current is null).
Does anyone knows why HttpContext.Current.Server.MapPath within a server control works when I run the server control but gives and error whilst in Design mode?
I have an ASP.NET site and I've been doing some work refactoring code to try to remove some long running processes (in the order of an hour) from the actual http Request by creating a BackgroundWorker and sending the work off to that to process. This was running fine on cutdown tests but when I applied the logic to the real code I found problems accessing Session variables from the code running in the Background Worker. It seems that the HttpContext object that was passed has a null session and if I ask for HttpContext.Current I get null back.
I'm assuming that this is because they are in a different thread and that the session and HttpContext.Current are both reliant on being in the same thread. Is there any way I can get access to the Session from the background worker or am I stuck with finding all the variables I need from session and putting them in an usable data structure and then putting them back in session (if appropriate) afterwards? It obviously complicates the refactor massively if I need to do this so I'd rather not.how I might do this other than BackgroundWorker processes
I'm trying to create a SessionManager class which I can use to manage sessions in my MVC applications. For that I'm thinking the best way of doing so is by creating a wrapper class for HttpContext which would then allow me to access HttpContext.Current.Session.
To be honest, I'm not really sure about the whole thing, I just feel it's the logical way of doing so. I also want to create an ISessionManager and ISession interfaces, and then implement them according to my application's needs. For my current project, and for now, I need a InProc session management, but I might need to store session data in MSSQL Server when we decide to expand and use a web farm or a garden. That's why I'm trying to build a sort of an extensible framework right from the start.
Final note, I will be using Microsoft Unity to inject the concrete SessionManager of choice. I believe that's a good way to maintain a certain level of abstraction.
I spawn a thread on Application_Start and would like to log exceptions. There is not Context/HttpContext/HttpContext.Current, so how might i get it to log?ATM it does not catch any exception in my threads and if i write ErrorSignal.FromCurrentContext().Raise(ex); i get an error about context cannot be null.Maybe i can create a dummy HttpContext but somehow i dont think that will work well.-edit- i tried ErrorSignal.Get(new HttpApplication()).Raise(ex); and it doesnt seem to pick up that exception.
What's the correct way to get the controller name and action from an httpContext object? I can see the values in the debug, but I don't seem to be able to get to them in the object code?
I need to fake HttpContext.Current.Application table to access it from my unit tests.I need to store my data somewhere. I thought that I can just pass instance of NameValueCollectionBase but as I descover this base type has no indexer so it's too complicated to use. So what about faking this part of HttpContext? Is it possible? How can I make it? Will be NUnit.
As per title. I want to be able to save some data in a cache object but this object must be available to all users/sessions and can expire.What is the best method to achieve this in a asp.net web app?
I have some code that works fine when I need to delete some image files from a directory on my web server:
Dim ImageURL As String = dsImages.Tables(0).Rows(iImgRow).Item("ImageURL") Dim physicalName = Server.MapPath(ImageURL) oUpload.DeleteFileFromServer(physicalName, iAdid, iImgID)
.but I am running into a problem when a maintenance task running in a separate thread at set intervals determines that files like the above need to be deleted:
Dim ImageURL As String = dsImage.Tables(0).Rows(i - 1).Item("ImageURL") Dim iImgID As Integer = dsImage.Tables(0).Rows(i - 1).Item("ImageId") Dim physicalName As String = HttpContext.Current.Server.MapPath(ImageURL) oUpload.DeleteFileFromServer(physicalName, iAdID, iImgID)
In this latter case, HttpContext.Current.Server.MapPath(ImageURL) has a value of Nothing.Is there a way to get the full path for this case?
I'm looking for as comprehensive as possible of a mock replacement and wrapper for the ASP.NET HttpContext in my applications. A comprehensive mock replacement could potentially increase the testability of my ASP.NET web applications substantially, without necessitating migrating every application to more-testable frameworks such as MVC.
Some of the features I am most interested in seeing in an HttpContext wrapper and mock framework include:
Serialized session storage (e.g., .Session). Serialized application-scoped storage (e.g., .Application). Per-request item storage (e.g., .Items). HttpRequest data, such as referrers, request Uri, server variables, post data, etc. HttpResponse data, such as status codes and content. Local file resolution (e.g. Server.MapPath)
VirtualPathUtility for application-relative URL path resolution, which has a dependency on the ASP.NET runtime.The identity and principal (e.g., .User) for validating authentication/authorization rules.The AllErrors collection for testing error resolution in HttpModules and Global.asax.I considered writing my own interface, wrapper, and mock; however, I believe such must already exist. The variety of mock frameworks is a little overwhelming for a first-timer to absorb.
What is the most comprehensive HttpContext wrapper and mock?
During Application_End() in Global.aspx, HttpContext.Current is null. I still want to be able to access cache - it's in memory, so want to see if I can reference it somehow to save bits to disk.
Question - is there a way to reference cache in memory somehow when HttpContext.Current is null?
Perhaps I could create a global static variable that would store pointer to cache that I could update on HTTP requests (pseudo: "static <pointer X>" = HttpRequest.Current) and retrieve a reference to cache through that pointer in Application_End()?
Is there a better way to access Cache in memory when there is no Http Request is made?
I am working on an existing application which works using a custom built MVC framework.
The gateway into the front end is an implementation of IHttpHandler to handle the requests and determine which Action to call - its called FrontControllerHandler.
Currently FrontControllerHandler.ProcessRequest(HttpContext context) method takes a HttpContext object and then continues to pass it around to various other methods that it calls.
What we're hoping to refactor is to stop passing around the 'context' object and simply refer to:
HttpContext.Current Allowing asp.net to do the work for us...its there...why not use it, right?
Thing that i'm not sure about is, would there ever be a scenarion in which the HttpContext object passed to ProcessRequest would not actually refer to the same memory location (same object) that is referenced by:
HttpContext.CurrentI'm assuming that this would never happen unless something has gone wrong, in which case i can test for it and throw an exception. EG
[Code]....
So i would like to get peoples thoughts on this...
I want to write a unit test which tests the function of a class called UploadedFile. The problem I face is this class' static constructor uses HttpContext.Current property and because I am running my unit test from a class library I do not have an HttpContext at the testing time.
Look at my static constructor:
static UploadedFile() { if (HttpContext.Current == null)[code]....
What should I do in my testing environment so that HttpContext.Current won't be null and I can successfully set this:
HttpServerUtility server = HttpContext.Current.Server;
