httpcontext

I am working on a project where I have a C# class library which needs to use the System.web.HttpContext . I've done this before in another project without problem but now its not working. I'm not sure what I am missing they're both targeting .net 3.5 and I've added the reference System.web and added the directive using System.web . However, when I try and do HttpContext nothing is found. I've tried using the full path System.web.HttpContext but the only thing that comes up are 3 items related to ASP. Below are screenshots from the working project intellisense and the non-working intellisense

I am writing a unit test and the controller method is throwing an exception because HttpContext / ControllerContext is null. I don't need to assert anything from the HttpContext, just need it to be not NULL. I have done research and I believe Moq is the answer. But all the samples that I have seen haven't helped me a lot. I don't need to do anything fancy, just to mock the httpcontext. Point me in the right direction! TheFlyingCircus Got these two functions from here in a class; public static class HttpContextFactory { public static void SetFakeAuthenticatedControllerContext(this Controller

Is there room for issue in the following code in terms of multiple users of the same web application? I mean, I know that a purely static string will be shared across all sessions for a single ASP.NET application, but given that this explicitly refers to the Current.Session , even though it is static it seems like it would always refer to the session instance of the "current user." But an error is happening that could be explained by everyone sharing the current value of Mode and thus the most recent change overwriting everyone else's mode value. (As a background: This string is in a Helpers

I have a method that uses a repository ( userRepo ): public override Task<IdentityResult> CreateLocalUserAsync(IUser user, string password, CancellationToken cancellationToken) { var task = new Task<IdentityResult>(() => { TUserEntity newUser = new TUserEntity { Id = user.Id, UserName = user.UserName, Password = password }; userRepo.Save(newUser).Flush(); return new IdentityResult(true); }, cancellationToken); task.Start(); return task; } The userRepo object has a dependency that uses HttpContext.Current . Both of these are resolved using ninject InRequestScope . The above method is called

I have a lot of code that depends on HttpContext.Current, and I noticed that requests that come from SignalR hubs have HttpContext.Current == null , so my code breaks, for example: HttpContext.Current.Request.IsAuthenticated So I came up with following: public static class UnifiedHttpContext { private static HubCallerContext SignalRContext { get; set; } private static int SignalRUserId { get { return WebSecurity.GetUserId(SignalRContext.User.Identity.Name); } } private static bool IsSignalRRequest { get { return SignalRContext != null; } } public static void SetSignalRContext(HubCallerContext

My goal is to have one data context ( MainDbContext ) per HTTP request in ASP.NET MVC and dispose the data context when the request ends. I'm using the following StructureMap configuration: public static class ContainerConfigurer { public static void Configure() { ObjectFactory.Initialize(x => { x.For<MainDbContext>().HttpContextScoped(); }); } } Whenever I need a MainDbContext , I'm using this code: var dbContext = ObjectFactory.GetInstance<MainDbContext>(); This is working as expected: only one data context is being created per HTTP request. The problem is, MainDbContext is not being

We have a multi-layered Asp.NET Web Forms application. The data layer has a class called DataAccess which impements IDisposable and has an instance of our Entity Framework Object Context as a private field. The class has a number of public methods returning various collections of Entities and will dispose its Object Context when it is disposed. Due to a number of problems we've been facing, we decided it would be a big plus to keep the Object Context (or an instance of DataAccess ) in scope for longer on the server. A suggestion was made to keep an instance in the HttpContext.Current.Items