I'm in process of creating a Console Application, which needs to invode methods that heavily dependent on HttpContext. I could simulate the base HttpContext as well as the authentication, but I fail to set HttpContext.Current.Application. Is there any possibility to set the data in it?
There were couple of question on the same subject overe here, but couldn't get a solution from either, and thus ended up posting another one here.
My target is to get this working.
HttpContext.Current.Application("PageDefinitionCache") = pageDefinitions
Any suggestions, please?
The cache lives inside the ASP.NET worker process, you cannot access it directly from a console application. HttpContext.Current is null since you don't use the aspx.net worker process in a console application.
Consider declaring a global variable in the console application to simulate the behavior of the HttpContext.Current.Application.
you can not use HttpContext in Console application.
as mentioned by #matrxRapture you can resolve this issue by using global variables and if you are looking for current directory path for the application you can use Assembly.GetExecutingAssembly().Location
Related
I'v used many ways to keep an object instance alive to share it's data between request.But All the methods even dependency injection doesn't work at all.
Finally I've realized that my App get recycled by every request and the reason was I wrote some log files in bin folder.So if you make any change in your bin directory, IIS will recycle your application.
I have been applying separate web.config files for each environoment as my ASP.NET application progresses through Development, IT, UA and Production and have been looking for a way to simplify this process.
In the past, these had been updated manually; this was tiresome and prone to human error. More recently, I've been using IBM's uDeploy to push the application with an environment-specific config file deployed with the application depending on the target environment.
I've seen many suggestions, such as separate config files (as per my current setup), use of pre-build events etc. However, I implemented a solution to this issue in our test environment whereby I assigned the database connection strings to environment variables on my application server. The relevant environment variable is then passed into my data access connection method.
In other words, each environment's application server has an environment variable with the same name but with a different value assigned. This solution is quite simple and easily implemented and appears to function correctly.
Does anyone else manage separate environment configurations in this way? Are there any disadvantages to this approach that I have failed to consider?
I have a Web Project setup that has both my WebForms and a WCF service. I am having an issue where every so often my application seems to recycle and i lose all singleton objects and session values. It does not appear to be a timeout issue, but maybe a memory leak of some kind. We can be using the app for a minute or so and then bam it just loses everything.
I have tried monitoring the directory for changes but found no changes to the filesystem at all. I also put a breakpoint in Application_Error and there are no errors being thrown.
I have been googling for two days trying to resolve this issue. The application is a direct duplication of a previous project that is working fine. The one thing I noticed that is different is my last project I used nHibernate for the backend and this project I switched to using Linq to SQL. I noticed that I wasn't handling the DataContext properly because I was diming an isntance of the DataContext inside my service calls and returning a value before ever disposing or setting the context back to nothing, so I figured it may not be closing. I tried instead of storing the datacontext in my "repository" class i stored it inside the operationcontext and explicitly dispose it on Application_EndRequest. That still hasn't resolved the issue.
Anyone have any suggestions or places I should look?
** UPDATE **: I believe i found my issue. I have objects that are using EntitySet and i am serializing those objects directly back using a serializable IList property with a linq query returning the list. When i tried to explicitly dispose of my datacontext before returning the data I am running into issues serializing those EntitySet's now because the datacontext is no longer active. I am going to try copying the data into a new blank object with regular Lists instead of EntitySet's and see if this will allow me to properly close my datacontext and resolve my issue.
Update is really a different question, but you really should not try and serialize stuff that comes off of an ORM -- lots of potential nightmares. Build yourself some DTOs.
In the IIS7 Console, select the specific application pool, and select "Recycling..." in the action pane to the left. It's a wizard that lets you define how the application pool recycles, and how it logs the recycle events to the event log (page 2 of the wizard).
Basically I want the effect that would occur if I were to edit the web.config file. The application basically completely unloads itself and starts again, thus re-firing Application_Start and also ditching any dynamically created Types created by the now-defunct AppDomain.
EDIT
I need to do this in my C# code inside my web application. I know it can be done; I did it ages ago but have since lost the code and forgotten how I did it.
For full trust you can use HttpRuntime.UnloadAppDomain(). If you aren't running in full trust you can modify the last write time on the web.config file. Rick Strahl has wrapped these two approaches up in a nice class.
You can "touch" the web.config file (i.e. rewrite it to disk unchanged), or any file in the bin directory to recycle the application. Of course this means the identity under which your application is running needs appropriate permissions.
Lately I seem to be answering my own questions a lot :P
Here we go:
HttpRuntime.UnloadAppDomain();
If all the options above fail, you can also create an endless recursive function as a final resort. The resulting stackoverflow exception will force a reload of the application. (don't do this when you have the visual studio debugger attached)
In IIS you can recycle the worker processes. You don't need to restart IIS.
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/24e3c22e-79a9-4f07-a407-dbd0e7f35432.mspx?mfr=true
If you have created a separate application pool for your application, you can reset the Application Pool.
In general, it's always a good idea to have separate app pool's for each application.
I'm being asked to look into a problem that occurs intermittently on a WebServer running my team's application.
Essentially, we have a webservice that does a lookup between codes. If you have Code Type A, you can use it to look up the corresponding Code Type B. Periodically, when memory is running low, when this webservice is called, a null reference exception is being thrown. Essentially, this service loads a lookup file into cache with a dependency on the file, so if the file chages, the cache is reloaded with the new file. The priority on the cache object is set to default. I'm guessing that somewhere in the code, it isn't being verified that the cache object is still there and when memory on the server gets low, that object is dumped causing the error. I'd like to be able to recreate the error and verify before I start digging into this code.
Is there a way in IIS manager (or from the command prompt) to force a running web app to dump it's cache? I would think that this should recreate the condition and therefore recreate the bug. Not to mention, seeing the detail error should lead to the right section of code.
Thanks,
Steve Brouillard
My gut reaction would be to set the WebMethod's CacheDuration to zero, then back to whatever you want on an ongoing basis. I haven't tried this, but I think this would dump the cache then start it forming again...
I found a utility that can be added to ASP.NET apps that will allow you to dynamically manage the cache as a whole or individual cache objects. Thanks to .NET Rocks! and dnrtv.
Here's a link to the tool that I used. This allowed me to clear just the specific objects in question, on the fly, and prove the error.
Thanks to everyone for your help. ASP Alliance Cache Manager.
Steve