Table of Contents

DynamicWeb 10 moving to .NET 10

DynamicWeb 10 is being updated to support .NET 10, alongside continued support for .NET 8. This is a platform upgrade, not a functional rewrite. Most solutions will continue to work unchanged, while the upgrade improves long-term support, security, and alignment with Microsoft’s current and future platform investments.

DynamicWeb 10 NuGet packages are multi-targeted and available for both net8.0 and net10.0, allowing partners and customers to upgrade on their own timeline.

This article explains:

  • Why DynamicWeb is moving to .NET 10 and what customers and partners gain
  • What changes in DynamicWeb 10 due to the upgrade
  • How to upgrade custom projects
  • Cloud hosting, CI/CD, runtime selection, and support policy considerations

Benefits for customers and partners

Long-term support and lifecycle alignment

.NET 10 is the latest Long Term Support (LTS) release from Microsoft of .NET.

.NET 8 will deprecate in November of 2026 making this update required for DynamicWeb.

Read about Microsofts .NET support policies

Improved security baseline

.NET 10 enhances application security with a strong focus on post-quantum cryptography (PQC), improved authentication, and stricter, flexible encryption standards.

  • Removal of deprecated and insecure cryptographic algorithms
  • Clearer and more explicit cryptography APIs
  • Reduced reliance on legacy compatibility layers
  • Support for modern authentication protocols

This improves the security posture of DynamicWeb solutions without requiring application-level changes in most cases and allows for implementation of new authentication methods like Passkeys and OAuth DPoP.

Performance improvements

Each .NET release includes runtime, JIT, and memory-management improvements which affects performance. Individually these changes are incremental, but they accumulate over time and are particularly relevant for:

  • Cloud-hosted solutions
  • Container-based deployments
  • High-traffic commerce environments

Dynamicweb performs better on .NET 10 due to the general performance improvements in .NET 10 and since we can use new and faster features from .NET in our APIs.

Platform readiness and Microsoft investments

Microsoft’s investments in cloud services, tooling, and AI-assisted workloads are focused on the latest .NET versions. Moving to .NET 10 ensures DynamicWeb is not a limiting factor when customers want to adopt new platform capabilities.

This upgrade does not introduce AI features by itself, but it removes technical barriers to future adoption.

No forced upgrade path

DynamicWeb 10 supports both .NET 8 and .NET 10 for the next 6 months:

  • Existing solutions can remain on .NET 8
  • New solutions can start on .NET 10
  • Upgrades can be planned and executed deliberately

Changes in DynamicWeb 10 due to .NET 10

There are no significant changes to Dynamicweb 10 due to this upgrade - most solutions do not require any changes.

The changes listed below are driven by framework behavior, not by product redesign - and are handled inside the Dynamicweb APIs - only in rare situations will custom code need to be updated.

Cryptography changes

  • Rijndael is no longer supported in .NET 10
  • Custom code using Rijndael must be replaced, typically with AES
  • Some cryptography APIs have updated usage patterns but are API compatible

Only custom encryption logic is affected. Built-in DynamicWeb functionality does not rely on deprecated algorithms.

C# code in XSLT

Applies to:

  • XML Navigation using XSLT transforms with embedded C#
  • XML Integration Provider using XSLT transforms with embedded C#
  • Feeds using XSLT transform with embedded C#

Changes in compilation and runtime behavior may result in:

  • C# constructs that no longer compile
  • Stricter type handling
  • Updated namespaces and APIs

Solutions using XSLT with embedded C# should be tested carefully.

ZIP file handling

ZIP files are now processed using updated framework implementations. This can affect:

  • Validation of malformed or non-standard ZIP archives
  • Error handling when reading corrupted files

Custom code that reads ZIP files manually should be reviewed and updated if using native .NET APIs.

IPNetwork changes

  • IPNetwork has moved to System.Net

This typically requires only minor namespace updates in custom code if IPNetwork is being used in custom code.

Multi-targeting in DynamicWeb

DynamicWeb 10 packages are built using multi-targeting - our project does it like this:

<PropertyGroup>
  <TargetFrameworks Condition=" '$(OnlyNET10)' == 'true' ">net10.0</TargetFrameworks>
  <TargetFrameworks Condition=" '$(OnlyNET10)' != 'true' ">net10.0;net8.0</TargetFrameworks>
  <LangVersion>14.0</LangVersion>
</PropertyGroup>

The SDK version is controlled using global.json:

{
  "sdk": {
    "version": "10.0.0",
    "rollForward": "latestMinor",
    "allowPrerelease": false
  }
}

This means that we push all our Nuget packages in both .NET 8 and .NET 10 compiled versions to Nuget.

When using NuGet in Visual Studio, it automatically resolves the correct target framework for consuming projects.

How to upgrade custom projects

Custom projects typically consist of Visual Studio or VS Code projects with NuGet references to DynamicWeb 10 packages.

Step 1: Install the .NET 10 SDK

Install the official .NET 10 SDK from Microsoft. .NET 8 can remain installed in parallel.

Step 2: Update the target framework

Update your project file:

<TargetFramework>net10.0</TargetFramework>

Step 3: Update NuGet package references

After changing the target framework to net10.0, update all DynamicWeb and related NuGet packages to versions that support .NET 10.

This is done explicitly by:

  • Updating <TargetFramework> to net10.0 in the .csproj
  • Updating <PackageReference> versions to the latest compatible releases
  • Running dotnet restore (or restoring in Visual Studio) to resolve updated dependencies

NuGet will then resolve the correct assemblies for net10.0 based on the updated package versions.

Visual Studio alternative (GUI)

In Visual Studio:

  • Right-click Solution
  • Manage NuGet Packages
  • Go to Updates
  • Select all → Update

Using dotnet CLI

If you target release ring meta packages in your custom project they can be updated to latest .NET version using dotnet CLI.

E.g. when .NET 10 is released on Ring1, this command can be used to update to latest Ring1 based on .NET 10:

dotnet add package Dynamicweb.Suite.Ring1

Step 4: Build and resolve compile errors

In most scenarios all that is needed at this point is a rebuild using the .NET 10 SDK.

Changes to custom code due to this upgrade is rare - Dynamicweb APIs remain unchanged - so only very specific custom code targetting .NET APIs that have changes is required.

Typical adjustments include:

  • Replacing deprecated cryptography APIs
  • Updating namespaces such as IPNetwork
  • Fixing XSLT-embedded C# code

Step 5: Test runtime behavior

Recommended test order:

  • Compile and run unit tests
  • Execute integration tests
  • Verify staging environment
  • Deploy to production

Pay particular attention to:

  • Encryption and decryption logic
  • ZIP file processing
  • XSLT-based integrations
  • Custom infrastructure code

Step 6: Deploy and monitor

No special deployment steps are required beyond ensuring the correct .NET 10 runtime is available in the hosting environment.

Breaking change checklist

Before upgrading, verify the following:

  • No usage of Rijndael remains in custom code
  • XSLT files with embedded C# compile and execute correctly
  • ZIP import/export flows behave as expected
  • IP-related custom logic builds against System.Net
  • CI build agents use the intended .NET SDK version

Cloud hosting and release rings

DynamicWeb 10 Cloud uses release rings to roll out the .NET 10 support.

  • Existing cloud solutions continue to run on .NET 8 by default
  • .NET 10 is opt-in
  • Both .NET 8 and .NET 10 are supported in cloud for 5 release rings, corresponding to approximately 6 months

.NET 10 support starts in R0 and moves through R1, R2, R3, and R4 over time following the below schedule.

  • R0: End February
  • R1: End March
  • R2: End April
  • R3: End May
  • R4: End June

This means that if a solution is running on Ring 3, it can be updated to .NET 10 end of May.

How to opt in to .NET 10

For the initial rollout:

Once R1 is released, switching to .NET 10 follows the same process as changing release rings.

To change release cycle or application version:

  1. Create a file named changeversion.txt

  2. Place it in: files\System\CloudHosting\

  3. In the file, write the desired release cycle:

    • R1-NET10
    • R2-NET10
    • R3-NET10
    • R4-NET10

This change will be applied as part of the standard cloud deployment process.

This approach ensures:

  • No forced runtime upgrades
  • Predictable rollout and validation
  • Alignment with solution release planning

Upgrade strategy

Recommended approach:

  • Plan the upgrade during the spring
  • Move to .NET 10 as part of the next normal update of your custom solution
  • Switch runtime when your current release ring supports .NET 10

In practice, this means treating the runtime upgrade like any other platform update rather than a standalone project.

New projects can start directly on .NET 10 once available in the selected ring.

CI/CD considerations

Build agents

Ensure build agents have the .NET 10 SDK installed.

SDK pinning

Use global.json to pin the SDK version and avoid accidental upgrades on build servers. This ensures the same SDK is used locally, in CI, and during releases.

Third-party libraries

Most actively maintained NuGet packages already support .NET 10 or will work without changes. Libraries targeting net8.0 or netstandard2.1 are generally forward-compatible and can typically run on .NET 10 without modification.

Compatibility issues are more likely with:

  • Legacy or unmaintained libraries targeting older frameworks
  • Packages relying on deprecated APIs or removed runtime behavior
  • Components tightly coupled to framework internals or native dependencies

In most cases, problems appear at compile time (missing APIs) or during runtime if a library depends on behavior that has been hardened or removed in newer .NET versions.

Docker-based pipelines

  • Update base images to include .NET 10
  • Consider separate images during the transition period if both runtimes are supported

Support policy

DynamicWeb follows its existing support policies:

  • .NET 8 support ends at the end of June 2026
  • Both .NET 8 and .NET 10 are supported during the transition period
  • After .NET 8 end-of-support, DynamicWeb solutions must run on .NET 10 or newer

This provides a long overlap window and a clear upgrade deadline.

Improve this doc
To top