Unit testing HttpContext Response.Redirect - asp.net

I am using HttpSimulator for unit testing. I am testing one method that has deeper in code chain call Response.Redirect. I am facing here with problem. I'm getting
System.NullReferenceException was unhandled by user code
HResult=-2147467261
Message= Object reference not set to an instance of an object.
Source=System.Web
StackTrace:
at System.Web.HttpApplication.CompleteRequest()
at System.Web.HttpResponse.End()
at System.Web.HttpResponse.Redirect(String url, Boolean endResponse, Boolean permanent)
at System.Web.HttpResponse.Redirect(String url, Boolean endResponse)
Then I reflected HttpApplication type and found mentioned method :
public void CompleteRequest()
{
this._stepManager.CompleteRequest();
}
I am initializing HttpApplication on one of the following ways :
HttpContext.Current.ApplicationInstance = new HttpApplication();
// or with Mock framework
var httpApplicationMock = new Mock<HttpApplication>()
var applicationInstance = httpApplicationMock.Object;
As I got from ASP documentation, _stepManager is in charge for Module and Handler execution order and harmonization. This field is initialized depends on whether application is under Classic or Integrated mode.
Then I have called in my test :
object stepManager = typeof(HttpApplication).GetField("_stepManager", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(HttpContext.Current.ApplicationInstance);
I got that stepManager is null, that is expected from above exception. StepManager is initialized within method :
internal void InitInternal(HttpContext context, HttpApplicationState state, MethodInfo[] handlers)
So, from this I am not having control how to ensure stepManager to be initialized.
Then I have tried second scenario. In this scenario I have tried to initialize ApplicationInstance on other way.
From following link AppHost.cs
I have tried to initialize ApplicationInstance like this :
private static HttpApplication GetApplicationInstance()
{
var writer = new StringWriter();
var workerRequest = new SimpleWorkerRequest("", "", writer);
var httpContext = new HttpContext(workerRequest);
return (HttpApplication)getApplicationInstanceMethod.Invoke(null,
new object[] { httpContext });
}
and I got on lat method's line :
InnerException: System.InvalidOperationException
HResult=-2146233079
Message=This method cannot be called during the application's pre-start initialization phase.
Source=System.Web
StackTrace:
at System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled()
at System.Web.Compilation.BuildManager.GetGlobalAsaxTypeInternal()
at System.Web.Compilation.BuildManager.GetGlobalAsaxType()
at System.Web.HttpApplicationFactory.CompileApplication()
at System.Web.HttpApplicationFactory.Init()
at System.Web.HttpApplicationFactory.EnsureInited()
at System.Web.HttpApplicationFactory.GetApplicationInstance(HttpContext context)
I have tried the third scenario. I have created custom Response derived from HttpResponseBase that has overrided Redirect method. But I am facing with problem, how to assign created HttpContextBase to the HttpContext.Current. I saw tip on Sergei's blog :
HttpContext httpContext = httpContextBase.ApplicationInstance.Context;
But it is not possible to set Context on ApplicationInstance. It is null.
Is it possible to solve one of these 3 cases or to take another idea/approach to unit test my scenario.
Thank you,
Rastko

Related

asp net core entity framework - Cannot access a disposed object

The following code:
public async static Task<List<RecentTask>> GetRecentTasks(ApplicationDbContext db,
int EmployeeID, int NewTaskID, ILogger<HomeController> logger)
{
var TaskList = await db.RecentTask.ToListAsync(); // without this line - no exception
var t = new RecentTask();
t.EmployeeID = EmployeeID;
t.TaskDefinitionID = NewTaskID;
db.RecentTask.Add(t);
await db.SaveChangesAsync(); // EXCEPTION!
return TaskList;
}
causes the exception:
Cannot access a disposed object. A common cause of this error is
disposing a context that was resolved from dependency injection and
then later trying to use the same context instance elsewhere in your
application. This may occur if you are calling Dispose() on the
context, or wrapping the context in a using statement. If you are
using dependency injection, you should let the dependency injection
container take care of disposing context instances. Object name:
'ApplicationDbContext'.
Removing the first line would cause the exception to disappear. I don't see how the object db would be disposed. Does anyone have an idea what is happening here?

Access appSettings in web.config from Thread in Class Library project

Can I able to access appSettings section in my ASP.NET web.config file from a method in another referenced Class Library project when it is called as a new Thread?
I'm accessing the setting through a property as
private static string TempXmlFolder
{
get
{
return System.Web.HttpContext.Current.Server.MapPath(ConfigurationManager.AppSettings["ReceiptTempPath"] ?? "~/Receipts/TempXML");
}
}
There is an extension method for the matter to generate the receipt.
internal static void GenerateReceipt(this IMatter matter)
{
try
{
string XmlFile = TempXmlFolder + "/Rec_" + matter.MatterID + ".xml";
// ...
// Generating receipt from the matter contents
// ...
// Saving generated receipt
}
catch (Exception ex)
{
ex.WriteLog();
}
}
I'm calling the receipt generation as a new thread from the class library like
Thread printThread = new Thread(new ThreadStart(this.GenerateReceipt));
// To avoid exception 'The calling thread must be STA, because many UI components require this' (Using WPF controls in receipt generation function)
printThread.SetApartmentState(ApartmentState.STA);
printThread.Start();
// ...
// Do another stuffs
// ...
// Wait to generate receipt to complete
printThread.Join();
But since the HttpContext.Current is null inside the Thread, I'm not able to access the current web server configuration file.
Can you suggest there any way other than passing the current HttpContext to the Thread? If no, what are the things I've to take care to keep thread safety?
Edit #1
Currently I'm passing the HttpContext to the thread like
System.Web.HttpContext currentContext = System.Web.HttpContext.Current;
Thread printThread = new Thread(() => this.GenerateReceipt(currentContext));
and in the function,
internal static void GenerateReceipt(this IMatter matter, System.Web.HttpContext htCont)
{
string TempXmlFolder = htCont.Server.MapPath(ConfigurationManager.AppSettings["ReceiptTempPath"] ?? "~/Receipts/TempXML");
//...
Pass the TempXmlFolder into the thread. Don't rely on HttpContext.Current. Alternatively, pass the value of HttpContext.Current to the thread and calculate the value of TempXmlFolder later.
You can pass the value using any way you want. Maybe a field or a local variable that you capture with a lambda.

Test ControllerFactory (pre-start initialization stage)

I want to write a unit test that verifies my route registration and ControllerFactory so that given a specific URL, a specific controller will be created. Something like this:
Assert.UrlMapsToController("~/Home/Index",typeof(HomeController));
I've modified code taken from the book "Pro ASP.NET MVC 3 Framework", and it seems it would be perfect except that the ControllerFactory.CreateController() call throws an InvalidOperationException and says This method cannot be called during the application's pre-start initialization stage.
So then I downloaded the MVC source code and debugged into it, looking for the source of the problem. It originates from the ControllerFactory looking for all referenced assemblies - so that it can locate potential controllers. Somewhere in the CreateController call-stack, the specific trouble-maker call is this:
internal sealed class BuildManagerWrapper : IBuildManager {
//...
ICollection IBuildManager.GetReferencedAssemblies() {
// This bails with InvalidOperationException with the message
// "This method cannot be called during the application's pre-start
// initialization stage."
return BuildManager.GetReferencedAssemblies();
}
//...
}
I found a SO commentary on this. I still wonder if there is something that can be manually initialized to make the above code happy. Anyone?
But in the absence of that...I can't help notice that the invocation comes from an implementation of IBuildManager. I explored the possibility of injecting my own IBuildManager, but I ran into the following problems:
IBuildManager is marked internal, so I need some other authorized derivation from it. It turns out that the assembly System.Web.Mvc.Test has a class called MockBuildManager, designed for test scenarios, which is perfect!!! This leads to the second problem.
The MVC distributable, near as I can tell, does not come with the System.Web.Mvc.Test assembly (DOH!).
Even if the MVC distributable did come with the System.Web.Mvc.Test assembly, having an instance of MockBuildManager is only half the solution. It is also necessary to feed that instance into the DefaultControllerFactory. Unfortunately the property setter to accomplish this is also marked internal (DOH!).
In short, unless I find another way to "initialize" the MVC framework, my options now are to either:
COMPLETELY duplicate the source code for DefaultControllerFactory and its dependencies, so that I can bypass the original GetReferencedAssemblies() issue. (ugh!)
COMPLETELY replace the MVC distributable with my own build of MVC, based on the MVC source code - with just a couple internal modifiers removed. (double ugh!)
Incidentally, I know that the MvcContrib "TestHelper" has the appearance of accomplishing my goal, but I think it is merely using reflection to find the controller - rather than using the actual IControllerFactory to retrieve a controller type / instance.
A big reason why I want this test capability is that I have made a custom controller factory, based on DefaultControllerFactory, whose behavior I want to verify.
I'm not quite sure what you're trying to accomplish here. If it's just testing your route setup; you're way better off just testing THAT instead of hacking your way into internals. 1st rule of TDD: only test the code you wrote (and in this case that's the routing setup, not the actual route resolving technique done by MVC).
There are tons of posts/blogs about testing a route setup (just google for 'mvc test route'). It all comes down to mocking a request in a httpcontext and calling GetRouteData.
If you really need some ninja skills to mock the buildmanager: there's a way around internal interfaces, which I use for (LinqPad) experimental tests. Most .net assemblies nowadays have the InternalsVisibleToAttribute set, most likely pointing to another signed test assembly. By scanning the target assembly for this attribute and creating an assembly on the fly that matches the name (and the public key token) you can easily access internals.
Mind you that I personally would not use this technique in production test code; but it's a nice way to isolate some complex ideas.
void Main()
{
var bm = BuildManagerMockBase.CreateMock<MyBuildManager>();
bm.FileExists("IsCool?").Dump();
}
public class MyBuildManager : BuildManagerMockBase
{
public override bool FileExists(string virtualPath) { return true; }
}
public abstract class BuildManagerMockBase
{
public static T CreateMock<T>()
where T : BuildManagerMockBase
{
// Locate the mvc assembly
Assembly mvcAssembly = Assembly.GetAssembly(typeof(Controller));
// Get the type of the buildmanager interface
var buildManagerInterface = mvcAssembly.GetType("System.Web.Mvc.IBuildManager",true);
// Locate the "internals visible to" attribute and create a public key token that matches the one specified.
var internalsVisisbleTo = mvcAssembly.GetCustomAttributes(typeof (InternalsVisibleToAttribute), true).FirstOrDefault() as InternalsVisibleToAttribute;
var publicKeyString = internalsVisisbleTo.AssemblyName.Split("=".ToCharArray())[1];
var publicKey = ToBytes(publicKeyString);
// Create a fake System.Web.Mvc.Test assembly with the public key token set
AssemblyName assemblyName = new AssemblyName();
assemblyName.Name = "System.Web.Mvc.Test";
assemblyName.SetPublicKey(publicKey);
// Get the domain of our current thread to host the new fake assembly
var domain = Thread.GetDomain();
var assemblyBuilder = domain.DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.RunAndSave);
moduleBuilder = assemblyBuilder.DefineDynamicModule("System.Web.Mvc.Test", "System.Web.Mvc.Test.dll");
AppDomain currentDom = domain;
currentDom.TypeResolve += ResolveEvent;
// Create a new type that inherits from the provided generic and implements the IBuildManager interface
var typeBuilder = moduleBuilder.DefineType("Cheat", TypeAttributes.NotPublic | TypeAttributes.Class, typeof(T), new Type[] { buildManagerInterface });
Type cheatType = typeBuilder.CreateType();
// Magic!
var ret = Activator.CreateInstance(cheatType) as T;
return ret;
}
private static byte[] ToBytes(string str)
{
List<Byte> bytes = new List<Byte>();
while(str.Length > 0)
{
var bstr = str.Substring(0, 2);
bytes.Add(Convert.ToByte(bstr, 16));
str = str.Substring(2);
}
return bytes.ToArray();
}
private static ModuleBuilder moduleBuilder;
private static Assembly ResolveEvent(Object sender, ResolveEventArgs args)
{
return moduleBuilder.Assembly;
}
public virtual bool FileExists(string virtualPath) { throw new NotImplementedException(); }
public virtual Type GetCompiledType(string virtualPath) { throw new NotImplementedException(); }
public virtual ICollection GetReferencedAssemblies() { throw new NotImplementedException(); }
public virtual Stream ReadCachedFile(string fileName) { throw new NotImplementedException(); }
public virtual Stream CreateCachedFile(string fileName) { throw new NotImplementedException(); }
}

Ninject + .NET 4 + Integrated Pipeline results in NullReferenceException

I have configured Ninject 2 in an ASP.NET 4.0 project (not MVC) however when I deploy the project to an IIS host it crashes with the following:
System.NullReferenceException: Object reference not set to an instance of an object.
[NullReferenceException: Object reference not set to an instance of an object.]
System.Web.PipelineModuleStepContainer.GetEventCount(RequestNotification notification, Boolean isPostEvent) +30
System.Web.PipelineStepManager.ResumeSteps(Exception error) +1481
System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb) +132
System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +709
I have tested this again with a vanilla ASP.net Web Application and get the same crash with the following code:
protected override IKernel CreateKernel()
{
return Container;
}
private IKernel Container
{
get
{
IKernel kernel = new StandardKernel(new SiteModule());
var module = new OnePerRequestModule();
module.Init(this);
return kernel;
}
}
Has anyone else got Ninject working with ASP.net 4?
[UPDATE: 2010.11.03]
After doing some research it appears it may be something to do with the OnePerRequestModule() module, removing this however doesn't seem to resolve the problem I added it due at the suggestion of this question.
In Ninject 2, you use the Ninject.Web extension (see the complete set here) and dont do any explicit config as you have here around OnePerRequestModule etc.
You don't do any web.config stuff either IIRC (I'm using the MVC one and you don't there)

HttpContext.Current NullReferenceException in Static Method

I have a static class with several static methods. In these methods, I'm trying to access the current thread's context using HttpContext.Current. For example:
var userName = HttpContext.Current.User.Identity.Name;
However, when I do that, I receive a NullReferenceException, the infamous "Object reference not set to an instance of an object."
Any ideas?
It isn't clear from the original post that the HttpContext is actually what's missing. The HttpContext.User property can also be null at certain stages of the lifecycle, which would give you the exact same exception. All other issues aside, you need to step through the source and see which part of the expression is actually null.
When you write code that references static methods/properties like HttpContext.Current, you have to write them knowing that your code isn't guaranteed to be run when the methods/properties are actually available. Normally you have something like this:
static string GetCurrentUserName()
{
HttpContext context = HttpContext.Current;
if (context == null)
return null;
IPrincipal user = context.User;
if (user == null)
return null;
return user.Identity.Name;
}
Although I suspect that this wouldn't really solve your problem here, it would just get rid of the exception. The issue is more likely that you're calling this method at a time or place when the context is simply not available, such as on a background thread, static constructor or field initializer, or in the Application_BeginRequest method, or some similar place.
I might start by changing the static methods to instance methods of a class that depends on an HttpContext instance (i.e. taken in the constructor). It's easy to fool yourself into thinking that methods like GetCurrentUserName are simple "utility" methods, but they're really not, and it is generally invalid to be invoking a method that references HttpContext.Current through the static property from any place where you don't already have an instance reference to the same HttpContext (i.e. from the Page class). Odds are, if you start rewriting your classes like this:
public class UserResolver
{
private HttpContext context;
public UserResolver(HttpContext context)
{
if (context == null)
throw new ArgumentNullException("context");
this.context = context;
}
public string GetUserName()
{
return (context.User != null) ? context.User.Identity.Name : null;
}
}
...then you will likely find out very quickly where the chain is being broken, which will be the point at which you need to reference HttpContext.Current because you can't get it from anywhere else.
In this specific case, obviously, you can solve the problem just by taking the stack trace of the NullReferenceException to find out where/when the chain begins, so you don't have to make the changes I've described above - I'm simply recommending a general approach that will help reduce these sorts of "missing singleton" errors in the future.
I've run into this a few times, especially with static methods in another library and not my main project. I've resorted to passing the HttpContext to the static method as a param when nothing else seems to work.
Where exactly is the null exception being thrown? Have you debug and see what is null? Is the HttpContext.Current is null or the User?

Resources