fixes #63 - option to control assembly source #136
Conversation
|
Tests are failing because xunit 2.x runs each test class in parallel and they're stepping on each other's changes to all the static members (either in the config package itself or all the test-support code, I'm not really sure -- but probably in DummyConsoleSink; could be the package's static reference to config though). xUnit didn't fix their settings that disable parallelization in versions that support the older .NET Frameworks, so the quick fix is to just move the one new test into the same class where there was a collision because xUnit doesn't run methods within a class in parallel. Burning a weekend afternoon nursing old unit tests for the sake of having passing tests is not the unit-testing happy-path... |
|
I like the usability of this one, but it seems like a grey area - do we really want to get into assembly scanning/loading here? It's historically been a very delicate and flaky part of .NET to get involved in. I'm not totally against it, but I'm also a bit nervous about supporting/debugging the failures that will inevitably bubble back to us, here.... Thoughts? |
|
Hmm, just looking again, I might have misunderstood how this is implemented - I see it's just switching between |
src/Serilog.Settings.Configuration/ConfigurationLoggerConfigurationExtensions.cs
Outdated
Show resolved
Hide resolved
src/Serilog.Settings.Configuration/ConfigurationLoggerConfigurationExtensions.cs
Outdated
Show resolved
Hide resolved
src/Serilog.Settings.Configuration/LoggerConfigurationSupport.cs
Outdated
Show resolved
Hide resolved
|
Just one nitpick comment, otherwise seems good-to-go, if we're satisfied this will sort out #63 👍 |
|
No sweat, I debated about where to put that and whether to use a specific or general name. Think this warrants documenting in the README? |
|
👍 I think we can deal with README updates down the line; pushing this through so we can assemble a final 3.0 dev build :-) 🎉 |
When the
DependencyContextparameter is null, theonNullDependencyContextdefines the interpretation -- either to scan in-memory assemblies (the default, when available) or scan DLL files in the working directory (optional, or the fallback if the default is not available). See #63 for discussion.