What's the difference between Application.Contents and Application.StaticObjects in Classic ASP? <p>There are two collections in the <a href="http://www.w3schools.com/asp/asp_ref_application.asp" rel="nofollow"><code>Application</code> object</a> in Classic ASP:</p> <ul> <li><code>Application.StaticObjects</code>, filled in <code>&lt;object&gt;</code> sections in <code>global.asa</code></li> <li><code>Application.Contents</code>, filled by whatever code decides to store something there, including <code>&lt;script&gt;</code> sections in <code>global.asa</code></li> </ul> <p>I note one apparent disadvantage of the <code>StaticObjects</code> collection: You cannot initialize objects you store. Let's take the example of an XML document. You can store a free-threaded DOM object there, but how if you wanted to preload an XML file? I cannot see a way to achieve this.</p> <p>Does <code>StaticObjects</code> have any advantage to compensate for this disadvantage?</p> <p>More generally, how are these collections different with regard to things like concurrency or access or whatnot?</p> <hr> <p>The discussion below has shown that there actually is an advantage to using <code>&lt;object&gt;</code> and hence <code>Application.StaticObjects</code>, and that is <em>lazy evaluation</em>. But then, of course, lazy evaluation is something you can easily code yourself (and with greater flexibility) in a script. Still, for application-scoped singletons to be created on demand, the <code>&lt;object&gt;</code> tag can be useful.</p>