Web Service throws exception during Application_Start

[fm]

We have some static information load from web.config during the
application_start of our web service.

However, if there is an error during this startup, the consumer gets back an
ugly error message starting like: Client found response content type of
'text/html; charset=utf-8', but expected 'text/xml'. The request failed with
the error message: --

Errors in the Global class seem to step outside of the Soap Fault standards.

What is worse is that even though there is an error on Startup, the Web
Service actually starts up. But of course the code in Application_Start did
not complete so now the Web Service is running in error.

Am I correct or am I doing something wrong?

fm

 

[Mujtaba Syed]

ASMX web services use the ASP.NET pipeline. If there is an error in
Application_Start, it will be returned to the client as an IIS error page.
One workaround is that you could trap all errors in Application_Error and
"hand-write" a SOAP envelope with an appropriate SOAP fault to the response.

Mujtaba.

 

[Dan Rogers]

Something else you can do is change the auto-generated HTML page for
specific errors. By default, these are HTML, but you can change them from
the IIS administration console.

Since you are having this kind of problem I wonder why are you doing
applicaiton start kind of logic? In general, you want web services to be
stateless. Using the application start feature implies you aren't staying
statless - which may be a cause of frustration for you ongoing. The
application.start, session, etc are ASP programming model entities for
managing web sites and web page based applications (using a general tone
here - I'm sure that there are exceptions to the rule as always).

Try NOT using applicaiton start for your web services....

Regards

Dan Rogers
Microsoft Corporation
--------------------

 

[fm]

During application startup, we are loading static values from web.config. We
expose those values to the rest of the application as shared properties in
the Global class. This is to be consistent with our ASP.NET web applications.
I suppose we could load these values on session start for web services but
that seems like a lot of extra processing during runtime. Perhaps with web
services we should have the code call our web.config wrapper methods
directly. But then you loose that layer of abstraction if we move the
location of those values (to a database or other data store).

The only times this logic should bomb is if web.config does not match what
the code is trying to read (that is how I discovered this problem). But the
fact is it could still error out. I think one thing I will investigate is
throwing a hand-written SOAP envelope (does not sound too pretty either).

 

[Mujtaba Syed]

Hi:

One solution could be to have a singleton-instance class that loads all the
properties. The constructor of that class reads the web.config and has
public properties that exposes those settings. And in all web methods that
you want to use the configuration key/value pairs, you get hold of that
singleton instance and invoke properties on it. The *first call to any web
method* will do the *actual loading from web.config* and incase there is an
error, it will go as a SOAP fault.

Hope this helps,
Mujtaba.

 

[fm]

Thanks, I will consider that. Like a Global on top of a Global

 

[Dan Rogers]

Have you considered using the config classes that are provided as part of
the WS stack? These are cached on start for you, so that if you access a
config value from within a web method, you get the cached value. If you
later change the web.config file, the service is restarted for you, so
subsequent calls see the new values.

There is no provision for redirecting config to some other non-file based
persistence mechanism at this point. But if you try out what is already
provided, I think you'll find it does the trick. The added value is that
if there is a config parsing problem, the application WON'T start properly
(an error is returned to any call).

I hope this helps

Dan Rogers
Microsoft Corporation
--------------------

 

[fm]

My understanding is that the only class to read appfrom web.config (which
logically merges machine.config) is
System.Configuration.ConfigurationSettings? We already use GetConfig and
AppSettings. We use this class to populate shared Global properties.

Where we are getting the data from was not the issue, just the timing of it.
Loading application state at Application_Start sounds like a bad spot in an
ASP.NET WebService even though it is fine in an ASP.NET Web Application.

We'll make do.