Migrate Server-Side Code from .NET 4.8 to .NET 8+

By now, it is known that the final release of the complete Framework series is .NET Framework 4.8. This means that Microsoft will cease to create new features, improvements, or updates for it.

It is no wonder that Microsoft is putting a huge percentage, if not all, of its efforts into .NET 6 and later, with .NET 8 being the current long-term support (LTS) release. The .NET 8 framework offers an enormous feature set, improved performance, and more flexibility than the .NET Framework.

NCache offers servers for .NET Framework (4.8) and .NET 6+ and recommends its users to upgrade to the latest versions of .NET. If you are using any of the server-side features of NCache on a .NET Framework server, then this blog is for you. Otherwise, the migration is seamless, as you just have to install an NCache .NET Core server and start using it.

Key Takeaways

Modernization Goal: Migrating NCache server-side features (like Read-Through/Write-Through) from .NET Framework 4.8 to .NET 8 to enable cross-platform support (Linux/Docker).
Infrastructure Shift: Transitioning legacy project files to the modern SDK-style .csproj format to support .NET Standard 2.0 or .NET 8.0 targets.
Dependency Check: Success depends on ensuring all external DLLs have .NET Standard or .NET 8 equivalents; otherwise, the provider will not run on a .NET Core server.
Performance Gain: Moving to .NET 8 provides superior throughput and memory management through architectural improvements like Tiered Compilation and Span<T>.

Why Migrate from a .NET Framework Server to a .NET Core Server?

Microsoft considers .NET 8, and its later versions, as the foundation of modern application development. The company is thus prioritizing its resource allocation towards .NET 8, considering that the .NET Framework is gradually being phased out. Instead of waiting until it is completely outdated, it is best to start migrating now.

Feature	.NET Framework 4.8	.NET 8 (LTS)
OS Support	Windows Only	Cross-platform (Windows, Linux, macOS)
Runtime Architecture	Monolithic / System-wide	Modular / Side-by-side (App-local runtimes)
Deployment	IIS / Virtual Machines	Cloud-native (Docker, Kubernetes, Microservices)
Performance	Legacy JIT & GC	High-throughput (via PGO, Span<T>, and Hardware Intrinsics)
Memory Mgmt.	Standard Garbage Collection	Reduced Footprint (Optimized GC and Pinning)
CLI Tools	Visual Studio / MSBuild	Unified .NET CLI (dotnet build/run/publish)
Future Support	Maintenance Mode (Security only)	Active Development (New features & LTS)

Besides, .NET Core brings so much to the table that .NET Framework doesn’t. The following list of features benefit .NET Core over .NET Framework:

Cross-platform support: .NET Core code can run on Windows, Linux, and macOS. This means that your NCache .NET Core servers are platform (OS) independent. The .NET CLI can also be used across all supported platforms.
Improved performance: .NET 8 delivers significantly better performance, making applications faster and more efficient.
Long-term support (LTS): .NET 8 provides long-term stability and security updates.
Containerization support: .NET 8 integrates better with modern deployment strategies like Docker and Kubernetes.
Better memory management: .NET 8 includes enhancements such as improved garbage collection and reduced memory footprint.

How to Deploy Your .NET Framework Code on a .NET Core Server

The best option for migrating your existing .NET Framework code base to a .NET 8 server involves first migrating it into .NET Standard 2.0 or migrate it directly into .NET 8. So, NCache now encourages users to develop applications using .NET 8 and especially for development of new application.

You can adopt one of the following approaches to convert your .NET Framework code into .NET Core code:

Start from scratch.
If your project uses the new .csproj format, update the TargetFramework tag to net8.0.
If your project uses the old .csproj format, migrate it to the new format.

Since the first and the second approaches are straightforward, let’s focus on the third approach with detailed steps.

Note: This conversion will not work if your .NET Framework provider depends on a DLL that explicitly requires .NET Framework and does not have a .NET Standard or .NET 8 equivalent.

Step 1: Unloading the Project

The first step is to unload your project from Visual Studio:

1. Open Solution Explorer in Visual Studio.
2. Right-click on your project and select Unload Project.

Step 2: Replacing the Content of the Project File

Open the .csproj file in a code editor of your choice and replace its content with the following:

<?xml version="1.0" encoding="utf-8"?>

<TargetFramework>netstandard2.0</TargetFramework>

</PropertyGroup>

</Project>

Step 3: Adding Dependencies

In this step, add your dependencies:

To add direct references to external libraries, modify the .csproj file with:

<HintPath>path\NCache.ReadThru.Provider.dll</HintPath>

</Reference>

</ItemGroup>

To add NuGet package dependencies, include:

</ItemGroup>

Step 4: Reloading Your Project

Once changes are made, reload your project in Visual Studio:

Go to Solution Explorer.
Right-click on the unloaded project.
Select Reload Project.

Step 5: Removing duplication from AssemblyInfo.cs

Your project won’t run properly unless you remove duplicate entries in the AssemblyInfo.cs file, located under Properties. This is because the new SDK-style project format automatically generates assembly attributes that previously had to be defined manually. Open this file and remove redundant information, ensuring it looks like this:

[assembly: AssemblyTitle("NCache.ReadThru.Provider")]

[assembly: AssemblyVersion("1.0.0.0")]

[assembly: AssemblyFileVersion("1.0.0.0")]

Step 6: Building and Deploying Your Provider

After completing the steps above, build your project and deploy the compiled provider on a .NET 8 NCache Server.

Benefits of This Migration

While migrating from .NET Framework to .NET 8 may require effort, it brings several advantages:

Guaranteed future support and updates by Microsoft.
Ability to run on Windows, Linux, and containers.
Access to modern .NET features, including improved performance and cloud-native capabilities.

Conclusion

NCache is an efficient and scalable distributed cache solution for the specific .NET, Java, and Node.js frameworks. The blog does not suggest that NCache will stop supporting.NET Framework servers. Nonetheless, it strongly advocates for a shift to .NET 8 in order to realize long-term advantages and hence be compatible with future updates and improvements in Microsoft’s technology.

Frequently Asked Questions (FAQ)

Q: Can I run a .NET Framework 4.8 provider on an NCache .NET 8 Server?
A: No. All server-side code (Read-Through, Write-Through, Cache Loader) must be migrated to .NET Standard 2.0 or .NET 8 to execute on a .NET 8 NCache server. If your provider remains on .NET Framework, it can only run on a .NET Framework-based NCache server.

Q: What happens if one of my third-party DLLs does not support .NET Standard?
A: This is a critical blocker. If a provider dependency is strictly tied to the .NET Framework (e.g., an old legacy library without a .NET Core version), that specific provider cannot be migrated to the .NET 8 server. You would need to find an alternative library or keep that specific cache cluster on a .NET Framework server.

Q: Why is it necessary to unload the project in Visual Studio?
A: Manually editing the .csproj file to switch to the SDK-style format is cleaner and less error-prone than using the Visual Studio UI. Unloading the project ensures that Visual Studio doesn’t overwrite your manual XML changes before they are properly saved.

Q: Will migrating my server-side code require changes to my client applications?
A: Not necessarily. NCache allows .NET Framework clients to connect to .NET 8 servers (and vice-versa). However, for the best performance and compatibility, it is recommended that your client-side objects match the serialization format used by your migrated server-side providers.