Unpin assembly version #135
Labels
Comments
|
See PowerShell/vscode-powershell#2538 (comment) and PowerShell/vscode-powershell#2538 (comment) for the particular breakdown of the issue. I see in serilog/serilog#1319 that this is by design. Is there a way to ensure we load the right DLL? |
|
Probably time to unpin, now that the NuGet/.NET ecosystem has settled down a bit around this 👍 |
nblumhardt
changed the title
nblumhardt
added a commit
to nblumhardt/serilog-sinks-file
that referenced
this issue
Jun 22, 2021
|
What are the next steps here? What's the worst that can happen if we unpin the version? |
|
@dkattan let's find out! :-) (Most likely - we'll see an uptick in support requests from folks whose tooling doesn't generate binding redirects correctly, which was a major pain in the past, but should hopefully be less so now.) |
nblumhardt
added a commit
that referenced
this issue
Jun 22, 2021
* Initial Nullable Support * Update Nullable Reference Support * Update appveyor config * Update Test Project * Update Test Project * Code Format * Code Refactor * Remove unnecessary references * Simplifying Constants * Add More TargetFrameworks for Update References Cleanup References * Remove netcoreapp3.0 to use netstandard2.0 insted * Unpin the assembly version; fixes #135 * Remove matching test Co-authored-by: Nicholas Blumhardt <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Looks like the assembly version is out of sync with the actual version.
This causes issues when loading from the GAC on .NET Framework because if v3 of
Serilog.Sinks.Fileis loaded in the GAC with assembly version 2.0.0.0... and we depend onSerilog.Sinks.Filev4 functionality... things won't work.As seen here: PowerShell/vscode-powershell#2538
The text was updated successfully, but these errors were encountered: