SqlClient and System.TypeInitializationException - Real Head Scratcher

S

Smithers

I solved this, but would appreciate an explanation if one is to be
had...this seems like a real WTF to me (sorry, I'm particularly put out
right now).

Please note 2 questions following the explanation of the issue:

This humble line of code choked:

System.Data.SqlClient.SqlConnection c = new
System.Data.SqlClient.SqlConnection();

Unbelieveable - eh? It's in a normal, "goin' down the road" Windows Forms
class - nothing fancy.

Here's the exception, followed by 4 levels of inner exceptions:

System.TypeInitializationException : The type initializer for
'System.Data.SqlClient.SqlConnection' threw an exception."

Inner exception:
"The type initializer for 'System.Data.SqlClient.SqlConnectionFactory' threw
an exception.

Next inner exception:
"The type initializer for 'System.Data.SqlClient.SqlPerformanceCounters'
threw an exception."

Next inner exception:
"Configuration system failed to initialize"

Next inner exception:
"Unrecognized configuration section MyCustomConfigurationSectionNameHere"

SOLUTION:
At the end of the day, I solved this be deleting the custom configuration
section in App.config (I hadn't yet created an entry for it in
<configSections> where all custom configuration sections are supposed to
have an entry. I suspect I could have created that entry as another solution
to this problem).

QUESTION #1:
How and why does the SqlClient's connection object care about App.config...
much less CHOKE when a custom configuration section is in App.config that
isn't completely defined? FWIW I'm NOT using App.config to store
connectionStrings - so the SqlClient has no business, AFAIKT, caring that
much about App.config. Plus I'm doing all kinds of things elsewhere with
App.config and custom configuration sections and SectionHandlers - and none
of those things choked.

QUESTION #2:
WHY does the problem NOT occur when stepping through the code? That is the
case: the problem does NOT surface when stepping through the code. It only
happens if we let the code execute without stepping through. For the heck of
it I event put the thread to sleep for a sec and let it rip (no break
points) and it choked. But put in a break point and step through and the
exception does NOT happen.

I'm the last person to claim to have found a bug - thus I'm asking for a
rational explanation for this one - if one is to be had.

FWIW: I'm using VS2008 Beta2.... also duplicated exact same behavior in
VS2005/SP2. The only difference is that VS2008 let me easily view the nested
inner exceptions all the way down to the "root cause", whereas 2005 only
gave me the first inner exception.

TO DUPLICATE:
Here is your entire App.config (could have more, but this will suffice):

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<SomeSection someAttribute="yo" />
</configuration>

Put the following into a Button_Click event handling procedure in a Windows
Forms form. You'd have to substitute your ServerName or IP, database name,
UserID and password , of course:

string cs = "Data Source=SqlServerNameOrIP; Initial Catalog=DatabaseName;
Trusted_Connection=false; Password=******;User ID=BigJimSlade";
System.Data.SqlClient.SqlConnection c = new
System.Data.SqlClient.SqlConnection();
c.ConnectionString = cs;
c.Open();

if (c.State == System.Data.ConnectionState.Open)
{
MessageBox.Show("Yup");
}
else
{
MessageBox.Show("Nope");
}

Run the code with and without <SomeSection... /> in App.config - you'll see
what I'm talking about. Also try it stepping through vs not stepping through
(with App.config having the <SomeSection /> in it).

Thanks!
 
M

Marc Gravell

re the config section; if your configuration file is borked (such that
the system wide configuration parser isn't happy), then things will
break. A quick search on "sqlconnection performance counters" reveals
that these counters are (as expected) configured via the config file:
http://msdn2.microsoft.com/en-us/library/ms254503(vs.80).aspx

<system.diagnostics>
<switches>
<add name="ConnectionPoolPerformanceCounterDetail"
value="4"/>
</switches>
</system.diagnostics>

So OK, you could argue that SqlConnection should be a little bit more
defensive, and simply use the defaults if it errors reading the
config. But at the same time, you could argue that an invalid
configuration is an invalid configuration, and at leats it highlighted
the exact error to you.

As for why it doesn't crash when you step through - no idea; this
makes no sense to me either.

Marc
 
S

Smithers

Marc Gravell said:
re the config section; if your configuration file is borked (such that
the system wide configuration parser isn't happy), then things will
break. A quick search on "sqlconnection performance counters" reveals
that these counters are (as expected) configured via the config file:
http://msdn2.microsoft.com/en-us/library/ms254503(vs.80).aspx

<system.diagnostics>
<switches>
<add name="ConnectionPoolPerformanceCounterDetail"
value="4"/>
</switches>
</system.diagnostics>

So OK, you could argue that SqlConnection should be a little bit more
defensive, and simply use the defaults if it errors reading the
config. But at the same time, you could argue that an invalid
configuration is an invalid configuration, and at leats it highlighted
the exact error to you.

As for why it doesn't crash when you step through - no idea; this
makes no sense to me either.

Marc


Thanks for the research Marc,...

RE:
<< But at the same time, you could argue that an invalid configuration is
an invalid configuration >>

True - But part of the problem with the configuration system, IMO, is that
it's difficult to know what constitutes an invalid configuration. Yes, the
schema is documented, but it's hard to know when some obscure configuration
rule is violated - like the one I just apparently violated. Another example
I've stumbled across is that when custom configuration sections are added,
then the mandatory <configSections... /> section MUST appear physicaly at
the top of the .config file - otherwise the configuration system won't
initialize. In that case we only get a "failed to initialize" message with
no guidance to relocate the <configSections> element to the top of the file
(immediately after the opening <configuration> element). The configuration
system is the least well-documented part of .NET that I have found. If one
wants to truly understand it, then codeproject has a 3-part article series
by Jon Rista that is far better than anything Microsoft has put out on the
subject of custom configuration (for those interested).

RE:
<< ... and at leats it highlighted the exact error to you.>>

Not exactly. I'd agree if it was the first exception or even it's inner
exception. In that case my OP here never would have happened. But it wasn't
until the 4th nested inner exception that it was pinpointed. I'm glad this
happened in VS2008 because VS2005 only gives the first two:

"The type initializer for 'System.Data.SqlClient.SqlConnection' threw an
exception."

and it's inner exception:

" The type initializer for 'System.Data.SqlClient.SqlConnectionFactory'
threw
an exception"

.... which doesn't get us even close to what the real problem was. Maybe 2005
pinpoints it as well, but via some other mechanism that I wasn't using.

Separately, It seems like any reasonable debugging effort finds us stepping
through the code early in the debugging efforts. This is why it's
particularly crazy-making on this one - that it doesn't show up when
stepping through code. Why should the configuration system have some rule
that states "choke on invalid configuration files, but only when *not*
debugging.". That's just plain old stupid - and it's what apparently is
happening. And I've tried this on two machines, so I doubt it's anything
about my particular setup.

-S
 
M

Marc Gravell

The configuration system is the least well-documented part of .NET that I
have found.
Perhaps. It would have some competition, though ;-p
If one wants to truly understand it, then codeproject has a 3-part
article series by Jon Rista that is far better than anything Microsoft has
put out on the subject of custom configuration (for those interested).

Thanks for the tip. I will definitely read those.
Direct url (part 1): http://www.codeproject.com/dotnet/mysteriesofconfiguration.asp

Marc
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top