News

Migrating WinForms & WPF from .NET Framework to .NET 10

Paul Usher (DevExpress) — Sun, 12 Jul 2026 22:05:00 Z

What This Guide Covers

I've hand-migrated more legacy codebases than I care to count, back when "modernisation" meant a fortnight of find-and-replace, a wall of compiler errors, and a knot in your stomach every time you hit Build. So when I recently took a fifteen-year-old WinForms line-of-business app from .NET Framework 4.8 to .NET 10 in a matter of days, with an AI agent doing the grunt work and me keeping my hands on the decisions, I paid attention to what actually worked. This guide is that method, written up as steps you can follow.

It assumes a real codebase: a non-SDK project, packages.config, a commercial control suite referenced the old way, and a decade of dependencies that were sensible in 2012 and a bit embarrassing now. If you've worked on real enterprise software, you've met this codebase. Odds are you maintain one. The app I'll keep referring to is WinForms, so the specifics lean that way, but the process is the same for WPF and I'll flag where the two part company.

The migration is rarely hard. It's vast and fiddly: thousands of small mechanical changes where one wrong move turns a working app into a non-compiling mystery you'll spend a day unpicking. It's tedious and easy to get wrong, which is exactly the kind of work worth automating, as long as you keep checking what it produces. Follow the steps below in order, commit after each one, and a job that's sat in the "someday" pile for years turns into this week's work.

Before you start: you need Visual Studio 2026 (or Visual Studio 2022 17.14.17+), your source in Git so every step is reversible, access to your DevExpress and NuGet feeds, and a paid GitHub Copilot plan if you want to run the modernization agent. With DevExpress v26.2 setting .NET 10 as the minimum supported target, this is the version to aim at.

Step 0: Pick the Right Target (LTS vs STS)

Decide the target framework before you touch anything, because it's one line in a project file that decides whether you do this again next year. Microsoft alternates its releases. The even-numbered ones (8, 10, 12) are Long-Term Support with a three-year window; the odd numbers in between are Standard-Term Support and shorter-lived (24 months now).

The first useful thing the AI did on my migration wasn't code. My obvious target was .NET 8. It pointed out that 8's support window was nearly up (November 2026), while .NET 10 was the current LTS with years of runway ahead of it. That's one line in a project file standing between "done" and "doing this again next year," and most juniors wouldn't have raised it. For an app that has to sit stable for years, you want the LTS. Right now that's .NET 10, which also happens to be the minimum DevExpress sets in v26.2.

Since .NET 10, .NET Framework 4.7.2, and Visual Studio 2022 will be minimally supported versions for DevExpress libraries in v26.2, we are also planning to update the DevExpress Project Converter accordingly: it will re-target DevExpress-based projects to .NET 10 and .NET Framework 4.7.2 and update 3rd party NuGet packages to the latest compatible versions (optionally and very similar to what we did for .NET 6 to 8 migration in 2024).

Step 1: Run an Assessment

Before changing code, get an honest picture of what stands between you and .NET 10. This is the job of GitHub Copilot app modernization for .NET, the Copilot agent that took over from the old Microsoft .NET Upgrade Assistant. In Visual Studio, right-click the solution in Solution Explorer and choose Modernize, or open Copilot Chat and invoke the agent:

@Modernize upgrade this solution to .NET 10

In VS Code or the Copilot CLI the agent is @modernize-dotnet. However you start it, the first thing it produces is an assessment.md in your repo: outdated NuGet packages, APIs with no modern equivalent, and the likely blockers. Read it before you agree to anything. That's the difference between planning a migration and discovering one.

Two caveats. Running the agent needs a paid GitHub Copilot plan, and if the Modernize option isn't there you'll need the GitHub Copilot app modernization component from the Visual Studio installer, so factor both in. And treat the assessment as a briefing, not a verdict: it's very good at finding the mechanical work, but the judgement calls are still yours.

Step 2: Review and Edit the Plan

Once the assessment's done, the agent writes a plan.md that sequences the upgrade into steps. The thing that matters about this file is that it's yours to edit. Reorder it, pull out steps you'd rather do by hand, and split anything that looks too big into smaller moves.

This is where you impose the one rule that keeps migrations safe, and I've learned it the hard way: never do it as a big bang. Work in small, reversible, committed steps, so a bad change is a git revert away rather than an afternoon of unpicking. A sensible plan for a DevExpress desktop app usually runs in this order:

Convert the project to SDK-style, targeting net10.0-windows.
Move dependencies from packages.config to PackageReference.
Prove the restore works against your feeds before attempting a build.
Fix what modern .NET rejects, then clear the build, then clear the warnings.

Approve the plan only when it reads like something you'd have written yourself. Then let the agent start executing, one step at a time.

Step 3: SDK-Style, PackageReference and CPM

The first executed step converts the old project format and moves your references. A couple of things are worth watching, because they catch you out.

If your .NET Framework project relied on assembly references, DevExpress assembly names do not match the DevExpress NuGet package names (for example, for the DevExpress.XtraGrid assembly there is a DevExpress.Win.Grid NuGet package). If you do not want to trust AI for this important conversion, we recommend that you use our Project Converter and its deterministic Convert DevExpress assembly references to NuGet packages option before you trigger actual project conversion.

If the project sits at the repository root, default file-globbing in an SDK-style project can hoover up source from other projects nearby. This is one the AI caught that I'd have walked straight into: my project sat at the repo root, so the default globbing would've pulled in source from the projects around it. It turned globbing off and carried the explicit file lists across. Keep an eye out for it, because it's easy to miss and a pain to debug.

If your solution has more than one project, this is the moment to adopt Central Package Management (CPM), so every project shares one set of versions. Drop a Directory.Packages.props at the repository root:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="DevExpress.Win" Version="26.2.*" />
  </ItemGroup>
</Project>

That example pins the WinForms meta-package; for a WPF app you'd use DevExpress.Wpf instead. Individual projects then reference the package without a version, and your DevExpress and framework versions stop drifting apart across the solution. Prove dotnet restore succeeds against your component feed before you try to compile. Get restore green first and you skip a whole category of confusing build errors.

For more information on how your projects can benefit from CPM, please also review a related article Application Security — Project Dependency "Version Bumps" Demystified or Modern Security Realities in .NET / NuGet Ecosystem.

Step 4: Fix What Modern .NET Rejects

Now the code itself. On my migration the first compile threw 36 errors and roughly 1,795 warnings. That sounds alarming, and mostly it isn't: the errors collapsed to a handful of root causes, and the warnings came down to one. Clear them in that order, errors first and then warnings, committing as you go. These are the ones you're most likely to meet on a DevExpress desktop app.

Retire APIs with no modern equivalent

Swap out the usual suspects: an old zip library for System.IO.Compression, LINQ-to-SQL screens for a supported data path, dead app.config sections for their modern equivalents. The assessment will have flagged most of them.

Watch for namespace clashes

A properly sneaky one on my app: a bare Windows.Forms… reference stopped resolving on the new framework, thanks to a namespace collision that didn't exist on Framework. Fully qualify it and the error vanishes. One line, but a baffling one until you spot it.

The screens look wrong: fix DPI awareness

The app compiled and launched, but the forms came up subtly wrong: controls a touch out of place, spacing not quite right. That's the DPI-awareness default changing between frameworks, and it's the sort of thing you can stare at for a while before the penny drops. The AI worked it out from a screenshot and a description, pointed me at the DevExpress high-DPI docs to back it up, and one setting put the screens back exactly as they were. That trap is a WinForms one; WPF scales differently and won't hit it, though it has its own breaking changes to watch for, the removal of BinaryFormatter being the one that bites most often (learn more).

Collapse the warning storm

The warning count after a big migration can look terrifying and usually is anything but. Two moves cleared most of mine: declaring the assembly's supported-platform attribute to keep the compatibility analyser happy, and pinning a data-access package to the last version before it was marked obsolete. That second change alone dropped 500-plus warnings without touching a line of generated code.

Step 5: Lean on Compatibility Shims

You don't have to migrate everything before you can run. I'd assumed I would need to move my two in-house .NET Framework libraries first. I didn't. The modernised app compiled and ran on .NET 10 while still referencing those libraries through the .NET Framework compatibility shim. One thing to be clear about: that only holds while those libraries stick to APIs modern .NET still provides. You'll get a build warning, and any code path that calls an API .NET 10 has dropped will fail at runtime rather than at compile time, so exercise the paths that go through them before you call it done. Even so, if you've got in-house libraries pinned to Framework, leave them where they are for now. Get the main application onto .NET 10 first, confirm it runs, and book the deeper library work as a separate job that blocks nothing.

This is the single biggest reason these migrations stall for no good reason. Teams assume every dependency has to move first, and give up. It doesn't, and they don't. You don't have to boil the ocean. Get a working, current-LTS application in place, then chip away at the rest without holding the whole project hostage.

Where AI Fits, and Where You Stay in Charge

The reason this workflow holds up is that the agent proposes and you dispose. The assessment.md and plan.md aren't decoration; they're your checkpoints. You read the assessment, you edit the plan, you approve each step, and every change lands as a described commit you can review or revert. The AI carries the vast, repetitive sweep across dozens of files with no fatigue and no typos. The judgement and the checking stay with you. I never once typed "trust me," and that's the whole point.

Assess, plan, execute. The agent does the work; you sign off each stage.

Keep the Component Code Current: AI Skills and the MCP Server

The modernization agent is built to move your framework, not to know your component vendor's latest API surface. That gap does the most damage during a migration, because a migration is when you touch the most component code in the shortest time. Ask a general-purpose model to update a DevExpress grid or report and it'll often reach for an older namespace it saw more of in training. The code looks right, compiles, and sits there on a superseded API. Two DevExpress tools close that gap, and they're worth adding to the same IDE for the fix-up work.

DevExpress AI Skills hand the assistant current DevExpress namespaces, entry points and configuration patterns before it writes a line. They install into the coding assistant you already use (GitHub Copilot, Claude Code, Cursor or JetBrains), they work even without a live documentation connection, and they keep the component code on supported APIs rather than remembered ones. On a migration that pays off directly: fewer convincing-but-stale suggestions to catch in review, and a first answer you can build on instead of unpick. Call the relevant skill explicitly at the start of a task rather than trusting auto-detection, with # in Copilot or / in Cursor and Claude Code.

The DevExpress MCP Server adds the other half: live access to current documentation and version-sensitive detail when a task gets specific. Where a Skill sets the right starting point, the MCP Server supplies the authoritative reference to finish the job, so the assistant spends its lookups on real implementation questions instead of working out which API it should've used in the first place. Adding it is a one-line job in most assistants; in Claude Code, for example:

claude mcp add --transport http dxdocs https://api.devexpress.com/mcp/docs

Put them together and the split is clean: the modernization agent carries the framework move, the Skills keep your DevExpress code correct, and the MCP Server fills in the detail on demand. It's the same partnership principle as the rest of this guide, pointed at your component layer. I went deeper on why this matters, and how the two work together, with worked before-and-after examples in an earlier post: Beyond Prompts: Teaching AI How to Build with DevExpress. If you haven't read it, that's the companion piece to this guide.

Step 6: Verify You Are Actually Done

"It compiles" isn't the finish line. Before you call it migrated, confirm the app launches and the main workflows behave, the screens render correctly at your users' DPI settings, the warning count is down to something you actually understand, and each step is a clean commit in history. Only then start building new features on the modern foundation, which you can now do this week rather than someday.

The Takeaway

The blocker on most legacy migrations isn't capability. It's the sheer volume of small changes, and the fear of breaking an app that's quietly worked for years. This workflow deals with both. The modernization agent carries the tedium and surfaces the landmines as an assessment you approve, DevExpress AI Skills keep the component code on current APIs, compatibility shims stop a single old dependency holding everything hostage, and small reversible commits keep the risk low at every step.

With DevExpress v26.2 aiming to make .NET 10 the minimum, now is the time to plan this migration, not a reason to panic. The app I did this on was fifteen years old and threw 36 errors and getting on for 1,800 warnings on its first .NET 10 compile. It was running clean within days, and I was building new features on it the same week. The migration is the part everyone dreads. Worked in small steps, with the tooling doing the legwork and you making the calls, it turns out to be the manageable bit.

Beyond Prompts: Teaching AI How to Build with DevExpress

Paul Usher (DevExpress) — Thu, 09 Jul 2026 03:23:00 Z

AI Needs More Than Good Prompts

If you've paired Claude Code, GitHub Copilot or Cursor with DevExpress, you already know the moment I'm about to describe. It's the same one the team kept running into while building the DevExpress Office & PDF File API and DevExpress Reports Skills, and their evaluation notes are what this post is really about. The assistant starts strong. Clean C#, sensible class names, code that looks like it belongs in your solution. Then you read it a second time and something's off: the namespace is from a release two versions back, the API has been superseded, or the whole thing has quietly wandered off to a third-party library because that's what the model saw most often in training.

The interesting part wasn't that the AI got things wrong. Everyone expects that. What struck me about the team's findings was how convincing the wrong answers were. The ones that failed to compile cost them nothing; those get spotted immediately. The expensive ones looked completely reasonable right up until someone compared them with the current documentation. More often than not, they were yesterday's best practice dressed up as today's.

That single observation ended up shaping how the team designed the Skills.

As they worked through the results, the same theme kept coming back. When the generated code missed, the problem was almost never C#, and it certainly wasn't the model's ability to reason. It was product knowledge. The model didn't have the current namespaces, the right entry points or the small amount of framework-specific context it needed before it started typing. Hand it those things and the quality of the output jumped straight away.

We spend a lot of energy on prompt engineering, and good prompts genuinely help. But a prompt can only work with what the model already knows. No amount of clever wording fills a gap in product knowledge that isn't there to begin with. Every time, giving the assistant accurate context before it wrote anything beat trying to talk it back from a bad first answer.

That's the whole idea behind DevExpress AI Skills. They don't replace the model's reasoning, and they don't try to re-host the documentation. They hand the assistant a concise, product-specific starting point before it writes the first line of code, so it can spend its effort solving your actual problem instead of reconstructing an unfamiliar API from scraps of training data.

The easiest way to show you what I mean is to walk through the same prompts the team used during the review, with and without the Skill.

When Good Code Is Still Wrong

This showed up early in the team's evaluation. Completely made-up APIs were never the issue, because you catch those instantly. The answers that slowed them down were the believable ones: code that read like it came from someone who knew the framework reasonably well, but carried just enough stale or incorrect detail to send you chasing the wrong problem for half an hour.

That's the trap with specialised frameworks. They move constantly. Namespaces get reorganised, newer APIs replace older programming models, and products grow in directions that simply aren't in the model's training data yet. The assistant has no way of knowing a better approach exists unless something tells it, so it does the reasonable thing and fills the gap with the closest match it can find. Most of the time that match looks plausible enough to trust.

Across the Office & PDF File API and DevExpress Reports review, the team watched this happen again and again. Same prompt, same model, same task. The only thing they changed was what the assistant knew before it started. And the moment it started from accurate DevExpress guidance rather than memory, the code changed.

Here are three examples straight from that work.

Example 1: Generating a QR Code

Start with something ordinary.

Prompt

Generate a QR Code containing https://community.devexpress.com and save it as a PNG using DevExpress.

Without the Barcode Skill, the assistant reached for an older DevExpress API. The important thing to note, the Barcode functionality was NOT removed, simply improved and updated.

using DevExpress.BarCodes;

BarCode barCode = new BarCode();
barCode.Symbology = Symbology.QRCode;
barCode.CodeText = url;
barCode.Save("qr.png");

There's almost nothing to object to here. It reads cleanly, it follows normal C# conventions, and if you didn't already know the current Barcode API you'd have every reason to assume it was fine. That's exactly what makes this kind of error awkward. It doesn't look absurd. It looks sensible.

The trouble is the historical DevExpress.BarCodes namespace and an object model that no longer reflects the current API. The model hasn't invented nonsense; it has rebuilt a solution out of older fragments that showed up often enough in training to feel right.

With the Barcode Skill loaded, the same prompt lands on the current API.

using System.IO;
using DevExpress.Docs.Barcode;
using DevExpress.Drawing;

var qrOptions = new QRCodeOptions {
    ModuleSize = 4f,
    Dpi = 96
};

using var generator = new BarcodeGenerator(qrOptions);
using var output = new FileStream("qr.png", FileMode.Create, FileAccess.Write);
generator.Export("https://community.devexpress.com", output, DXImageFormat.Png);

Nothing changed except what the assistant knew going in. That matters more than it first appears, because the first answer becomes the foundation for everything after it. Start the conversation on an obsolete namespace and every follow-up (styling the barcode, switching the output format, dropping the image into another document) tends to stay on that same dead branch.

I'll be honest: these errors worry me more than a broken build ever has. A bad method name announces itself. Convincing code built on an old API doesn't, and it's easiest to trust precisely when you're moving fast and not looking closely. The Skill heads that off by putting the assistant on the right API before the conversation picks up speed.

Example 2: Exporting Large Excel Files

This one's trickier, because the "wrong" code isn't wrong in the usual sense. It compiles. It produces a perfectly valid workbook. The problem is that the assistant picked the wrong DevExpress product for the job.

Prompt

Export 100,000 rows to an Excel workbook efficiently using DevExpress.

Without the Excel Export Library Skill, most assistants reach for the Spreadsheet API.

using var workbook = new Workbook();

Worksheet sheet = workbook.Worksheets[0];

for (int i = 0; i < 100_000; i++)
{
    sheet.Cells[i, 0].Value = data[i];
}

workbook.SaveDocument("output.xlsx", DocumentFormat.Xlsx);

Functionally, this is a fair answer. It builds a workbook and writes data into it, and for most day-to-day work the DevExpress Spreadsheet API is exactly what you want: it gives you a rich in-memory object model for creating, editing, formatting, calculating and analysing content.

But look at the prompt again. It says efficiently.

Building an Excel document and streaming out a large dataset are related jobs, not the same job. The Spreadsheet API holds the whole workbook in memory so everything stays editable for the life of the document. That's a strength when you're editing. At 100,000 rows it's mostly overhead, because once a row is written you're never going back to touch it, the formulas usually don't need recalculating mid-generation, and what you actually care about is memory that stays flat as the row count climbs. That's the exact problem the DevExpress Excel Export Library was built for.

With the Excel Export Skill in play, the assistant switches to the streaming API.

using DevExpress.Export.Xl;

IXlExporter exporter = XlExport.CreateExporter(XlDocumentFormat.Xlsx);

using var document = exporter.CreateDocument(stream);
using var sheet = document.CreateSheet();

foreach (var customer in customers)
{
    using var row = sheet.CreateRow();
    using var cell = row.CreateCell();
    cell.Value = customer.Name;
}

These two libraries aren't rivals. They solve different problems. One hands you a full workbook object model for manipulation; the other writes rows straight to the stream and keeps memory predictable no matter how big the export gets. On its own, the assistant has no real basis for preferring one over the other, because both technically satisfy the loose wording of the prompt.

That's the gap the Skill fills. It isn't fixing syntax; it's supplying the engineering judgement to match the API to the workload.

Example 3: Report Viewer Setup and Customization

DevExpress Reports is a great stress test for AI-assisted development, because so much of it hinges on small platform-specific details. The code can look structurally perfect and still be missing the one registration call, callback or client-side API that makes the viewer actually work.

One evaluation prompt asked for the native DevExpress Report Viewer in a Blazor Server app. Without the DevExpress Blazor Reports Skill, the assistant registered services for the JavaScript-based viewer family instead of the native Blazor one.

builder.Services.AddDevExpressBlazorReporting();

Easy mistake to make. The method name sounds right, it slots neatly into the ASP.NET Core service registration pipeline, and nothing about it raises a flag. But native Blazor Reporting needs a different call.

builder.Services.AddDevExpressServerSideBlazorReportViewer();

This is the kind of thing that costs a disproportionate amount of pain. The app compiles, the page loads, and you're left staring at a blank viewer wondering what you did wrong. Nothing failed at the C# level. It failed at knowing which DevExpress Reports viewer family the prompt was even talking about.

The same story plays out when you customise the viewer. Say you want to hide the Print button and limit exports to PDF. With no product guidance, assistants tend to invent APIs that feel plausible but don't exist.

previewModel.GetToolbarItemCommands().forEach(command => {
    if (command.id === "print") {
        command.visible = false;
    }
});

previewModel.GetExportFormatItems().forEach(item => {
    if (item.format !== "pdf") {
        item.visible = false;
    }
});

It reads like it belongs in a reporting viewer: sensible names, a clean split between toolbar and export customisation, the shape of a real client-side API. But the actual DevExpress callbacks use different entry points.

function customizeMenuActions(s, e) {
    var printAction = e.GetById(DevExpress.Reporting.Viewer.ActionId.PrintPage);
    if (printAction) {
        printAction.visible = false;
    }
}

function customizeExportOptions(s, e) {
    e.HideFormat(DevExpress.Reporting.Viewer.ExportFormatID.XLS);
    e.HideFormat(DevExpress.Reporting.Viewer.ExportFormatID.XLSX);
}

This is why specialised frameworks are hard for general-purpose assistants. The answer has the right shape and the wrong product knowledge, and in reporting, where so much of the setup is declarative or callback-driven, one wrong method name is the difference between a working viewer and a dead end.

When the Best Answer Is Another Question

Not every win comes from better code. Some of my favourite Skill behaviour shows up when the assistant decides not to write code yet.

AI assistants are heavily biased towards answering the prompt in front of them. When a requirement is underspecified, they'll usually make an assumption and press on. That keeps things moving, but it also produces software that satisfies the words of the prompt rather than what you actually meant.

Picture asking for "a chart using DevExpress." From a developer's point of view that request is wide open. Bar, line, pie, scatter? What's the data source? Who's the audience? Any experienced developer would ask a question or two before writing a line.

Most assistants won't. They'll pick whatever chart type seems most likely and start generating.

Several DevExpress Skills nudge the assistant the other way: when something essential is missing, ask first.

Developer

Create a chart using DevExpress.

AI with the Skill

Which chart type would you like to create? For example, Bar, Line, Pie, Area or Scatter?

That small shift makes the whole thing feel less like poking a code generator and more like working with a colleague. And it saves you the classic time-sink of unwinding an implementation built on an assumption nobody ever made.

You could bake this into your own prompts, of course, but then you're on the hook to remember it, repeat it across every assistant you use, and keep it in step with how your team works. Putting it in a Skill makes it part of the workflow instead of one more line you have to paste into every request.

Skills and the DevExpress MCP Server

One question comes up almost every time I talk about this:

If the DevExpress MCP Server already gives AI agents access to the documentation, why do we need Skills too?

Because they're solving different problems.

A Skill is the focused guidance the assistant gets before it starts: enough to recognise the right product area, follow the common implementation patterns, and sidestep the mistakes that come from leaning on training data alone. Skills are deliberately small, so they load fast and cover a lot of everyday work without sending the assistant off on several rounds of exploration.

The MCP Server plays a different role. It gives compatible agents live access to the current documentation, API details and examples. That's the shipping product, not whatever the model happened to memorise.

A Skill points the assistant to the right product area up front; the MCP Server supplies authoritative detail once the task gets specific.

In practice they hand off to each other. The Skill gets the assistant to the right place; when the task needs more depth, the MCP Server supplies the authoritative reference to carry it through. Together they cut the guesswork at both ends: the Skill keeps the assistant out of the wrong product area, and the MCP Server fills in the specifics once the work gets detailed.

That pairing also trims a lot of back-and-forth. Without a Skill, an agent can burn several tool calls just working out which API it should be using. With the right Skill loaded, those MCP calls go towards real implementation questions instead of correcting the assistant's starting assumptions.

There's a discoverability angle here too. In a recent customer survey, roughly a third of respondents didn't know the DevExpress MCP Server existed. Skills give us a natural way to reintroduce it as part of a broader AI-assisted workflow, rather than leaving it as a separate tool people may never stumble across.

Why Smaller Models Benefit Even More

The big frontier models are impressive even when their product knowledge is patchy. Claude Opus, Claude Sonnet and the latest GPT-class models can often reason their way to something that works, especially with documentation access or a patient developer steering. They still slip up, but they tend to recover.

Smaller and older models have a harder time. Compact models like Claude Haiku and Gemini Flash (and the local models more teams are running now) are built to be fast, responsive and cheap. They're a great fit for plenty of coding work, but they carry less specialised product knowledge out of training.

This is where Skills earn their keep. Rather than asking a compact model to reverse-engineer an unfamiliar API from a handful of examples, the Skill hands it the essentials up front: current namespaces, recommended entry points, the usual patterns and the traps worth avoiding, all dropped straight into its working context.

And it matters beyond the hosted services. More teams are looking at local models for privacy, compliance or cost reasons. Those models will keep improving, but they're never going to hold detailed knowledge of every commercial framework or every recently shipped API. Skills close that gap by supplying the DevExpress-specific context regardless of whether the model runs in the cloud or on the developer's own machine.

The aim isn't to make a small model behave like a large one. It's to let you choose the model that suits your workflow without giving up confidence that it understands the DevExpress APIs you're working with.

Skills Versus Custom Instructions

Most AI assistants already give you a way to shape their behaviour. Copilot has custom instructions, Cursor has rule files, Claude Code has project instructions, and just about every other agent has its own flavour. Useful, all of them, but also fragmenting: each one wants its guidance in a different format.

Work across a few tools and you end up maintaining the same advice in several places at once. Coding conventions, preferred APIs, project-specific practices, all copied between config files and quietly drifting out of sync.

Skills take a more portable route. They load when they're relevant and stay out of the way when they're not: a DevExpress Reports Skill turns up for reporting work, a Barcode Skill for barcode generation, spreadsheet guidance when you're in Excel territory. The assistant gets what it needs without dragging a giant instruction file into every unrelated conversation.

That on-demand behaviour is the point. Loading everything into every request eats context and pulls the assistant's attention off the task at hand. Progressive disclosure keeps the working context tight, which really shows when you've got several DevExpress products installed, or a project that mixes reporting, document processing and web UI.

Portability is just as valuable. Because Skills aren't tied to one assistant, the same guidance travels across every supported agent. And as plugin-based distribution matures, Skills give updates a path to evolve alongside DevExpress products, instead of leaving each developer to hand-maintain their own instruction files.

The takeaway is simple: you shouldn't have to teach every AI assistant how to use DevExpress from scratch. Install the relevant Skills, pair them with the MCP Server when you need more depth, and let the tooling carry consistent guidance wherever the work happens.

Looking Beyond the Prompt

A year ago, most of the conversation around AI-assisted development was about prompt engineering, with whole posts hunting for the magic phrasing that would unlock better code. Prompts matter, no argument. But they're only part of the story. An assistant can only work with what it knows, and no amount of elegant wording makes up for knowledge that isn't there.

That's the lesson that runs through the team's work on the Office File & PDF API and DevExpress Reports Skills. When the assistant only half-knew DevExpress, it papered over the gaps with educated guesses. When it started from accurate context, the output was more reliable, more current, and a lot closer to what an experienced DevExpress developer would actually write.

The MCP Server rounds out the picture, handing compatible agents the current documentation, examples and API details whenever the task needs more depth. Skills get the assistant to the right starting point; the MCP Server keeps it honest from there.

Assistants will keep getting better. New models, stronger reasoning, today's rough edges smoothing out. What won't change is the value of context. General-purpose models will always do better when they understand the frameworks they're building on, especially frameworks that move faster than any training run can keep up with.

That's the thinking behind both DevExpress AI Skills and the DevExpress Documentation MCP Server. Between them, the assistant gets immediate guidance and access to current product knowledge. The payoff isn't just cleaner code. It's a development experience that feels less like correcting a stranger and more like working alongside someone who already knows the framework you're using.

DevExpress Developer Survey — AI Impact, Regulatory Compliance, Upgrade & General Product Experience

Dennis Garavsky (DevExpress) — Tue, 02 Jun 2026 07:08:00 Z

As always, we thank you for your continued support and for choosing DevExpress for your software development needs.

Below is an important usage survey and we ask that you take a few minutes to submit your feedback to us. Your thoughts/comments will help us shape our future R&D efforts so they better align with your development objectives. The survey should take about 10 minutes to complete.

The focus of this survey is as follows:

AI-assisted development and its impact on your enterprise
Regulatory compliance requirements in an ever-changing regulatory landscape
Satisfaction with DevExpress product delivery model and licensing

Your Feedback Matters!

Thanks,
Dennis Garavsky
Principal Product Manager
dennis@devexpress.com

Application Security — Documents Are Untrusted Input

Oliver Sturm (DevExpress) — Fri, 29 May 2026 07:04:00 Z

A .docx is a ZIP file

Open a .docx file in a hex editor and the first two bytes are PK. Every modern Office format - .docx, .xlsx, .pptx - is a ZIP archive of XML parts and embedded resources. PDF is not a ZIP file, but just like Office formats it is a container. When your code loads any of these file types, some complex work is done with the content of that container: compressed streams are inflated, references are resolved, an object graph is materialized.

Most of us understand a “load document” feature to be a passive read operation: bytes in, document model out, nothing happens that we didn’t ask for. But loading is not passive, and the document itself dictates the shape and size of the process. A document can instruct the loader to allocate gigabytes from a few kilobytes on disk, to follow a path that climbs out of the extraction directory, or to decrypt with primitives pulled in by the format specification implicitly. The document is input, but it must be treated as untrusted input.

Loading a document implies a security boundary.

Here are a few examples of known attack vectors used “in the wild” against document loaders:

“Decompression bombs” are small archives that inflate to a size which exhausts memory.
Path traversal (“Zip Slip”) can write outside the intended directory when extracted carelessly, by using an entry named ../../etc/something or ..\..\Windows\System32\something.
Symlink and device-name tricks use entries resolving to absolute paths, or to reserved Windows names like CON, NUL, PRN, to cause damage when extracted.

”Compatible” is not “secure”

Most applications which load documents can’t easily decide to only support the latest formats. Of course we know not to assume that old formats are as secure as new ones, but since support for legacy formats is required, we may believe that if our loader algorithms are compliant with the latest standards, then we are secure. Unfortunately, that is not always the case.

For example, a PDF may be encrypted with AES-128. By name that is a modern choice, nothing obviously legacy about it. But the PDF standard (ISO 32000-1) requires AES-128-encrypted PDFs to derive the encryption key with MD5 and to validate permissions with RC4. Both are long recognized as cryptographically weak, and neither is permitted under FIPS 140-2, the US government’s cryptographic standard. PDF readers that support AES-128 encryption need to support MD5 and RC4, and this means that the code path that loads such documents is not FIPS-compliant.

This is what “compatible isn’t secure” actually means: you didn’t knowingly pick something old, but your choice to support a seemingly current format carries a hidden legacy dependency. The same is true of Office document protection: the latest OpenXML formats support SHA-512 hashing, but they also support SHA-1 and MD5 for legacy reasons. If you support the format, you support the legacy algorithms too.

A document format is a specification, and it can mandate approaches that your application code can’t avoid. Your exposure is inherited from the standards you choose to support, not introduced by any mistakes you made.

In the .NET space in particular, the Windows FIPS policy used to be the main line of defence against this problem. If you tried to load a document that triggered a non-compliant code path, the runtime would throw an exception. However, this safety mechanism was never perfect:

On .NET Framework with the Windows FIPS policy enabled, instantiating a non-validated algorithm threw an exception. However, that exception was a TargetInvocationException with a message pointing at a generic non-validated implementation, and lacking details like the document type or the offending algorithm.
On .NET 5 and later, managed FIPS enforcement was largely removed. An MD5/RC4 code path now runs with no error at all. The trap is the transition: code that threw reliably on .NET Framework can fall silent after a routine upgrade to .NET 5 or later, with no source change. It is easy to read that silence as the problem having been fixed, when in fact only the diagnostic has gone, while the code remains exactly as non -compliant, just quieter about it.

This means that any loader code is responsible for auditing the document types it supports. We can’t rely on the runtime to enforce compliance.

Office & PDF File API: compliance and safety by design

The latest Office & PDF File API answers both halves of the problem with a single idea: compliance and structural safety should be enforced automatically and early in the pipeline.

At the cryptographic layer, FIPS enforcement is now explicit. On a FIPS-enforced Windows system, opening or saving a document that depends on cryptography prohibited by FIPS (this includes encrypted XLS or DOC files, AES-128 or ARC4 PDFs, OpenXML protection using SHA-1 or MD5 hashes) throws a DevExpress.Utils.OperatingSystemLevelFipsMode.ComplianceViolationException before processing. We made two design choices to improve upon the .NET Framework-style handling. First, the exception derives from System.Security.SecurityException, so existing catch (SecurityException) blocks keep working unchanged. Second, the message includes actionable details: instead of the runtime’s generic string, our message tells you which detail of the document you attempted to load was non-compliant, and we include suggestions for compliance.

Note that on machines which are not configured with the Windows FIPS policy, or in non-Windows environments, no cryptography validation is performed. It is possible to force the same behavior by setting DevExpress.Utils.OperatingSystemLevelFipsMode.ForcedFipsMode to true, and you can use IsEnabled on the same type to detect whether the policy is active. Setting ForcedFipsMode does not change the operating system level policy.

At the structural layer, the new SecureZipPolicy applies to both the low-level data engine (DevExpress.Utils.Zip) and the high-level API (DevExpress.Compression.ZipArchive). It enforces resource limits with sensible defaults, such as maximum entry count, per-entry and total uncompressed size, per-entry and total compression ratio to guard against “decompression bombs”, as well as path-nesting depth. It blocks the structural attacks mentioned earlier: path traversal, absolute paths, control characters, reserved device names, symlinks. The write-time encryption default also changes from the old EncryptionType.PkZip to AES-256.

The structural enforcement through SecureZipPolicy applies to all ZIP processing and is not tied to the FIPS policy. But on systems that do not have FIPS enabled, a call to SecureZipPolicy.SetEncryptionPolicy(...) with either AesRequired or FipsStrict (the latter disallows any unknown encryption types on read) enables the encryption policies regardless of any OS-level configuration.

Some of these changes may be “breaking”

If you process documents on FIPS-enforced systems, code that previously ran on .NET 5 or later may now throw an exception. We have published detailed guidance for existing code, Breaking Change T1327031 for the Office and PDF File API and Breaking Change T1325920 for the new Zip Security Policy.

It is important to point out that these changes are only “breaking” in the sense that they change behavior for existing implementations. They make your code safer (very directly so in the case of the new Zip security policy), and offer improved discoverability and auditability of violations for FIPS compliance.

Without repeating the details of the guides, it is possible to adjust some of the defaults to restore old behavior, but also to accommodate your requirements. For example, the Zip policy has tunable parameters for resource protection.

We recommend that you take the opportunity to review your document processing code and consider whether you can migrate to more secure formats. You can use the new observable violations to identify documents that are currently being processed but would not be compliant with the new policies, and then make informed decisions.

Compatibility and security

A common perception is that security and compatibility are always in tension. We should state up front that this is not generally true. The new Office & PDF File API is an example of a case where the compliant choice and the convenient choice are the same, and the new enforcement simply makes that alignment visible. For many applications, there is no meaningful trade-off between security and compatibility.

The real conflict between security and compatibility is mostly at the legacy surface area. Sticking to documents as the main topic of this article, that legacy surface area can be large if you need to support old formats and old storage standards, but it can be small if you can migrate to current formats.

There are two recommendations for navigation of this tension.

First, if you can use current formats, do. Migrating encrypted XLS to XLSX, DOC to DOCX and AES-128/ARC4 PDFs to AES-256 (Revision 6) is an easy and cheap path - speaking from the purely technical perspective of course, while organizational and regulatory constraints may be more complex, and only you can judge the practical complexity of migration in your environment.

If legacy formats are genuinely unavoidable, then treat those documents explicitly as untrusted input and wrap them accordingly: you now get resource limits by default, and you can consider separating your loading or conversion logic out to a standalone process that makes it possible to apply OS limits on memory use or prevent network access - bearing in mind that any loading method still parses the document, so the point of a separate process is to contain that parse, not to avoid it.

Depending on the exposure your project has to unverified input, you will find your own balance of “defense in depth” measures, but it is important to make active decisions about these assessments. Monitoring for violations is easy with the new policies, and the ResourceLimitViolation and TrustBoundaryViolation events exist precisely so that you gain auditability that matters particularly in regulated, enterprise, and government environments.

Your Feedback Matters!

SBOMs for CRA Compliance in DevExpress-Based Apps — Preview Now Open

Alex Chuev (DevExpress) — Thu, 07 May 2026 10:10:00 Z

If you ship apps to customers in the EU, the Cyber Resilience Act (CRA) will require a Software Bill of Materials (SBOM) as part of your conformity documentation. SBOM generation and CRA compliance are top priorities for DevExpress, and CycloneDX SBOM files for our .NET NuGet packages are now available as a preview. We are looking for feedback to help us refine our solution before a broader release.

Why This Matters

Regulatory expectations around software supply chain transparency have moved from emerging practice to a baseline requirement over the past four years:

2021 — SBOM became a key requirement of the US Executive Order 14028 on Improving the Nation's Cybersecurity.
2022 — Microsoft open-sourced its SBOM generation tool, signaling SBOM as a standard part of the build pipeline.
2024 — Germany's BSI TR-03183 Part 2 made SBOM delivery mandatory for products in scope. The EU Cyber Resilience Act (CRA) adopted the same requirement and entered into force on December 10, 2024, with a three-year transition period. Manufacturers selling digital products in the EU must produce and maintain SBOMs for conformity assessment.
2026 — CRA vulnerability reporting obligations apply from September 11, 2026, ahead of full applicability on December 11, 2027.

Under the CRA, SBOM obligation falls on the manufacturer of the finished product. You can run an SBOM generation tool against your project and assemble most of what you need. But tools that read package manifests cannot reliably see bundled NPM assets, statically-linked code, or license attribution for third-party components embedded at build time. A vendor-signed SBOM can fill these gaps and serve as stronger evidence when compared to tool-derived data. Our goal is to provide SBOMs that fit cleanly into workflows you already use.

What's Available Today (Preview)

DevExpress publishes digitally-signed CycloneDX 1.6 SBOM files for our .NET NuGet packages. Each SBOM is updated with every build. These files use our production format and signing pipeline — "preview" status reflects ongoing metadata alignment with NTIA Minimum Elements and BSI TR-03183, not file quality.

Each SBOM:

Lists first-party and third-party dependencies, including transitive dependencies.
Includes a dependency graph for the package it describes.
Lists corresponding NPM packages and their transitive dependencies when DevExpress .NET packages bundle client-side NPM assets.
Marks NPM devDependencies (used during development but not shipped) with "scope": "excluded" for transparency.

These files can be consumed by standard SBOM analysis tools — including Dependency-Track, Trivy, and Grype.

Current Scope

This first release covers DevExpress .NET product packages (Blazor, WinForms, WPF, ASP.NET Core, Web Forms, MVC, and shared component libraries) published on NuGet.org for our current shipping version (v25.2.6). It does not yet cover VCL or DevExtreme product libraries, installers, demos, packages from our private NuGet feed, standalone assembly-level SBOMs, or earlier package versions. We are starting with this narrow scope so we can refine output based on customer requirements before broadening coverage.

For complete technical details — including known limitations, format specifics, and step-by-step guidance for Dependency-Track, Trivy, and Grype — see our SBOM discussion thread.

Your Feedback Matters

Our SBOM preview is now open to additional participants — particularly developers working on compliance, supply chain security, or vulnerability management for applications built with DevExpress components.

If you are willing to test our SBOM files in your existing tooling and share what works (and what does not), please complete the survey below. After you submit, our team contacts you with download access and next steps. Survey participants also get a direct line to the product team. If you would prefer to discuss specifics outside the survey, you can also open a private support ticket.

Microsoft Build 2026 is coming!

Julian Bucknall (DevExpress) — Mon, 27 Apr 2026 15:10:00 Z

...And we shall be there! Not in Seattle this year, but, for a change, in San Francisco. To be more accurate, Microsoft Build will be at Fort Mason Center in San Francisco, CA. for two full days, June 2-3. As is usual, sessions will also be broadcast online.

The main emphasis of Microsoft Build 2026 is going to be AI. Not only how to use AI workflows and agents to write code and applications, but also how to provide AI capabilities to end-users to help them use those apps. Naturally sessions will also cover how developers "supervise" output from AI agents through testing, checking outputs for security, applicability, and so on. For more details on the sessions that will occur at Build, please follow this link.

Like every year, DevExpress will have a booth in the Partner Hub, and we will be there to chat to attendees about what's happening with our next major releases coming up in late June, as well as how we're supporting the topics highlighted in the Build sessions. We'll talk about how we're providing support for AI agents when writing apps with our controls, as well as how we're providing AI capabilities for end-users of the apps that use those controls.

We look forward to seeing you at our booth if you're going to Microsoft Build 2026. Do please stop by and say hello!

Application Security — Project Dependency "Version Bumps" Demystified or Modern Security Realities in .NET / NuGet Ecosystem

Dennis Garavsky (DevExpress) — Fri, 24 Apr 2026 09:44:00 Z

In this post, I want to show you how to effectively upgrade vulnerable third-party dependencies in your projects, highlight .NET industry best practices, and also clarify how DevExpress helps you mitigate security-related risks in general. For illustration purposes, I will use a System.Security.Cryptography.Xml-related security advisory, which Microsoft published in the GitHub Advisory database last week.

You probably already know about this report from NuGet, Visual Studio, or DevExpress Support Center. And if not, it's important to note that such reports impact every NuGet package, which has direct or transitive dependencies on the highlighted package version (it's not specific to DevExpress directly). Ultimately, even if such external advisories do not originate from DevExpress, they may impact DevExpress packages and DevExpress customers via a chain of system or third-party sub-dependencies. Hence, it's still our responsibility as a component vendor to inform our customers, improve transparency and awareness of the best practices, update problematic dependencies of affected DevExpress packages in our new releases.

As a result of this System.Security.Cryptography.Xml advisory, you might see warnings in your Solution Explorer, NuGet Package Manager or just build output (example for .NET 8 projects). Since we also build .NET projects and use the same development tools daily, we knew about this new report right after its publication in the GitHub Advisory database on April 13-14th 2026 (much like you, other vendors or anyone else). Fortunately for all, a general fix (upgrade to the latest package version) is also available for all affected DevExpress and other vendor packages that were released prior to publishing such advisories (for example, DevExpress v25.2.6 released on 07 Apr 2026 - a week before this particular report).

warning NU1901: Package 'System.Security.Cryptography.Xml' 8.0.2 has a known low severity vulnerability, https://github.com/advisories/GHSA-w3x6-4m5h-cxqf
DevExpress.Blazor imports the transitive package of System.Security.Cryptography.Xml

General Fix Idea (Applicable to All Solutions)

The beauty of such simple "version bump" vulnerabilities is that you can easily fix it yourself immediately - without awaiting anyone (vendors, new package versions, etc).

You can bump the version right in your project for affected third-party dependencies (such as Microsoft .NET System.XXX or others), as described in the "How do I fix the issue?" section of the official advisory. Anyone can apply this fix at their convenience (even "within hours" of publication of the original security advisory in the CVE / GHSA database), because in this instance it's literally one line of code in one or a few places only.

I also want to emphasize that when a vulnerability occur in a system or core .NET library, many other dependent system, .NET BCL, and vendor libraries are impacted. For example, System.Security.Cryptography.Xml is used by System.ServiceModel.Http, System.ServiceModel.Primitives, System.ServiceModel and others. They are also used directly or indirectly in a dozen more packages - all are often used in many apps of even medium complexity (I am not even talking about complex apps). You will have to update those dependencies anyway, regardless DevExpress or any other impacted package vendor/third-party.

Notwithstanding the negative effects of dealing with a vulnerability, NuGet and its best practices such as Central Package Management (CPM) exist in the development world - all to deal with such incidents quickly and to address modern realities effectively.

Solution #1: You Have a Few Projects Only or Are NOT Using CPM

Applicability: Simple applications (~1-3-5 projects in your solution) targeting any .NET version, no CPM.
Urgency: High (apply immediately).
Complexity: Medium - Copy and maintain one code line in X files (the number of your projects).
Risks: Low.

If you have no CPM, the standard Microsoft solution is to:

1. Add a direct NuGet package reference (PackageReference) to your required projects (CSPROJ/VBPROJ);
2. Set the patched version (Version) from the advisory (for example, 8.0.3 for System.Security.Cryptography.Xml and .NET 8 in this case, but it can be another third-party package/version):

.NET 8: <PackageReference Include="System.Security.Cryptography.Xml" Version="8.0.3" />
.NET 9: <PackageReference Include="System.Security.Cryptography.Xml" Version="9.0.15" />
.NET 10: <PackageReference Include="System.Security.Cryptography.Xml" Version="10.0.6" />

As you can see, this is a one-line solution, which you can copy into required projects where problematic direct or transitive dependencies were detected. In my example, I copied it into 1 project only (so, 1 code line in total to maintain).

Solution #2: You Have Multiple Projects or Are Using CPM

Applicability: Medium to complex applications (more than 5 projects in your solution) targeting any .NET version, CPM configured.
Urgency: High (apply immediately).
Complexity: Low - Copy and maintain one code line in one file.
Risks: Low.

If you have too many projects so that even the one-line solution is not practical to copy/maintain, then you must seriously consider using CPM with the Directory.Packages.props file (<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>). CPM is the best or recommended development practice regardless this vulnerability discussion anyway.

Regardless how many projects you have in your .NET solution (5, 100, 200, etc.), this is always a one-line solution to maintain - that is the beauty of CPM in action.CPM is nowadays also super-fast to add to your non-CPM solution with AI assistants.

Solution #2.1 (PackageVersion)

If CPM is enabled and you need common dependencies for many different projects (not all) in a repository, the standard Microsoft solution is to:

1. Define a PackageReferenceelement without the Versionattribute in your required projects (CSPROJ/VBPROJ):

<PackageReference Include="System.Security.Cryptography.Xml"/>

2. In your Directory.Packages.props file, add a package version entry (PackageVersion) and set the patched version (Version) from the advisory (for example, 8.0.3 for System.Security.Cryptography.Xml and .NET 8 in this case, but it can be another third-party package/version):

.NET 8: <PackageVersion Include="System.Security.Cryptography.Xml" Version="8.0.3" />
.NET 9: <PackageVersion Include="System.Security.Cryptography.Xml" Version="9.0.15" />
.NET 10: <PackageVersion Include="System.Security.Cryptography.Xml" Version="10.0.6" />

Solution #2.2 (GlobalPackageReference)

If CPM is enabled and you need to specify a package to be used by every project in a repository, the standard Microsoft solution is to:

1. Add a global package reference (GlobalPackageReference) to your Directory.Packages.props file.
2.Set the patched version (Version) from the advisory (for example, 8.0.3 for System.Security.Cryptography.Xml and .NET 8 in this case, but it can be another third-party package/version):

.NET 8: <GlobalPackageReference Include="System.Security.Cryptography.Xml" Version="8.0.3" />
.NET 9: <GlobalPackageReference Include="System.Security.Cryptography.Xml" Version="9.0.15" />
.NET 10: <GlobalPackageReference Include="System.Security.Cryptography.Xml" Version="10.0.6" />

If you already maintain a Directory.Packages.props file, replacing "PackageVersion" with "GlobalPackageReference" is fast too with or without AI.

Solution #2.3 (VersionOverride)

If CPM is enabled and you need to ignore the centrally defined package version in a specific project of your repository, the standard Microsoft solution is to:

1. Add a direct NuGet package reference (PackageReference) to your required projects (CSPROJ/VBPROJ);
2. Set the patched version (VersionOverride) from the advisory (for example, 8.0.3 for System.Security.Cryptography.Xml and .NET 8 in this case, but it can be another third-party package/version):

.NET 8: <PackageReference Include="System.Security.Cryptography.Xml" VersionOverride="8.0.3" />
.NET 9: <PackageReference Include="System.Security.Cryptography.Xml" VersionOverride="9.0.15" />
.NET 10: <PackageReference Include="System.Security.Cryptography.Xml" VersionOverride="10.0.6" />

You can disable this feature in your project or Directory.Packages.props / Directory.Build.props files: <CentralPackageVersionOverrideEnabled>false</CentralPackageVersionOverrideEnabled>(in that case VersionOverride causes error NU1009).

Solution #3: Await & Install a New/Fixed DevExpress Build

Applicability: Applications of any complexity targeting the minimally supported .NET version (like .NET 8), with or without CPM.
Urgency: Low (await a few weeks).
Complexity: Medium - Download a new version and re-test your application completely.
Risks: Low - for the official maintenance update; High - for a hot-fix/intermediate build.

Affected DevExpress packages are typically updated in the next minor release according to our Security Advisories and Product Update Process. This usually takes a few weeks or so. If you wish, you can request a hot-fix/intermediate build as well. For example, for this particular System.Security.Cryptography.Xml vulnerability we updated our packages and published a fixed night build at https://downloads.devexpress.com/HotFixes/DXP/v25.2(review our hot-fix policy first before applying).

.NET 8 is the minimally supported modern .NET / .NET Core version for DevExpress v25.2 and v26.1 NuGet libs. Due to various reasons, we currently publish only a single .NET 8 package set, which is compatible with multiple .NET frameworks (.NET 9 and .NET 10).

.NET 8-based Projects

If your project targets .NET 8: our DevExpress.Printing.Core (v25.2.7+) and other affected DevExpress packages will use a non-vulnerable System.Security.Cryptography.Xml dependency (>= 8.0.3 for .NET 8) after the official fix automatically. Once you upgrade your DevExpress dependencies, the previous Solutions #1 or #2 (manual version pinning) are no longer required - remove them from your projects.

.NET 9/10-based Projects

If your project targets .NET 9/10, your solutions depend on the target project SDK and target framework:

Microsoft.NET.Sdk (the base SDK for .NET without additional targets like net10.0-windows): Implement the Solutions #1 or #2 (manual version pinning), because they are still required and recommended due to how NuGet resolution operates. How NuGet/IDE restores third-party dependencies or which versions are used eventually in your project on your target machine are out of DevExpress control. NuGet has its own rules where in a dependency tree with multiple parents, the "lowest wins" for the target framework of your end app. For example, DevExpress path → System.Security.Cryptography.Xml (>= 8.0.0) and ServiceModel path → System.Security.Cryptography.Xml (>= 10.0.0), then the result for net10 is >= 10.0.0 → choose 10.0.0 - lowest.
When it comes to built-in .NET dependencies (a part of the distributed .NET runtime on your machine), another "framework" layer is also considered (see this example situation). It's even more interesting when it comes to your third-party dependencies, which are unique for each customer app - there will be numerous dependency trees with System.ServiceModel.Http, Microsoft.Identity.Web, and other libs, for which it will be necessary to find a common denominator or override package versions. Ultimately, third-party dependencies and .NET runtimes are unique for each customer app and environment - this falls under the responsibility of the app developer eventually.
Microsoft.NET.Sdk.Web, Microsoft.NET.Sdk.Razor, or Microsoft.NET.Sdk + net10.0-windows: No manual action needed, because the System.Security.Cryptography.Xml is correctly resolved to a non-vulnerable version from the SDK bundle automatically. This version (for example, v10.0.9, not 9.0.15) is bundled in your installed .NET 9/10 runtime for your build environment/machine (of course, if your .NET 9/10 is updated properly).

Frequently Asked Questions (FAQ)

Does DevExpress release builds when it already "knows" about a vulnerability such as System.Security.Cryptography.Xml 8.0.2?

No. In this instance, DevExpress v25.2.6 was released on 07 Apr 2026, many days before the aforementioned vulnerability was even published/known to the world.

DevExpress uses a multi-layered scanning strategy for every PR (code repositories and container images are continuously and automatically scanned for vulnerabilities during the CI/CD process) prior to release. This includes Static Application Security Testing (SAST) for product source code, Software Composition Analysis (SCA) for vulnerable third-party libraries/license compliance, antiviral software installation and artifact scanning. High-risk vulnerabilities trigger an automatic 'Build Fail'. DevExpress employs a combination of commercial and internally managed security tools (including, but not limited to Veracode, Dependabot, CodeQL, NuGet Audit, VirusTotal, etc).

For more information, please review Information Security and Security - What You Need to Know.

How often similar security advisories for system/core or popular 3rd-party packages are reported?

Quite many every day - it's best to estimate it for yourself at https://github.com/advisories (filter by NuGet, NPM, or other keywords). This is also not the first and not the last vulnerability in a system/core library. For example, 3 security advisories were published for System.Security.Cryptography.Xml alone in less than 2 years. And I am not even referring to others in popular SQL Client, JSON, OData, and other libraries with even more dependencies.

To better understand the situation, let's make a thought experiment: imagine that a vendor started publishing new official builds in response to each and every security advisory immediately. For this (in theory), one would need the previous official build, bump the affected NuGet package version (such as System.Security.Cryptography.Xml), re-build, re-run automatic tests and security checks, and publish a new official build. As a result of this experiment, customers would need to deal with 3-5 new minors a week. That rough number is only considering the current CVE/GHSA update rate for .NET - for JS/NPM it would be even more frequent. As you may understand, not many customers or businesses would want such an update carousel.

How often DevExpress "bumps versions" of their .NET packages internally in response to security advisories for external NuGet packages?

Multiple times every month or so. To give you a full picture, DevExpress v25.2 .NET packages depend on over 150+ system/core .NET packages (based on our "c:\Program Files\DevExpress 25.2\Components\Sources\Directory.Packages.props" file or our public SBOM artifacts, which you can check for yourself). Our .NET packages often include our JS packages as assets, these JS packages depend on external JS/NPM packages, and so on - you got the idea or the high chances of a "version bump" at such a scale.

Good news is that we heavily rely on CPM, so this "version bumping" itself is now a mechanical routine - it just takes time and discipline from our product teams. This is basically what every developer of any serious or complex application/solution is doing nowadays, because security matters.

Why does not DevExpress release a new/fixed build within hours after a security advisory is published?

As noted in Method #3, we follow our Security Advisories and Product Update Process and update affected DevExpress packages in the next minor release (in a few weeks or so on purpose). All our builds must pass standard testing procedures. We do our best to test our software and it takes time (for example, we intentionally did not release v25.2.7 "within hours"). We simply do not want our customers rely on poorly tested software (and potentially experience bigger issues with the upgrade).

Fortunately, the current release cadence suits the majority of our customers and proved itself over the years well. In urgent cases, customers can either apply a one-line solution in their projects or request a hot-fix/intermediate build. That is also why Microsoft has Patch Tuesday monthly and NOT "hourly", and many other vendors follow similar security and testing protocols. Otherwise, it would be a mess for all vendors and customers in the .NET ecosystem, for JS ecosystem it would be even worse due to a different NPM package update strategies and the number of updated packages. In other words, the solution should never be worse than the original problem.

Application Security — Stronger Hashes and Safer Passwords

Oliver Sturm (DevExpress) — Fri, 17 Apr 2026 11:00:00 Z

Every application that stores passwords makes an implicit bet: that the hashing algorithm it chose will remain strong enough to resist attacks for as long as those hashes exist. It’s worth revisiting that bet regularly. This post walks through the reasoning behind some recent changes we’ve made to password hashing across DevExpress components, and covers broader principles that apply whether you use our tools or not.

A Quick Primer on Password Hashing

A hash function takes an input - say, a password - and produces a fixed-length string that looks nothing like the original. The critical property is that this transformation is one-way: given the hash, it should be computationally impossible to recover the original password.

Here’s a concise example using the .NET class Rfc2898DeriveBytes, which implements the PBKDF2 algorithm:

using System.Security.Cryptography;

byte[] salt = RandomNumberGenerator.GetBytes(16);
int iterations = 600_000;

byte[] hash = Rfc2898DeriveBytes.Pbkdf2(
    password: "correct-horse-battery-staple",
    salt: salt,
    iterations: iterations,
    hashAlgorithm: HashAlgorithmName.SHA512,
    outputLength: 64);

The salt ensures that identical passwords produce different hashes. The iteration count controls how much computational work is required to produce each hash, making brute-force attacks proportionally more expensive. And the choice of hash algorithm matters more than you might think, as I’ll discuss below.

NOTE: The low-level code above is intended primarily for demonstration purposes. For production-ready password hashing and storage, you may end up with a more sophisticated implementation based on Rfc2898DeriveBytes and other built-in .NET helpers. For instance, in modern ASP.NET Core applications with Identity (Blazor, Web API, Minimal APIs, ASP.NET Core MVC, Razor Pages, gRPC), you can use PasswordHasher<TUser> (Microsoft's recommendation - see below). Similar APIs can be used for other platforms: our XAF framework (for Blazor/WinForms UI and Web API) includes a PasswordCryptographer helper powered by Rfc2898DeriveBytes with additional configuration options.

Document Protection: SHA-512 for Office Documents

If you’ve used document protection in Word-compatible file formats, you know that it’s an “advisory” protection mechanism. It signals that a document shouldn’t be edited, but it’s ultimately up to the consuming application to check and enforce that flag. Document protection is not an encryption mechanism designed to provide strong security.

Even so, the protection password hash is stored inside the document. While these passwords are often shared with collaborators and hopefully aren’t reused for online banking, there’s still no good reason to make it easy for someone to brute-force the original password. In v26.1, our Document.Protect method uses the strongest hash function supported by the Office format, as documented by Microsoft. You can find the full details in our breaking change notice.

Digital Signatures: OcspClient Defaults to SHA-512

Password hashes aren’t the only place where hash strength matters. Digital signatures rely on hash functions too, and a weak hash can undermine the integrity guarantees that a signature is supposed to provide. With v26.1, the OcspClient class used for OCSP (Online Certificate Status Protocol) responses in our digital signature workflow now uses SHA-512 by default. This is a straightforward upgrade that brings the default in line with current best practices.

XAF Security System: SHA-512 with 600000 Iterations

XAF’s built-in Security System handles full user account management, including password storage. This is the scenario where hashing strength matters most, since these are real user passwords protecting real application access.

With v26.1, we’re configuring the default hash mechanism to use SHA-512 with 600000 iterations of PBKDF2. This is a significant step up from previous defaults. Because this change affects how stored passwords are verified, it can be considered a breaking change (full documentation and migration guidance is available here). We’ll provide detailed steps to help you update your application and migrate existing password hashes to the new configuration.

Why These Specific Choices?

You might wonder: why SHA-512? Why 600000 iterations? Why not something else entirely?

The short answer is that we’re following the OWASP Password Storage Cheat Sheet, specifically its guidance on PBKDF2 for environments that require FIPS-140 compliance. OWASP is widely regarded as the authoritative source for application security best practices, and their recommendations are well-researched, regularly updated, and practical.

If you handle passwords in your own applications - whether for storage, verification, or any other processing - reading the OWASP guidance in detail is highly recommended. It’s clearly written and covers important related concepts like the salts mentioned above (random values mixed into each hash to prevent precomputed attacks) and peppers (application-level secrets added as an extra layer of defense).

That said, there are two important points worth expanding on in the context of the choices we made.

NOTE: As of this writing, SHA-256 remains a fully valid, supported, and widely recommended choice (including the current OWASP and NIST guidance). Despite a larger output size, SHA-512 can be as fast as SHA-256 on modern 64-bit hardware. In practice, the overall security is driven by many more factors (like iteration count, rate limiting, and algorithm design, etc.) than the output length of a specific SHA-XXX algorithm.

Point 1: Iteration Count Is a Trade-Off, and Rate Limiting Is Non-Negotiable

The OWASP guidance for PBKDF2 with SHA-512 suggests an iteration count that is actually somewhat lower than the 600000 we adopted for XAF. That’s because iteration count is a trade-off between security and performance: more iterations mean more work for an attacker, but also more work for your server on every legitimate login.

To make an informed choice, think about where and when your application computes password hashes. How frequently does it happen? What does the load look like during peak usage? Measure how long a single hash computation takes on your hardware. These data points, combined with the OWASP guidance, will help you find the right balance for your specific situation.

This line of thinking leads to a critical complementary measure: rate limiting. No matter how strong your hash function is, if an attacker can make unlimited login attempts, they have unlimited opportunities to guess passwords. Rate limiting caps the number of attempts in a given time window, making brute-force attacks impractical even against weaker hashes.

You want this at two levels. At the application level, lock out individual accounts after repeated failures. ASP.NET Core Identity supports this through the LockoutOptions.MaxFailedAccessAttempts property in the IdentityOptions.Lockout configuration, and the XAF Security System offers equivalent functionality with the ISecurityUserLockout interface. At the edge, protect your infrastructure from being overwhelmed, by using a WAF (Web Application Firewall), Cloudflare, or a reverse proxy like Nginx or Caddy with built-in rate limiting. Use both techniques: account lockout and infrastructure protection solve different problems.

Point 2: PBKDF2 vs. Memory-Hard Algorithms - the State of the Art

If you read the OWASP cheat sheet closely, you’ll notice that PBKDF2 is positioned as the last choice in their ranked list of recommended algorithms. OWASP explicitly notes that PBKDF2 is the best option only when FIPS-140 compliance is required.

The reason is architectural. PBKDF2 is a CPU-bound algorithm, its security relies on requiring many sequential computations. The problem is that modern GPUs and purpose-built ASIC chips can perform these computations orders of magnitude faster than general-purpose CPUs. An attacker with access to specialized hardware can brute-force PBKDF2 hashes far more efficiently than a defender’s server can compute them. Some hardware of this nature can be rented conveniently in the cloud, making it accessible to a wide range of attackers.

OWASP’s preferred alternatives are memory-hard algorithms like Argon2id and scrypt. These algorithms are designed to require large amounts of memory during computation, which makes them resistant to GPU and ASIC attacks. Specialized hardware is fast at computation but has limited memory bandwidth, which levels the playing field.

However, memory-hard algorithms come with trade-offs of their own. Consider the OWASP-recommended minimum for Argon2id: 19 MiB of memory and 2 iterations per hash computation. If you need to support just 100 concurrent login attempts, that’s already 1.9 GiB of memory dedicated solely to password hashing. The calculation for your maximum concurrent user count becomes a fundamentally different exercise than with CPU-bound algorithms.

There’s also a practical consideration in the .NET ecosystem: Argon2id and scrypt are not natively supported by the .NET runtime. Using them requires third-party libraries, which introduces dependencies on external maintainers for security-critical code. Many developers and organizations reasonably conclude that a well-configured, natively supported algorithm - PBKDF2 with SHA-512 and a high iteration count - is preferable to taking on that dependency risk. This is the reasoning behind our choice for DevExpress products.

The Bottom Line

Password hashing is one of those areas where “good enough” has a shelf life. Algorithms that were considered strong a few years ago may no longer provide adequate protection against modern hardware. The updates we’re shipping in v26.1 reflect current best practices, and we encourage you to review your own applications with the same critical eye, if you handle passwords in any capacity.

Your Feedback Matters!

Application Security — Why One Does Not Simply Protect a Data Store Connection String and Other Login Credentials?

Oliver Sturm (DevExpress) — Thu, 02 Apr 2026 11:00:00 Z

A developer asks: “How do I protect my connection string in a desktop application?”

This is one of the most common security questions in .NET development, and it sounds like it should have a straightforward answer. But there is a fundamental problem we need to analyze.

When an application connects to a service, SQL Server, a REST API, any service at all, it needs credentials. That’s unavoidable.

Sometimes those are long-lived “root” credentials: usernames and passwords, API keys, client secrets. Sometimes they’re derived tokens with limited scope and lifetime. Sometimes they come from the environment, like Windows Authentication. The exact form doesn’t matter.

What matters is this:

At the moment your application uses those credentials, it has everything it needs to act on them.

And that leads directly to a part which is easily underestimated.

The reality of using credentials

If your application can use credentials, then anything that can control your application can use them too.

On a typical desktop system, the user fully controls the machine. That means they can inspect memory, attach a debugger, intercept calls, or simply drive the application in ways you didn’t intend.

To illustrate: a connection string used by an application through Entity Framework or ADO.NET can typically be found in plain text in a process memory dump, using standard tools like WinDbg or dotnet-dump. No reverse engineering required.

Managed enterprise environments can raise the cost of such attacks significantly, through tools like AppLocker, WDAC, or restricted user accounts. But the fundamental dynamic does not change: the complexity of exploitation increases, while the possibility remains. This applies to WPF or Windows Forms applications, other types of native applications, and also to server applications like those served by a web server.

If your application uses a secret to access a remote resource, you can try to hide the secret. You can encrypt it at rest. You can obfuscate it.

But none of that changes the core fact: the application itself is already authenticated, at the point where it works with the remote resource.

An attacker doesn’t need to extract the password if they can just make your application run the query, call the API, or perform the operation on their behalf.

This is a key point that many discussions miss. The problem is not just that secrets can be stolen. It’s that the application already embodies the permission those secrets grant.

So can we protect connection strings?

Not in the way people often expect. If someone can run code on the same machine, under the same user account as your application, they can make your application do anything it is allowed to do. That’s not a framework limitation or a missing feature. It’s simply how software works.

Microsoft’s own guidance reflects this reality indirectly. For example, Entity Framework explicitly recommends not relying on storing connection strings with sensitive information directly in application configuration, and instead using more secure patterns where possible (see: Entity Framework Core connection string guidance). Guidelines for ASP.NET Core go in the same direction, you can read them here.

For development, Microsoft recommends the use of the Secret Manager tool. Note that it is meant to be used for development purposes only! Local storage mechanisms are for convenience and isolation - not for real security boundaries. The fundamental issue isn’t changed by the use of these tools: locally stored secrets are not safe from the user of the machine.

The .NET platform itself does not provide a single, clear, production-ready solution for secure storage on client machines. Its built-in configuration system can read values from many sources, but it does not make those sources secure.

In Microsoft’s more current guidance, the picture does not fundamentally change. For example, documentation for MSAL.NET, specifically for desktop apps, recommends persisting token caches locally and, on Windows, protecting them using DPAPI or similar mechanisms. In other words, the responsibility for secure storage remains with the application and the underlying operating system rather than the .NET framework itself.

Integrating facilities such as DPAPI or the Windows Credential Manager with application configuration often requires additional code or libraries, as there is no standard built-in bridge between secure OS storage and the .NET configuration system. The documentation for MSAL.NET, linked just above, includes mention of the Microsoft.Identity.Client.Extensions.Msal NuGet package, which has persistence support for token caches. The best recommendation for general purpose secret persistence however is the ProtectedData class. There are third party NuGet packages in this space as well, but trustworthiness is a concern for such an important feature.

What actually helps

Once you accept that secrets inside a client application cannot be fully protected, the question changes. It’s no longer how do I hide this credential? but how do I limit the damage when it’s used by the wrong person?

There are two strategies, and they work best together.

Make credentials less worth stealing

If a credential is compromised, how much damage can it do? The answer should be: as little as possible.

Restrict permissions to the minimum required
Scope credentials to specific operations
Prefer short-lived tokens over long-lived root secrets

This is where modern identity systems earn their keep, whether cloud-based or self-hosted. OpenID Connect providers, managed identities, token services, they don’t hide secrets better. They issue weaker, narrower ones, secrets of much lower value to a potential hacker.

Reduce the blast radius

If a credential or an application is compromised, how far can the damage spread? There are two ways to constrain it: change the architecture, or change the environment.

Changing the architecture is the most powerful option: instead of giving a client direct access to a database, you introduce a service layer. The client talks to an API, the API talks to the database.

Now the high-value credentials live in a controlled environment: on a server you manage, not on every user’s machine. The API of that server, the services it publishes, define what is possible. A connection string allows arbitrary SQL. An API should not.

A service layer also solves another problem: it decouples client authentication from backend authentication. If your database or backend service only supports long-lived credentials, the API can still offer token-based, short-lived access to clients. The powerful credential stays on the server, the client never sees it.

The narrower and more specific your API is, the less damage can be done. Of course the client will still need credentials to access the API, but with a careful structure potential damage is very limited even if a client is fully compromised.

This idea can also be extended to the client environment itself. In managed Windows environments, administrators can reduce the blast radius further by restricting what users are allowed to do on the machine: limiting which applications can be executed (e.g. via AppLocker or Windows Defender Application Control), enforcing restricted user accounts, or even locking systems into kiosk-style operation. These measures do not eliminate the underlying issue, but they can make it significantly harder to exploit in practice by removing the ability to run arbitrary code alongside the application.

A service layer also opens up an entire category of server-side protections that are simply impossible to enforce on a client machine: rate limiting, anomaly detection, device or IP binding, audit logging. These don’t prevent credential misuse on their own, but they make abuse observable and containable - and they only become options once privileged access has moved off the client.

The path most people take

In practice, developers rarely jump straight to architectural changes. They tend to go through a series of steps.

First, they look for ways to avoid handling credentials at all, using Windows Authentication or similar mechanisms. If that works, it’s ideal.

If this is not an option, the second-best approach is to avoid embedding powerful credentials directly, introducing identity providers or token-based access instead.

As long as any credentials need to be stored on the client machine, secure storage becomes a concern - options have been discussed above.

At this point, many developers feel they’ve “secured” their application. But if you follow the logic from earlier, you arrive at an uncomfortable conclusion:

None of these steps prevent a determined attacker with control over the machine from using the application’s access.

And that’s where the final step becomes unavoidable.

When architecture is the only real fix

If the risk still matters - and in many systems it does! - the only meaningful improvement comes from changing the shape of the system.

Move privileged access away from the client. Introduce services. Narrow what those services do.

This doesn’t make your system invulnerable. But it changes the game from anyone with access can do anything to even with access, only specific actions are possible.

That’s a huge difference.

I strongly recommend reading our related blog series (starting with Modern Desktop Apps And Their Complex Architectures) and documentation pages about the Backend Web API Service, Data Access Security, and XAF Security Tiers. They go into more detail about how to design systems with these principles in mind. Of course this approach is complex and specific to your application, its architecture and requirements. Please don’t hesitate to reach out if we can help!

A common misconception: .NET "Secure" String

This comes up often enough to be worth addressing directly, in a few words.

SecureString was designed to minimize the time secrets exist in memory in plain text. In theory, that sounds helpful.

In practice, especially in the managed .NET environment, it does little to solve the problem. There are two reasons:

Most APIs which connect you to services require “normal” strings, so the secure in-memory representation SecureString offers needs to be converted into .NET strings. These conversions leave data in managed memory, just as if you’d stored it there all along.
Even if this could be prevented, the application still performs authenticated operations. This leaves it open to control by a local user just like before.

So while it may reduce exposure in very narrow scenarios, it does nothing to address the fundamental issue: the application already has the capability to act. Finally, it's difficult to ignore the official Microsoft recommendations (one, two, three).

Your Feedback Matters!

Microsoft Multilingual App Toolkit (MAT) Has Been Deprecated: What’s Next for DevExpress-Powered App Localization?

Dennis Garavsky (DevExpress) — Wed, 01 Apr 2026 05:15:00 Z

As you probably know, Microsoft Multilingual App Toolkit (MAT) support ended on October 15, 2025. Since MAT is no longer supported, this post documents localization-related alternatives available to the Microsoft developer community.

What MAT Deprecation Means in Practice

No future compatibility guarantees with new tooling or runtimes.
Localization assets are not lost — MAT uses standard XLIFF / RESX formats, so translations remain reusable.
Microsoft recommends moving to alternative localization tools.

What to Look for in a MAT Alternative

Key requirements for .NET apps:

Centralized localization string management
Validation and consistency checks
Reuse of translations across versions
Support for RESX/XLIFF-based workflows

New DevExpress Localization Tool at a Glance

All the aforementioned localization requirements are supported in the new DevExpress Localization Tool (available as Community Technology Preview or CTP in v25.2): Downloads | Get Started.

This new tool introduces enhanced collaboration capabilities, easier resource navigation/management, AI-powered translation services, support for multiple DevExpress products/platforms, and much more.

Key features include:

Simpler localization string management
Use advanced data shaping capabilities available in our Data Grid control to locate resources, filter or group data, and more.
Enhanced translation consistency and coverage
Locate duplicate strings, find inconsistent translations using a built-in localization validator, review context information, and run batch operations.
Multiple export types
You can export translations as satellite assemblies, NuGet packages, a single merged RESX file for multiple products (replaces hundreds of assemblies), or JSON files for JS/TS-based products.
New collaboration capabilities
You can now use change tracking, reviews, import/export capabilities, and built-in backups. All DevExpress product localization resources are available on GitHub. You can either use our Windows-based tool, modify your translations directly in RESX/XML, or build your own tool.
Support for multiple products/platforms
The current version already supports numerous DevExpress UI libraries (WinForms, WPF, Blazor, ASP.NET Core, Reports, Dashboard, XAF). We plan to add support for .NET MAUI, DevExtreme, and VCL UI Controls in future release cycles.
AI-powered resource translation
Integrate your favorite AI service into our new Localization client.

My favorite feature: a way to export all your multi-product translations to a single or merged RESX file. This is a huge time-saver or much simpler alternative to dozens of NuGet packages or satellite resources/assemblies (this standard .NET approach is still supported). A single RESX file under your control means fewer dependencies in projects: no accidentally forgotten references and no heavy maintenance later when you add a new component to the project.

The fact that the source translations reside on GitHub and the internal translation database (RESX/XML) is accessible for custom tools (yes, our customers did that too) or AI-based translations are nice additions as well. I also think that our powerful WinForms Data Grid speaks for itself.

Future Plans

Long-term goal: one unified localization platform (even for VCL and JS) instead of multiple overlapping tools. In 2026, we will improve ease of use/usability as follows:

Automatic localization resource downloads vs manual copy/paste from GitHub;
Automatic product selection for localization (based on application DLL)
Better integration with DevExtreme JS / TS (Intl and custom dictionaries), XAF (XAFML files), VCL (INI files).

Ultimately, the new DevExpress Localization Tool offers a modern path forward for DevExpress-powered apps. Older DevExpress localization utilities are now in maintenance mode (see also this comparison). For example, we will continue to maintain the localization.devexpress.com service as we have no alternatives for older DevExpress product versions, but this service will only receive bug fixes. While you can use the service for new DevExpress versions, we recommend that you give the new tool a try for translation-related tasks (on Windows at least).

Your Feedback Matters!

Thanks,
Dennis Garavsky
Principal Product Manager
dennis@devexpress.com

News

Migrating WinForms & WPF from .NET Framework to .NET 10

What This Guide Covers

Step 0: Pick the Right Target (LTS vs STS)

Step 1: Run an Assessment

Step 2: Review and Edit the Plan

Step 3: SDK-Style, PackageReference and CPM

Step 4: Fix What Modern .NET Rejects

Retire APIs with no modern equivalent

Watch for namespace clashes

The screens look wrong: fix DPI awareness

Collapse the warning storm

Step 5: Lean on Compatibility Shims

Where AI Fits, and Where You Stay in Charge

Keep the Component Code Current: AI Skills and the MCP Server

Step 6: Verify You Are Actually Done

The Takeaway

Further Reading

Beyond Prompts: Teaching AI How to Build with DevExpress

AI Needs More Than Good Prompts

When Good Code Is Still Wrong

Example 1: Generating a QR Code

Example 2: Exporting Large Excel Files

Example 3: Report Viewer Setup and Customization

When the Best Answer Is Another Question

Skills and the DevExpress MCP Server

Why Smaller Models Benefit Even More

Skills Versus Custom Instructions

Looking Beyond the Prompt

Further Reading

DevExpress Developer Survey — AI Impact, Regulatory Compliance, Upgrade & General Product Experience

Your Feedback Matters!

Application Security — Documents Are Untrusted Input

A .docx is a ZIP file

”Compatible” is not “secure”

Office & PDF File API: compliance and safety by design

Some of these changes may be “breaking”

Compatibility and security

Your Feedback Matters!

SBOMs for CRA Compliance in DevExpress-Based Apps — Preview Now Open

Why This Matters

What's Available Today (Preview)

Current Scope

Your Feedback Matters

Microsoft Build 2026 is coming!

Application Security — Project Dependency "Version Bumps" Demystified or Modern Security Realities in .NET / NuGet Ecosystem

General Fix Idea (Applicable to All Solutions)

Solution #1: You Have a Few Projects Only or Are NOT Using CPM

Solution #2: You Have Multiple Projects or Are Using CPM

Solution #2.1 (PackageVersion)

Solution #2.2 (GlobalPackageReference)

Solution #2.3 (VersionOverride)

Solution #3: Await & Install a New/Fixed DevExpress Build

.NET 8-based Projects

.NET 9/10-based Projects

Frequently Asked Questions (FAQ)

Does DevExpress release builds when it already "knows" about a vulnerability such as System.Security.Cryptography.Xml 8.0.2?

How often similar security advisories for system/core or popular 3rd-party packages are reported?

How often DevExpress "bumps versions" of their .NET packages internally in response to security advisories for external NuGet packages?

Why does not DevExpress release a new/fixed build within hours after a security advisory is published?

See Also

Application Security — Stronger Hashes and Safer Passwords

A Quick Primer on Password Hashing

Document Protection: SHA-512 for Office Documents

Digital Signatures: OcspClient Defaults to SHA-512

XAF Security System: SHA-512 with 600000 Iterations

Why These Specific Choices?

Point 1: Iteration Count Is a Trade-Off, and Rate Limiting Is Non-Negotiable

Point 2: PBKDF2 vs. Memory-Hard Algorithms - the State of the Art

The Bottom Line

Your Feedback Matters!

Application Security — Why One Does Not Simply Protect a Data Store Connection String and Other Login Credentials?

The reality of using credentials

So can we protect connection strings?

What actually helps

Make credentials less worth stealing

Reduce the blast radius

The path most people take

When architecture is the only real fix

A common misconception: .NET "Secure" String