text:
Q: Using HttpContext.Current.Application to store simple data I want to store a small list of a simple object (containing three strings) in my ASP.NET MVC application. The list is loaded from the database and it is updated rarely by editing some values in the site's admin area.
I'm thinking of using HttpContext.Current.Application to store it. This way I can load it in the Global.asax:
protected void Application_Start()
{
    RegisterRoutes(RouteTable.Routes);

    HttpContext.Current.Application["myObject"] = loadDataFromSql(); // returns my object
}

And then can easily reference it from any controllers or views as needed. Then in the event, the admin area calls the updateMyObject controller action, I can just update the DB and load it in again and replace HttpContext.Current.Application["myObject"].
Are there any cons to doing this? It seems like it will work fine for what I am trying to achieve, however does anyone know of a better way to do this, assuming there is some major disadvantage to the method I've laid out?

A: HttpContext.Current.Application is essentially a hangover that is needed for backwards compatibility with classic ASP.  It's essentially a static Hashtable with classic ASP locking semantics (Application.Lock / Application.UnLock).
As a weakly-typed Hashtable, you will need to cast objects you retrieve:
MyObject myObject = (MyObject) HttpContext.Current.Application["myObject"];

In an ASP.NET application that is not a migration from classic ASP, I would prefer using other standard .NET stuff, such as:

*

*A static field, using .NET locking semantics if you need locking (e.g. the C# lock keyword, or a ReaderWriterLockSlim instance, depending on your requirements):
static MyObject myObject = LoadFromSql();

*The ASP.NET Cache - which has rich functionality for managing expiration, dependencies, ...

A: Yes, using HttpContext.Current.Application will work fine for what you are doing. No problems.
HttpContext.Current.Application is simply a reference to the static global HttpApplicationState object in .NET for your Web Application, of which there should be one global instance per web application. By storing data there, you provide fast, thread-safe access to your global variables. Be sure to lock them when updating values, as in this example:
System.Web.HttpContext.Current.Application.Lock();
System.Web.HttpContext.Current.Application["WebApplicationPath"] = MyWebApplicationPath;
System.Web.HttpContext.Current.Application.UnLock();

As others have mentioned, you can also create a series of static classes in your App_Code or other folder and there store global static values as well as your HttpContext.Current.Application values, where they can be safely checked for values or updated from the database, or update and check each other, working in tandem. I usually create a static global class to assist in the management and retrieval of the Application variables I store. In this way you have both the state dictionary of the HttpApplicationState class and the web application static objects working together to share and maintain global values. (Keep in mind each static class is assigned per worker process and there may be as many as 10 WP on average by default on many IIS web servers/web applications. So keep data in static types to a minimum.)
Keep in mind as some mentioned server farms do not share Application state. There are many ways to manage this. I'm not a fan of cache because of the ways in which it can expire, fail, become stale, or get corrupted. A simpler solution is to simply use use the database and URL querystrings to communicate across servers and maintain state. Good luck!

A: What you actually do is Caching, and it's great, since you reduce calls to an external storage (a database or a file, whatever). The trade-off is memory usage, of course. Now, almost any modern web framework, including ASP.NET, includes some kind of a caching mechanism. Either you use it, or you use some kind of a global variable.
Storing data in ASP.NET's built-in Cache object has some significant advantages, since this mechanism actually checks the memory usage and removes the cached data according to some rules.
However, if the data you want to cache is intensively used across the application, and its size is not too large (say, smaller than 1 MB), you may want to store it in as a global variable.
In ASP.NET, global variables are achieved by either using the Application object, like you described in your question, or by writing public static properties/fields in an internal/public class.
Here's my solution to static properties. Note that I use a locking object, to protect the inner data from corruption. It looks like this:
public class WhateverClass
{
  private static object theLocker = new object();
  private static YourDataType theData;
  public static YourDataType TheData
  {
    get
    {
      lock (theLocker)
      {
        return theData;
      }
    }
    set
    {
      lock (theLocker)
      {
        theData = value;
      }
    }
  }
}

The usage is very simple:
First time, in Application_Start:
protected void Application_Start()
{
    RegisterRoutes(RouteTable.Routes);

    WhateverClass.TheData = loadDataFromSql();
}

In any controller:
var myData = WhateverClass.TheData;

This approach is better because you have type safety, since this public static property can be explicitly declared with the exact type. In addition, this kind of storage is more testable since it doesn't depend on the web context.
HTH!

A: If you're deploying to a single web server the approach would work.  Consider the Cache object for this as it provides more options for expiration if you need such functionality.  (See a comparison, albeit an aged one, here.)
If you're ever going to deploy to a web server farm or equivalent you should use memcached or another web farm friendly caching mechanism.  Both the Application and Cache objects only typically exist in a single server context; if your user could be hitting multiple web servers during their session (and the cache needs to be identical) you'll need a shared cache that can be seen from each of the potential web servers.
Regardless of which path you take you will need to invalidate/reload your cache whenever the underlying data changes, which is custom code that varies by app.
This approach works well and can speed things considerably but it's a bit more work than you may realize at first glance...

A: Application_Start really only gets fired on App Pool Recylce's, IIS Resets or reboots.  If your updating these values that infrequently, why not store them in your web.config and access them that way?
That being said, I don't think there is anything wrong with your approach.  Though more typically I've seen people using config files for rarely changed values.


text:
Lokesh Manufactures more than 800 CNC Machines Per Year
Lokesh Machines
Long lasting accuracies, 25 years older machines are still delivering finished parts with original accuracy at Ashok Leyland & other OEMS
EURO 6 SPM's supplied to Volvo Eicher
We Thank M/s Volvo Eicher Commercial Vehicles Ltd
First Time In India, SPM's Were Delivered With Auto Component Loaders Like Pallet Changers
Auto Component Division
The auto component division of Lokesh is India's leading supplier of machined engine blocks,heads & connecting rods
Leading Machine Tools Manufacturer in India
Lokesh machines limited was incorporated on 17 dec 1983 and started commercial operations in 1985 at hyderabad.
Lokesh machines limited was incorporated on 17th December 1983 and started commercial operations in 1985 at Hyderabad.
To champion high quality parts eco system through manufacturing services and machining services.
ACCEPT CHALLENGE, CUSTOMER CENTRICITY, CREATE UNIQUENESS, FREEHAND
Lokesh ranks amongst the top five machine tool manufacturers in the country.
Approximately 20% of machines are supplied to auto OEMs, 60% of supplies to auto ancillaries & 20% to general industries and exports.
Lokesh - Special Purpose Machines are supplied mainly to the Automobile industry, Power Generation and General Engineering Industries. These are custom built to the client's requirements. The application of these machines are in the areas of Metal cutting and Machining.
All machines are manufactured as per the process capability requirement of the components.
Lokesh is a leader in Cam & Crank borers, Fine borers & Finish Milling machines.
The auto component division of Lokesh is india's leading supplier of machined engine Cylinder Blocks, Cylinder Heads & Fractured Connecting Rods.
The line at Lokesh Production facility at Pune is a testimony to the implementation of breakthrough concepts in Automation, Quality Control & Traceability equipped with Poka Yoke and other modern manufacturing concepts.
Lokesh Machines Has Successfully Executed Volvo Eicher's Euro 6 Engine Project
Learn More News

redpajama_set_name: RedPajamaCommonCrawl


text:
import sys

from twisted.internet import reactor, ssl
from twisted.python import log

from karmabot.core.client import KarmaBotFactory

def main():
    from optparse import OptionParser
    parser = OptionParser(usage="usage: %prog [options] channels")

    # IRC connection options
    parser.add_option("-s", "--server",
                      action="store", dest="server",
                      default="irc.freenode.net",
                      help="IRC server to connect to")
    parser.add_option("-p", "--port",
                      action="store", type="int", dest="port", default=None,
                      help="IRC server to connect to")
    parser.add_option("--ssl",
                      action="store_true", dest="ssl", default=False,
                      help="use SSL")
    parser.add_option("--password",
                      action="store", dest="password", default=None,
                      help="server password")
    parser.add_option("-n", "--nick",
                      action="store", dest="nick", default="karmabot",
                      help="nickname to use")
    # Bot options
    parser.add_option("-v", "--verbose",
                      action="store_true", dest="verbose", default=False,
                      help="enable verbose output")
    parser.add_option("-d", "--data",
                      action="store", dest="filename", default="karma.json",
                      help="karma data file name")
    parser.add_option("-t", "--trust",
                      action="append", dest="trusted", default=[],
                      help="trusted hostmasks")
    parser.add_option("-f", "--facets",
                      action="append", dest="facets", default=[],
                      help="additional facets to load")

    (options, channels) = parser.parse_args()

    if not channels:
        parser.error("You must supply some channels to join.")
    else:
        log.msg("Channels to join: %s" % channels)

    if options.verbose:
        log.startLogging(sys.stdout)

    if not options.port:
        options.port = 6667 if not options.ssl else 9999

    factory = KarmaBotFactory(options.filename, options.nick,
                              channels, options.trusted, options.password,
                              options.facets)
    if not options.ssl:
        reactor.connectTCP(options.server, options.port, factory)
    else:
        reactor.connectSSL(options.server, options.port,
                           factory, ssl.ClientContextFactory())
    reactor.run()

if __name__ == "__main__":
    main()

redpajama_set_name: RedPajamaGithub


text:
Q: How to listen for a change in app permission Currently looking for a way to listen for if an app's lock screen permission has been revoked.
I know one can actively query for an app's access information with:
var accessStatus = Windows.ApplicationModel.Background.BackgroundExecutionManager.getAccessStatus();

But I am looking for a way to listen to any change (or at least revocation) to the lock screen or notification permission status.

A: An app can register that a background task is run when it is removed from the lock screen.  In addition, an app can similarly find out if it is added to the lock screen - a user can add an app to the lock screen without the app requesting itself to be added (e.g., when the app is not running via user settings).
The system triggers of interest are
lockScreenApplicationAdded and lockScreenApplicationRemoved.
The background task sample on MSDN can be adapted to be trigger a background task when the user adds or removes the app from the lock screen.

redpajama_set_name: RedPajamaStackExchange