Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Reference Application("") vars?

Reply
Thread Tools

Reference Application("") vars?

 
 
Keith Chadwick
Guest
Posts: n/a
 
      11-04-2003
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

 
Reply With Quote
 
 
 
 
Kevin Spencer
Guest
Posts: n/a
 
      11-04-2003
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
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


 
Reply With Quote
 
 
 
 
Keith Chadwick
Guest
Posts: n/a
 
      11-04-2003
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.
>



 
Reply With Quote
 
Kevin Spencer
Guest
Posts: n/a
 
      11-04-2003
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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.
> >

>
>



 
Reply With Quote
 
Keith Chadwick
Guest
Posts: n/a
 
      11-05-2003
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > 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.
> > >

> >
> >

>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ASP.NET 2.0: master pages and web user controls: reference to a non-shared member requires an object reference bminder ASP .Net 0 06-24-2005 12:22 AM
asp.net 2005 question re: "reference to a non-shared member requires an object reference" ce ASP .Net 1 06-23-2005 09:15 PM
web reference interfering with reference to component Dude ASP .Net 0 11-09-2004 11:53 AM
How to tell if a reference is project or file reference from within the IDE? Darren ASP .Net 0 10-11-2004 12:51 AM
Passing the value by reference is same as pointer by reference sam pal C++ 3 07-16-2003 09:14 PM



Advertisments