«

I am having some trouble referencing an Application("myVar") variable from within a module.vb file on my ASP.NET site.

According to the documentation I should be able to reference System.Web.HttpApplication but it does not seem to like that one bit.
I also have a MSXML2.DOMDocument30 defined as a public object within the vb module which is loaded during the application start up with a bunch of XML. What is weird is that the data contained within the XML object seems to remain as an application level even though it is not defined as an application variable. The xml is stored within an application("myxml") variable but the object is not defined as an application level variable. In the old ASP module we where not supposed to declare objects within an Application variable so I am not in .NET.

I am coming from the old ASP module so I know I am thinking far to linear at this point but am I to understand that an object/var declared as public within a module.vb means its scope is application? If so, huh!

Thanks in advance

Keith

Okay, first, the Application Collection is there for backwards
compatibility, so you shouldn't be using it, as it isn't thread-safe. You
should be using the Application Cache instead. The Cache is thread-safe, and
objects stored there can be expired according to whatever rules you specify.

Second, forget the rules for ASP. EVERYTHING in .Net is an object, so store
anything you want in the Cache (except for database Connections, which
should be destroyed ASAP).

Third, to reference the Application Cache, you would have to refer to it in
context. For example, if you are writing code inside a Page class
definition, you can refer to "Cache" directly, as the Application Cache is
the "Cache" property of the Page class. If you're writing a utility class of
some sort, you need to grab the Cache from the current HttpContext, as in:
HttpContext.Current.Cache.

Finally, it might be best to forget about Modules. Although you can
certainly build Modules in .Net, they are also more for backwards
compatibility. A Module is basically a collection of Shared (static) data
and Methods, not very object-oriented. Instead, try to get used to
developing Classes and Class Libraries. You can create static (Shared)
properties and methods within a Class, but you will more often be working
with instantiated Classes. Shared/static methods and properties are more
problematic, and less likely to be necessary than instantiated Classes. A
Shared/static property is, in a sense, global, in that it is globally
accessible, but you don't have the control over accessibility that you have
with an instantiated Class property. For example, if a property is a public
property of an instantiated Class, you can have more than one instance of
it, whereas a static/Shared property exists in one and only one place. You
might say that a shared property of a module has Application scope, but it
is not the same thing as storing an object in the Application or Application
Cache. It actually exists in the heap, and, again, in one and only one
place.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Big Things are made up of
Lots of Little Things.


"Keith Chadwick" <> wrote in message
news:...
I am having some trouble referencing an Application("myVar") variable from
within a module.vb file on my ASP.NET site.

According to the documentation I should be able to reference
System.Web.HttpApplication but it does not seem to like that one bit.
I also have a MSXML2.DOMDocument30 defined as a public object within the vb
module which is loaded during the application start up with a bunch of XML.
What is weird is that the data contained within the XML object seems to
remain as an application level even though it is not defined as an
application variable. The xml is stored within an application("myxml")
variable but the object is not defined as an application level variable. In
the old ASP module we where not supposed to declare objects within an
Application variable so I am not in .NET.

I am coming from the old ASP module so I know I am thinking far to linear at
this point but am I to understand that an object/var declared as public
within a module.vb means its scope is application? If so, huh!

Thanks in advance

Keith

Ok, so what you are saying is application("") scope is now maintained via
application cache. This would be a good place to store things like my
connection string and some small XML blobs used commonly through all the
pages. How is the cache on storing objects, like a MSXML or a chunk of
transformed html?

Ok, so no modules, classes only. I can see that as modules are procedural.
I come from an ASP/VB background so to me it made sense to move my common
functions into a module for reuse by each page.

It is interesting that both the reference books I have, one from Microsoft
Press, cover application variables as if they belong and should be used.
There is only a brief mention that they are there for backwards
compatibility and no mention that you should use the cache instead. Perhaps
when starting a web project it would be nice if the UI asked you if you
wanted backwards compatibility and if not would remove those options.

One question about my SQL Server connections. You mentioned destroying them
ASAP but you would not want to have to open a connection several times on a
page load as that would not make sense, correct?

Is there a page on MSDN that provides a VISUAL MODEL of the .NET framework?
Pictures speak a thousand words!

Thanks for the info.

Cheers
Keith


"Kevin Spencer" <> wrote in message
news:...
> Okay, first, the Application Collection is there for backwards
> compatibility, so you shouldn't be using it, as it isn't thread-safe. You
> should be using the Application Cache instead. The Cache is thread-safe,
and
> objects stored there can be expired according to whatever rules you
specify.
>
> Second, forget the rules for ASP. EVERYTHING in .Net is an object, so
store
> anything you want in the Cache (except for database Connections, which
> should be destroyed ASAP).
>
> Third, to reference the Application Cache, you would have to refer to it
in
> context. For example, if you are writing code inside a Page class
> definition, you can refer to "Cache" directly, as the Application Cache is
> the "Cache" property of the Page class. If you're writing a utility class
of
> some sort, you need to grab the Cache from the current HttpContext, as in:
> HttpContext.Current.Cache.
>
> Finally, it might be best to forget about Modules. Although you can
> certainly build Modules in .Net, they are also more for backwards
> compatibility. A Module is basically a collection of Shared (static) data
> and Methods, not very object-oriented. Instead, try to get used to
> developing Classes and Class Libraries. You can create static (Shared)
> properties and methods within a Class, but you will more often be working
> with instantiated Classes. Shared/static methods and properties are more
> problematic, and less likely to be necessary than instantiated Classes. A
> Shared/static property is, in a sense, global, in that it is globally
> accessible, but you don't have the control over accessibility that you
have
> with an instantiated Class property. For example, if a property is a
public
> property of an instantiated Class, you can have more than one instance of
> it, whereas a static/Shared property exists in one and only one place. You
> might say that a shared property of a module has Application scope, but it
> is not the same thing as storing an object in the Application or
Application
> Cache. It actually exists in the heap, and, again, in one and only one
> place.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> http://www.takempis.com
> Big Things are made up of
> Lots of Little Things.
>

Hi Keith,

> pages. How is the cache on storing objects, like a MSXML or a chunk of
> transformed html?

In .Net, everything is an object. So, hopefully that clears that question
up!

> It is interesting that both the reference books I have, one from Microsoft
> Press, cover application variables as if they belong and should be used.
> There is only a brief mention that they are there for backwards
> compatibility and no mention that you should use the cache instead.

Books are written by people. Heck, I've co-authored a couple of them. .Net
is new technology, and some of the people who write books are working with
brand new technologies, such as the books that were written about .Net
before it was released fully. In any case, the best authority on .Net is the
..Net SDK, which is a free download from:

http://www.microsoft.com/downloads/d...displaylang=en

> One question about my SQL Server connections. You mentioned destroying
them
> ASAP but you would not want to have to open a connection several times on
a
> page load as that would not make sense, correct?

..Net uses Connection Pooling, and it is safer to destroy Connections each
time you use them. There are, of course, cases such as the one you mention,
in which it might be just as well to re-use the same Connection. On the
other hand, if you're using DataReaders, for example, this can be tricky, as
DataReaders cannot share a Connection. So, the short and simple answer is,
always close and re-open your Connections as quickly as possible. The long
answer is more difficult to define, and at this point in your .Net
education, probably not worth bothering with, as Connection Pooling makes
re-using Connections transparent to you, the developer.

> Is there a page on MSDN that provides a VISUAL MODEL of the .NET
framework?
> Pictures speak a thousand words!

Agreed. I think you'll find plenty of that sort of thing in the .Net SDK,
the most awesome software documentation ever written.

Best of luck to you in your endeavors, Keith.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Big Things are made up of
Lots of Little Things.

"Keith Chadwick" <> wrote in message
news:...
> Ok, so what you are saying is application("") scope is now maintained via
> application cache. This would be a good place to store things like my
> connection string and some small XML blobs used commonly through all the
> pages. How is the cache on storing objects, like a MSXML or a chunk of
> transformed html?
>
> Ok, so no modules, classes only. I can see that as modules are
procedural.
> I come from an ASP/VB background so to me it made sense to move my common
> functions into a module for reuse by each page.
>
> It is interesting that both the reference books I have, one from Microsoft
> Press, cover application variables as if they belong and should be used.
> There is only a brief mention that they are there for backwards
> compatibility and no mention that you should use the cache instead.
Perhaps
> when starting a web project it would be nice if the UI asked you if you
> wanted backwards compatibility and if not would remove those options.
>
> One question about my SQL Server connections. You mentioned destroying
them
> ASAP but you would not want to have to open a connection several times on
a
> page load as that would not make sense, correct?
>
> Is there a page on MSDN that provides a VISUAL MODEL of the .NET
framework?
> Pictures speak a thousand words!
>
> Thanks for the info.
>
> Cheers
> Keith
>
>
> "Kevin Spencer" <> wrote in message
> news:...
> > Okay, first, the Application Collection is there for backwards
> > compatibility, so you shouldn't be using it, as it isn't thread-safe.
You
> > should be using the Application Cache instead. The Cache is thread-safe,
> and
> > objects stored there can be expired according to whatever rules you
> specify.
> >
> > Second, forget the rules for ASP. EVERYTHING in .Net is an object, so
> store
> > anything you want in the Cache (except for database Connections, which
> > should be destroyed ASAP).
> >
> > Third, to reference the Application Cache, you would have to refer to it
> in
> > context. For example, if you are writing code inside a Page class
> > definition, you can refer to "Cache" directly, as the Application Cache
is
> > the "Cache" property of the Page class. If you're writing a utility
class
> of
> > some sort, you need to grab the Cache from the current HttpContext, as
in:
> > HttpContext.Current.Cache.
> >
> > Finally, it might be best to forget about Modules. Although you can
> > certainly build Modules in .Net, they are also more for backwards
> > compatibility. A Module is basically a collection of Shared (static)
data
> > and Methods, not very object-oriented. Instead, try to get used to
> > developing Classes and Class Libraries. You can create static (Shared)
> > properties and methods within a Class, but you will more often be
working
> > with instantiated Classes. Shared/static methods and properties are more
> > problematic, and less likely to be necessary than instantiated Classes.
A
> > Shared/static property is, in a sense, global, in that it is globally
> > accessible, but you don't have the control over accessibility that you
> have
> > with an instantiated Class property. For example, if a property is a
> public
> > property of an instantiated Class, you can have more than one instance
of
> > it, whereas a static/Shared property exists in one and only one place.
You
> > might say that a shared property of a module has Application scope, but
it
> > is not the same thing as storing an object in the Application or
> Application
> > Cache. It actually exists in the heap, and, again, in one and only one
> > place.
> >
> > --
> > HTH,
> >
> > Kevin Spencer
> > Microsoft MVP
> > .Net Developer
> > http://www.takempis.com
> > Big Things are made up of
> > Lots of Little Things.
> >
>
>

I must admit I understand what and where .NET is going in theory when I read
the books and online documentation. Having said that though, it is very
frustrating getting to know the .NET object model as it is so immense. It
is extra annoying considering I having been writing VB, ASP, XML, XSL and
SQL server for as long as I can remember and rip out code very quickly. Now
I find myself faced with getting frustrated with the model/syntax. Lucky
for me I am just sitting on the bench at the moment slogging through all of
this so I have the time to pull all my hairs out.

Cheers
Keith


"Kevin Spencer" <> wrote in message
news:...
> Hi Keith,
>
> > pages. How is the cache on storing objects, like a MSXML or a chunk of
> > transformed html?
>
> In .Net, everything is an object. So, hopefully that clears that question
> up!
>
> > It is interesting that both the reference books I have, one from
Microsoft
> > Press, cover application variables as if they belong and should be used.
> > There is only a brief mention that they are there for backwards
> > compatibility and no mention that you should use the cache instead.
>
> Books are written by people. Heck, I've co-authored a couple of them. .Net
> is new technology, and some of the people who write books are working with
> brand new technologies, such as the books that were written about .Net
> before it was released fully. In any case, the best authority on .Net is
the
> .Net SDK, which is a free download from:
>
>
http://www.microsoft.com/downloads/d...displaylang=en
>
> > One question about my SQL Server connections. You mentioned destroying
> them
> > ASAP but you would not want to have to open a connection several times
on
> a
> > page load as that would not make sense, correct?
>
> .Net uses Connection Pooling, and it is safer to destroy Connections each
> time you use them. There are, of course, cases such as the one you
mention,
> in which it might be just as well to re-use the same Connection. On the
> other hand, if you're using DataReaders, for example, this can be tricky,
as
> DataReaders cannot share a Connection. So, the short and simple answer is,
> always close and re-open your Connections as quickly as possible. The long
> answer is more difficult to define, and at this point in your .Net
> education, probably not worth bothering with, as Connection Pooling makes
> re-using Connections transparent to you, the developer.
>
> > Is there a page on MSDN that provides a VISUAL MODEL of the .NET
> framework?
> > Pictures speak a thousand words!
>
> Agreed. I think you'll find plenty of that sort of thing in the .Net SDK,
> the most awesome software documentation ever written.
>
> Best of luck to you in your endeavors, Keith.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> http://www.takempis.com
> Big Things are made up of
> Lots of Little Things.
>
> "Keith Chadwick" <> wrote in message
> news:...
> > Ok, so what you are saying is application("") scope is now maintained
via
> > application cache. This would be a good place to store things like my
> > connection string and some small XML blobs used commonly through all the
> > pages. How is the cache on storing objects, like a MSXML or a chunk of
> > transformed html?
> >
> > Ok, so no modules, classes only. I can see that as modules are
> procedural.
> > I come from an ASP/VB background so to me it made sense to move my
common
> > functions into a module for reuse by each page.
> >
> > It is interesting that both the reference books I have, one from
Microsoft
> > Press, cover application variables as if they belong and should be used.
> > There is only a brief mention that they are there for backwards
> > compatibility and no mention that you should use the cache instead.
> Perhaps
> > when starting a web project it would be nice if the UI asked you if you
> > wanted backwards compatibility and if not would remove those options.
> >
> > One question about my SQL Server connections. You mentioned destroying
> them
> > ASAP but you would not want to have to open a connection several times
on
> a
> > page load as that would not make sense, correct?
> >
> > Is there a page on MSDN that provides a VISUAL MODEL of the .NET
> framework?
> > Pictures speak a thousand words!
> >
> > Thanks for the info.
> >
> > Cheers
> > Keith
> >
> >
> > "Kevin Spencer" <> wrote in message
> > news:...
> > > Okay, first, the Application Collection is there for backwards
> > > compatibility, so you shouldn't be using it, as it isn't thread-safe.
> You
> > > should be using the Application Cache instead. The Cache is
thread-safe,
> > and
> > > objects stored there can be expired according to whatever rules you
> > specify.
> > >
> > > Second, forget the rules for ASP. EVERYTHING in .Net is an object, so
> > store
> > > anything you want in the Cache (except for database Connections, which
> > > should be destroyed ASAP).
> > >
> > > Third, to reference the Application Cache, you would have to refer to
it
> > in
> > > context. For example, if you are writing code inside a Page class
> > > definition, you can refer to "Cache" directly, as the Application
Cache
> is
> > > the "Cache" property of the Page class. If you're writing a utility
> class
> > of
> > > some sort, you need to grab the Cache from the current HttpContext, as
> in:
> > > HttpContext.Current.Cache.
> > >
> > > Finally, it might be best to forget about Modules. Although you can
> > > certainly build Modules in .Net, they are also more for backwards
> > > compatibility. A Module is basically a collection of Shared (static)
> data
> > > and Methods, not very object-oriented. Instead, try to get used to
> > > developing Classes and Class Libraries. You can create static (Shared)
> > > properties and methods within a Class, but you will more often be
> working
> > > with instantiated Classes. Shared/static methods and properties are
more
> > > problematic, and less likely to be necessary than instantiated
Classes.
> A
> > > Shared/static property is, in a sense, global, in that it is globally
> > > accessible, but you don't have the control over accessibility that you
> > have
> > > with an instantiated Class property. For example, if a property is a
> > public
> > > property of an instantiated Class, you can have more than one instance
> of
> > > it, whereas a static/Shared property exists in one and only one place.
> You
> > > might say that a shared property of a module has Application scope,
but
> it
> > > is not the same thing as storing an object in the Application or
> > Application
> > > Cache. It actually exists in the heap, and, again, in one and only one
> > > place.
> > >
> > > --
> > > HTH,
> > >
> > > Kevin Spencer
> > > Microsoft MVP
> > > .Net Developer
> > > http://www.takempis.com
> > > Big Things are made up of
> > > Lots of Little Things.
> > >
> >
> >
>
>