After deploying the project, custom widget views that reference or depend on the System.Numerics.Vectors assembly throw a controller error. The error does not occur when running the project locally in the development environment.

• The site works correctly when running locally in the development environment.
• The deployment completes successfully — no build or deployment errors are reported.
• The error is visible in the application error logs or event viewer on the deployed environment.
• The error affects custom widget views that directly or indirectly depend on the System.Numerics.Vectors assembly.
• The issue can occur on any hosting environment (Sitefinity Cloud, on-premises IIS, Azure App Service) when the build machine has a different .NET Framework SDK version than what the binding redirect expects.

In the default Sitefinity 14.4 project template, the System.Numerics.Vectors assembly is referenced in the .csproj as a bare .NET Framework reference without a version attribute or NuGet package HintPath:

<Reference Include="System.Numerics.Vectors" />

Because no version is specified, the build process resolves the assembly from the .NET Framework SDK installed on the build machine. When the build machine has a newer .NET Framework SDK than the local development machine (which is common with CI/CD hosted build agents, shared build servers, or updated development environments), the resolved assembly version can differ.

For example:

• Local development machine — Resolves to System.Numerics.Vectors 4.1.5.0 → matches the web.config binding redirect → site works
• Build machine — Resolves to System.Numerics.Vectors 4.1.6.0 → does not match the web.config binding redirect → FileLoadException after deployment

The deployment artifact contains the newer DLL in the bin folder, but the web.config binding redirect still instructs the runtime to load version 4.1.5.0. The .NET runtime detects a manifest mismatch and throws a FileLoadException. This surfaces as a controller error on any custom widget view that directly or indirectly invokes methods from the System.Numerics.Vectors assembly.

Option 1 — Update the binding redirect (immediate fix)

Verify the actual DLL version in the deployment artifact's bin folder and update the binding redirect in web.config to match.

From:

<dependentAssembly><assemblyIdentity name="System.Numerics.Vectors" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /><bindingRedirect oldVersion="0.0.0.0-4.1.5.0" newVersion="4.1.5.0" /></dependentAssembly>

To:

<dependentAssembly><assemblyIdentity name="System.Numerics.Vectors" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /><bindingRedirect oldVersion="0.0.0.0-4.1.6.0" newVersion="4.1.6.0" /></dependentAssembly>

Note: The exact version should match the DLL in the deployment artifact's bin folder. Right-click the DLL → Properties → Details to check the product/assembly version.

Option 2 — Pin the assembly version in .csproj (recommended)

To prevent this from recurring, pin the assembly to a specific NuGet package version. This mirrors the approach used in the Sitefinity 15.4 project template.

1. Install the NuGet package System.Numerics.Vectors version 4.6.1 in the project.

2. Replace the .csproj reference from:

   <Reference Include="System.Numerics.Vectors" />

   To:

   <Reference Include="System.Numerics.Vectors, Version=4.1.6.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"><HintPath>packages\System.Numerics.Vectors.4.6.1\lib\net462\System.Numerics.Vectors.dll</HintPath></Reference>

3. Update the binding redirect in web.config:

   <dependentAssembly><assemblyIdentity name="System.Numerics.Vectors" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /><bindingRedirect oldVersion="0.0.0.0-4.1.6.0" newVersion="4.1.6.0" /></dependentAssembly>

4. Rebuild and redeploy.

Option 3 — Upgrade Sitefinity

Upgrade to Sitefinity 15.x, where the .csproj template pins System.Numerics.Vectors to NuGet package 4.6.1 by default, eliminating this issue.

• This issue is not specific to any hosting environment. It can occur on Sitefinity Cloud, on-premises IIS, Azure App Service, or any deployment scenario where the build machine and the development machine have different .NET Framework SDK versions.
• The issue is not caused by a code change or a Sitefinity update. It is triggered by a .NET Framework SDK update on the build machine.
• This pattern may affect other bare framework references in the .csproj file. Review all <Reference Include="..." /> entries that lack a version attribute and HintPath, and consider pinning them to specific NuGet package versions.
• Microsoft periodically updates hosted build agent images (windows-latest), which can introduce newer SDK versions without notice.

Progress Article(s):

• Upgrade: Sitefinity Could not load file or assembly error — https://community.progress.com/s/article/Could-not-load-file-or-assembly-error-when-upgrading-Sitefinity

References to Other Documentation:

• Sitefinity: How to resolve assembly binding errors — https://community.progress.com/s/question/0D5Pb00002On9dBKAR/sitefinity-how-to-resolve-assembly-binding-errors
• Microsoft Docs, <bindingRedirect> Element — https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/bindingredirect-element