The type initializer for 'System.Data.SqlLocalDb.Logger' threw an exception.

Question

The type initializer for 'System.Data.SqlLocalDb.Logger' threw an exception.

damianh opened this issue 9 years ago · 16 comments

We use SqlLocalDB mostly in tests at this time and we're seeing this occur occasionally (i.e. non-deterministically). When it does though, the error and stack trace is always the same?

The type initializer for 'System.Data.SqlLocalDb.Logger' threw an exception.

  at System.Data.SqlLocalDb.SqlLocalDbApi.GetInstanceNames()
   at System.Data.SqlLocalDb.SqlLocalDbProvider.GetInstances()
   at System.Data.SqlLocalDb.Extensions.GetOrCreateInstance(ISqlLocalDbProvider value, String instanceName)
   at eVision.PermitVision.Infrastructure.DatabasePool.Initialize() in D:\dev\eVision.PermitVision\src\eVision.PermitVision.Tests\Infrastructure\DatabasePool.cs:line 120
   at eVision.PermitVision.Infrastructure.DatabasePool..ctor() in D:\dev\eVision.PermitVision\src\eVision.PermitVision.Tests\Infrastructure\DatabasePool.cs:line 33
   at eVision.PermitVision.Infrastructure.DatabasePool.<>c.<.cctor>b__24_0() in D:\dev\eVision.PermitVision\src\eVision.PermitVision.Tests\Infrastructure\DatabasePool.cs:line 23
   at System.Lazy`1.CreateValue()

Type is not resolved for member 'Serilog.Context.ImmutableStack`1[[Serilog.Core.ILogEventEnricher, Serilog, Version=1.5.0.0, Culture=neutral, PublicKeyToken=24c2f752a8e58a10]],Serilog.FullNetFx, Version=1.5.0.0, Culture=neutral, PublicKeyToken=24c2f752a8e58a10'.

at System.AppDomain.GetHostEvidence(Type type)
   at System.Security.Policy.Evidence.GetHostEvidenceNoLock(Type type)
   at System.Security.Policy.Evidence.RawEvidenceEnumerator.MoveNext()
   at System.Security.Policy.Evidence.EvidenceEnumerator.MoveNext()
   at System.Configuration.ClientConfigPaths.GetEvidenceInfo(AppDomain appDomain, String exePath, String& typeName)
   at System.Configuration.ClientConfigPaths.GetTypeAndHashSuffix(AppDomain appDomain, String exePath)
   at System.Configuration.ClientConfigPaths..ctor(String exePath, Boolean includeUserConfig)
   at System.Configuration.ClientConfigPaths.GetPaths(String exePath, Boolean includeUserConfig)
   at System.Configuration.ClientConfigurationHost.RequireCompleteInit(IInternalConfigRecord record)
   at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
   at System.Configuration.BaseConfigurationRecord.GetSection(String configKey)
   at System.Data.SqlLocalDb.Configuration.SqlLocalDbConfigurationSection.GetSection()
   at System.Data.SqlLocalDb.SqlLocalDbConfig..cctor()

Often re-running the test "fixes" things, but I'd rather it never happen at all. It seems like a race condition loading types. What I don't understand is how or what serilog (we have that referenced in our tests) has to do with this. There is no app.config. There is a .Tests.Config which mostly contains binding redirects. Fails in ncrunch and resharper test runner.

Any thoughts?

Answer 1 · 2015-12-11T10:45:30.000Z

Interesting. I'll have a more thorough think about this later today.

From a cursory glance at the stack trace, I'm wondering if SqlLocalDb is going into the configuration sub-system to make its own checks, which is then somehow hitting some sort of evidence assert in System.Configuration loading types, which is then throwing an error because of something it doesn't like in Serilog. Is it possible you've got an occasional assembly binding problem somewhere related to Serilog or one of its dependencies, like a race condition in a file copy during build?

I suppose I could consider putting a try-catch around this initialization to ignore the problem so the exception doesn't take everything down.

Answer 2 · 2015-12-11T11:12:43.000Z

Thanks for the quick response. I've been googling around looking for similar problems and nothing is coming up.

The exception is thrown from this line https://github.com/martincostello/sqllocaldb/blob/master/src/SqlLocalDb/Configuration/SqlLocalDbConfigurationSection.cs#L155

try-catch & ignore is a bit of a blunt approach though. :|

Personally, I'm not a fan of libs reaching into configuration.

Perhaps, instead of being static, this could be instance based that allows the caller to supply config and so, System.Configuration paths are not executed?

I don't have any other options at this point...

Answer 3 · 2015-12-11T11:28:02.000Z

Yeah, I agree that try-catch would be very hacky.

Given that the next version of the package will target .NET 4.0, I could consider making the logging initialization use Lazy<T> so that the configuration read only happens when needed.

There is a property to override the logger used, but that can probably only be altered after the line of code that's throwing executes, so wouldn't help.

I'll have a think about making the configuration injectable as well.

Answer 4 · 2015-12-11T11:33:20.000Z

I'll have a think about making the configuration injectable as well.

👍

I'm stuck now though... what do what do...

Answer 5 · 2015-12-11T11:49:16.000Z

Custom build for now...

Answer 6 · 2015-12-11T11:59:24.000Z

I'll look at doing this within the next week or so (maybe later today or this weekend). There's various stuff been lying around that could have gone into a v1.15.0, but nothing important enough to bother with a new version.

Answer 7 · 2015-12-11T13:39:24.000Z

I've just committed 45e799d to lazily initialize the default logger. Does a build with that change fix your issue?

Answer 8 · 2015-12-11T17:58:05.000Z

@damianh This issue sounds similar to what you're experiencing: serilog/serilog#128. Similar error in a forum post here.

Answer 9 · 2015-12-12T14:05:56.000Z

Will try it out possibly tomorrow, but definitely Monday. cheers.
On 11 Dec 2015 2:39 pm, "Martin Costello" notifications@github.com wrote:

I've just committed 45e799d
45e799d
to lazily initialize the default logger. Does a build with that change fix
your issue?

—
Reply to this email directly or view it on GitHub
#15 (comment)
.

Answer 10 · 2015-12-15T09:22:10.000Z

@damianh Did you get anywhere with trying out a build with the change?

Answer 11 · 2016-01-08T09:58:08.000Z

@damianh Bump :)

Answer 12 · 2016-01-25T23:53:43.000Z

Closing as external unless evidence to the contrary found.

Answer 13 · 2016-06-18T18:47:00.000Z

Oh I'm so behind on this one, but yeah looks like it's a serilog issue serilog/serilog#109

Answer 14 · 2016-06-18T22:40:32.000Z

Thanks for getting back with the link :)

Answer 15 · 2016-06-18T22:41:23.000Z

Did the change in v1.15 help at all?

Answer 16 · 2016-06-18T23:50:16.000Z

Unfortunately no, it didn't. Seems I'll have to see if serilog 2 fixes it.
On 19 Jun 2016 12:41 a.m., "Martin Costello" notifications@github.com
wrote:

Did the change in v1.15 help at all?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#15 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AADgXMqJI0Hfhwlr21hNxECYsLb_rojQks5qNHQUgaJpZM4GzdVK
.