[Bug]: System.Buffers

[Aakashgunasekaran-sbi]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

This is because IIS or DNN is overwriting your web.config automatically after some time. This is a known DNN behavior — DNN can reset web.config during certain operations.

Steps to reproduce?

Step 1 — Check which System.Buffers.dll is conflicting
There are likely two copies of the DLL:
• D:\netpub\wwwroot\sbiclocal\bin\System.Buffers.dll — correct version
• GAC (Global Assembly Cache) — older version conflicting
Step 2 — Copy the correct DLL to a safe location
Keep a backup at:
D:\netpub\wwwroot\sbiclocal\bin\System.Buffers.dll
Step 3 — Lock the DLL in web.config
Open web.config and add this so it always uses the bin folder version:





The line forces .NET to always load from the bin folder, ignoring the GAC.
Step 4 — Make web.config read-only
After saving web.config, right-click the file → Properties → check Read-only. This prevents DNN from overwriting it.

Current Behavior

No response

Expected Behavior

No response

Relevant log output

Anything else?

No response

Affected Versions

develop build (unreleased), 10.3.2 (latest release)

What browsers are you seeing the problem on?

Microsoft Edge

Code of Conduct

• I agree to follow this project's Code of Conduct

[valadas]

I understand the description but what is the bug?

[Aakashgunasekaran-sbi]

The bug is:
After upgrading DNN from 9.1 to 10.2.1, a scheduled task is overwriting System.Buffers.dll in the /bin folder with an older version that does not match the version specified in web.config binding redirect.
This causes the error:
Could not load file or assembly 'System.Buffers' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)
The site goes down until the correct version of System.Buffers.dll is manually copied back to the /bin folder and IIS is reset.
A scheduled task overwrites System.Buffers.dll with an older version, causing a version mismatch and bringing the site down.

[valadas]

The suggested upgrade path is to go to 10.2.5 the classic way and then to upgrade to the latest (10.3.2 at time of writing) using the new upgrade process.

See https://docs.dnncommunity.org/content/getting-started/setup/upgrades/suggested-upgrade-path/index.html

I'll convert this issue into a discussion but let us know if you run into problems after following that path.