Hi George,
Hi George,
With all respect, i must say you're talking rubbish. I have used
"static"
approach in .NET many times without any problems, I also come from C++
world
but things look different in .NET, let me start from the beginning.
.NET
static constructor is used to initialize static data members as soon as
the
class is referenced first time, whereas an instance constructor is used
to
create an instance of that class with <new> keyword (it is called "lazy
initialization"), not as you said "static constructor is executed
first
thing application is loaded into memory and only then execution point
is
given to WinMain or whatever it is in ASP.NET world". It is a big
difference
because it will not be run if you have not used it anywhere. In
addition,
ConfigurationManager (which is actually called from
WebConfigurationManager)
uses "lazy initialization" as well meaning it loads the contents of the
web
config only if it has been requested. As you may expect, ASP.NET gets
many
things from the web config anyway. Initialization on demand fixes
"static
initialization order fiasco" in C++, which you pointed out. So don't
worry
about this issue as it does not exist in C#.
King regards
Milosz
--
Milosz
:
I would say it's a novel idea (at least for me). But I would classify
it
as
dangerous. Have you actually tried to use it?
Here is an explanation:
Are you positive that .NET library is properly initialized at the
point
when
static constructor called?
I mean that your
System.Configuration.ConfigurationSettings.AppSettings["ConnectionString"];
will actually work correctly.
I would imagine that when application is loaded into memory .NET must
do
a
lot of work before this line can be executed... Like load web.config
for
example. Or even determine that it must be web.config and not
executablename.config...
And static constructor is executed first thing application is loaded
into
memory and only then execution point is given to WinMain or whatever
it
is
in ASP.NET world.
------------------------------------------------------------------
I apologize, I hate to be the downer here.... But I would stick with
calling
it in Application_Start. Nobody wants it's application suddenly stop
working
(even if it does now) when you switch to new version of .NET
PS: I know those problems first hand when I worked on C++ (long time
ago)
and application would blow up when i called printf in static
constructor.
Thanks
George.
Hi George,
Just a small suggesyion - no need for calling Init method from
application
start. It enough to use a static constructor.
--
Milosz
:
I always have a class with static varaibles in my applications for
that
purpose....
Call it clsGlobal for example.
class clsGlobal
{
public static string _sConnection;
public static void Init()
{
_sConnection =
System.Configuration.ConfigurationSettings.AppSettings["ConnectionString"];
}
public static string FormatMoney(decimal dTotal)
{
return dTotal.ToString("$0.00");
}
}
Application_Start(...)
{
clsGlobal.Init();
}
Then everywere in my application i use
clsGlobal._sConnection
or something like
<%#clsGlobal.FormatMoney(Eval("OrderTotal"))%>
Hope you get an idea....
George.
message
Your scenario is basically what Application state is for.
-- Peter
To be a success, arm yourself with the tools you need and learn
how
to
use
them.
Site:
http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://ittyurl.net
:
In addition to Web.config, I have a few configuration values
that I
store
in
a sql server database. I would like to read them from the
database
only
once
per Application.Start (there is no need to read the values per
session,
as
the values are used throughout the entire application and are
needed
by
many
pages).
Just wondering if Application state would be the best place to
store
these
values. Are there better alternatives for my scenario?
I don't think the Cache is a good alternative because items in
it
can
get
removed unpredictably, and I need these values to hang around on
a
permanent
basis.
Your comments and thoughts are appreciated.
. Anyway, have a nice weekend.