Developer Express Inc.

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 File API and Reporting 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 File API and Reporting 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 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 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: Reporting Setup and Viewer Customisation

Reporting 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 Reporting 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 Reporting 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 Reporting 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 API and Reporting 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 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.

What's New in CodeRush 26.1: Mermaid Diagrams, LaTeX Formulas, and Smarter AI

Mark Miller (DevExpress) — Mon, 22 Jun 2026 09:00:00 Z

This release adds support for embedding Mermaid diagrams and beautifully rendered formulas (math, chemistry, physics) into source code comments. This release also adds support for the latest AI models, improves AiGen's ability to work with diagrams and formulas, and introduces a new Test Runner feature that makes it easier to troubleshoot failing tests with AI assistance.

Let's take a look.

Mermaid Diagrams in Rich Comments

Rich Comments can now render Mermaid diagrams directly inside source code comments.

Instead of maintaining architectural diagrams in separate documentation systems that inevitably drift from the implementation, you can keep them alongside the code they describe. Mermaid source is stored in external .mmd files and referenced in the source code comment where it renders, allowing diagrams to participate naturally in source control and code reviews.

CodeRush renders Mermaid diagrams directly inside the editor, supporting a broad range of diagram types including:

Flowcharts
Sequence diagrams
Class diagrams
State diagrams
Entity Relationship diagrams
Git graphs
Mind maps
Timelines
ZenUML
And many more

]

Diagrams can be edited in place by right-clicking the rendered image and selecting Edit Diagram. The integrated editor provides a live preview while you modify the Mermaid source inside Visual Studio, eliminating the need to switch to external tools. You can even have AiGen generate and modify Mermaid source automatically -- more on that in a bit.

We added two display options make diagrams easier to manage in larger files.

Thumbnail Mode collapses a diagram into a compact preview that expands on demand, making it ideal for large architectural diagrams. Just click the thumbnail to see it in the full size image viewer.

When a thumbnail expands, it appears in a special image viewer that makes it easy to explore large images. You can zoom in and out with the mouse wheel and you can click and drag to shift your view into the large image.

Fit in TextView automatically scales diagrams to fit the current editor window, helping them remain readable at a glance without introducing unnecessary scrolling.

Enhanced LaTeX Support

LaTeX support has graduated from beta and now provides sharper output, improved performance, and expanded support for complex mathematical notation, including matrices, piecewise functions, chemistry notation, physics symbols, and multi-line expressions.

Formulas automatically scale with the editor font, allowing them to integrate naturally with surrounding code.

The following templates create formula placeholders inside code comments:

Language	Template	Expansion
C#	/f	// <formula >
VB	‘f	‘ <formula >
XAML	!f	<!– <formula > –>

After expanding one of the templates above in the appropriate source file, you can paste in the LaTeX equation (you can also use online LaTeX equation editors to create formulas)

Templates for LaTeX formula components:

Template	Description	Expansion
\.	Centered dot	\cdot
\..	Three centered dots	\cdots
\8	Infinity	\infty
\b	Braces	{}
\bca	Big Cap	\bigcap_{lower}^{upper}
\bcu	Big Cup	\bigcup_{lower}^{upper}
\cp	Co-product	\coprod_{lower}^{upper}
\f	Fraction	\frac{numerator}{denominator}
\l	Limit	\lim_{x\to\infty}
\lr	Left & Right Parens	\left( \right)
\nr	nth Root	\sqrt[root]{value}
\o	Circle symbol	\circ
\oi	Contour integral	\oint
\p	Product	\prod_{lower}^{upper}
\s	Sum	\sum_{lower}^{upper}
\sq	Square Root	\sqrt{value}
\v	Vector	\vec{numerator}

Together with Mermaid support, Rich Comments become an effective place to capture visuals of algorithms, mathematical derivations, engineering and architectural diagrams directly within the source code.

AiGen Works with Code, Diagrams, and Formulas

AiGen now understands not only your source code, but also the Mermaid diagrams and LaTeX formulas contained within Rich Comments.

This enables new workflows. You can ask AiGen to generate diagrams from existing code, generate code from diagrams, create LaTeX representations of algorithms, or analyze whether documentation and implementation remain consistent.

Here's an example of a Mermaid diagram in Visual Studio generated from the source code below it.

Keeping documentation synchronized with evolving code has traditionally been a manual process. Because AI can now reason across both implementation and in-source documentation (including diagrams and formulas), you can use CodeRush and AiGen to realign architectural drift over time.

You can also ask AiGen to generate LaTeX formulas for expressions inside a method and have those placed inside a comment in the code. In the screenshot below notice that AI found the local variable u = 1 - t and substituted its expression everywhere the u variable appeared in the code. It also found coefficients and power equivalents and incorporated them into the formula.

Expanded AI Model Support

AiGen now supports the latest generation of AI models from multiple providers, including:

Anthropic Claude 4.5 models
Google Gemini 2.x and 3.x models
OpenAI GPT-5.5 models

Support has also been added for advanced reasoning capabilities available on supported models.

Configuring providers, selecting models, and understanding model-specific capabilities is covered in a separate blog post dedicated to AI configuration.

Copy Failed Test Report

The Test Runner includes a new Copy Failed Test Report command.

Available from the context menu, this command copies detailed information for every failing test within the selected node (and child nodes) including fully-qualified test names, execution times, exception information, and complete stack traces.

The generated report is ideal for direct use with AI assistants, making it easy to send the clipboard results to AiGen or another LLM for analysis of failing tests and identification of common root causes.

Wrapping Up

The features in this release share a common goal: keeping more of your project's knowledge inside the source code itself.

Mermaid diagrams, LaTeX formulas, and AI-generated documentation all become first-class citizens, and AiGen gets the ability to reason across code and diagram documentation together. Along with expanded AI model support and improved developer tooling like Copy Failed Test Report, these new features streamline everyday development while helping in-source documentation stay in sync with implementation.

As always, we look forward to hearing your feedback.

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

XAF Blazor/WinForms UI — Case Study by DataWerkes: Field Services Management Platform (TimeWerkes)

Dennis Garavsky (DevExpress) — Mon, 01 Jun 2026 12:49:00 Z

Meet DataWerkes (an independent software vendor in Alberta, Canada) and Keith Courneyea (a founder), who has been using our Cross-Platform .NET App UI (XAF) since 2019.

We recently published a case study about their flagship commercial product (TimeWerkes) powered by XAF WinForms/Blazor UI as well as DevExpress Blazor / WinForms (Grid & Data Editors, Charts, Pivot Grid, TreeList, Scheduler, Rich Text Editor), Reporting and BI Dashboard components.

Here is how Keith Courneyea described their product TimeWerkes (has been in active client use since late 2024):

TimeWerkes is a commercial, end-to-end field services management platform for industrial contractors. It manages the full business lifecycle of a contracting operation — from initial quoting through job execution, field ticketing (aka time reporting), inspection reporting, and final invoicing — within a single integrated application available as both a Windows desktop client and a Blazor Server web application. Currently the Blazor app in the primary client.

The platform is architected as a core business foundation with industry-specific modules that can be added as client requirements evolve. The core handles workflows common to all contractors: quotes, jobs, field tickets (aka timesheets) with labour and billable items, rate sheets, approval workflows, staff and certification management, equipment tracking, document management, and full invoicing. Specialized modules adapt this base for specific industries.

TimeWerkes is offered commercially. It is built on Microsoft SQL Server with Azure SQL in production and uses Azure Blob Storage for all document/image attachments, Azure Functions for background workflow processing, and Azure Communication Services for automated email notifications.

DataWerkes has been in operation for seven years. Keith's decision to build on DevExpress in 2019 was not the result of a product evaluation or a recommendation — it was a return. He had worked with DevExpress components in the early 2000s and had a positive experience that stayed with him. When he decided to pursue serious application development, DevExpress was the first place he went back to.

The specific choice of XAF as the framework was driven by what Keith needed as a first-time C# developer with a clear vision of what he wanted to build. XAF's model-driven approach — where defining a domain class in XPO produces a working UI, security system, and data layer without writing boilerplate infrastructure code — meant that Keith could focus on the business logic he understood deeply and let the framework handle the rest.

And here’s what Keith Courneyea said about XAF's primary benefits:

TimeWerkes uses the full breadth of the XAF module ecosystem. The Security System provides role-based access control across the entire application without custom authentication code. The Audit Trail module — extended through Llamachant's enhanced implementation — tracks every change across all 120 domain entities. The Validation module enforces business rules declaratively. Conditional Appearance drives dynamic UI behaviour. The Scheduler handles staff and job scheduling. Reports Module V2 powers 34 reports covering every business document in the system, from client-facing inspection reports to internal job cost summaries and invoices.

Critically, XAF's cross-platform architecture meant that the same core module and XPO domain model powers three deployment targets simultaneously: a WinForms desktop client, a Blazor Server web application, and an Azure Functions background processing host. A team of any size would find that a significant time saving. For a product owned by one person and built in partnership with a small development firm, it is what made the product possible at all.

Dave Hesketh of Llamachant Technology Ltd., whose team serves as the primary development partner on TimeWerkes, describes the XAF ecosystem as central to how Llamachant approaches every engagement. Llamachant's own framework extensions — including the workflow engine, Azure Blob file attachment integration, AutoIncrementingID, and LlamaLogger — are themselves built on top of XAF, which is a measure of how extensible and production-ready the platform is.

Read the full article to learn why DataWerkes chose XAF for cross-platform RAD project development and what they liked about our tools.

Get Started with XAF today if you want to build Office-like line-of-business (LOB) apps powered by Blazor and WinForms much faster than using traditional approaches. Check out XAF's demos in your DevExpress installation or online at https://demos.devexpress.com/xaf/blazordemo/. You can learn more about XAF benefits here, and our Considerations for Newcomers will help you understand whether this application framework is right for your business.

Do You Have a Story to Share?

We'd love to publish your story on our website. It doesn’t matter if the project is big or small, or which DevExpress tools you used. Fill out this simple case study form and email us at clientservices@devexpress.com.

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!

DevExpress Blazor AI Chat — Multi-Model Support, MCP Server Integration, and a Look at What's Coming Next

Dmitry Tokmachev (DevExpress) — Fri, 22 May 2026 00:01:00 Z

We continue to extend the capabilities of the DevExpress Blazor AI Chat component and publish GitHub examples designed to address real-world usage scenarios. This post highlights two new examples: a multi-model chat with persistent conversation history, and MCP server integration that extends AI context with external data sources. I'll also share planned features for v26.1 (scheduled for mid-June 2026).

Multi-Model Chat with Conversation History

Our earlier multi-LLM chat application example demonstrated how to switch between AI providers within a single chat session. The new DevExpress Blazor AI Chat — Multi-Model Chat with Conversation History example adds persistent conversation threads and automated chat session title generation.

The application uses a two-pane layout with DxSplitter. The left pane is a sidebar that hosts a DxComboBox for model selection and a DxListBox for conversation threads. InMemoryChatThreadStore manages thread data. This thread-safe dictionary-backed store tracks message history and timestamps. The right pane hosts the DxAIChat component. The following Razor markup defines the layout:

<DxSplitter CssClass="chat-splitter" Height="100%">
    <Panes>
        <DxSplitterPane Size="320px" MinSize="220px" MaxSize="500px">
            <DxButton RenderStyle="ButtonRenderStyle.Primary"
                      RenderStyleMode="ButtonRenderStyleMode.Contained"
                      Text="New Chat"
                      Click="CreateNewThreadAsync" />
            <DxComboBox Data="@ModelsList"
                        Value="@SelectedModel"
                        TextFieldName="@nameof(ChatClientSession.Name)"
                        ValueChanged="@((ChatClientSession session) => OnSelectedThreadModelChangedAsync(session))" />
            <DxListBox Data="@Threads"
                       Value="@SelectedThread"
                       ValueChanged="@((ChatThread thread) => OnThreadSelectedAsync(thread))"
                       TextFieldName="@nameof(ChatThread.Title)">
                <ItemDisplayTemplate>
                    <div class="thread-list-item">
                        <div class="thread-title">@context.DataItem.Title</div>
                        <div class="thread-model">@GetModelName(context.DataItem.ModelSessionId)</div>
                    </div>
                </ItemDisplayTemplate>
            </DxListBox>
        </DxSplitterPane>
        <DxSplitterPane>
            <DxAIChat @ref="DxAiChat"
                      Initialized="OnChatInitialized" />
        </DxSplitterPane>
    </Panes>
</DxSplitter>

Automatic thread title generation is a key implementation detail. The CompositeChatClient class implements IChatClient and intercepts outgoing user messages via GetResponseAsync and GetStreamingResponseAsync methods. On the first message in a new thread, the class sends a background request to the selected AI model using a dedicated system prompt and requests a concise 3–6 word title. IChatThreadStore stores the result. The ThreadTitleUpdated event updates the UI and refreshes the sidebar without blocking the main chat response:

// CompositeChatClient.cs
public IAsyncEnumerable<ChatResponseUpdate> GetStreamingResponseAsync(IEnumerable<ChatMessagegt; messages, 
ChatOptions? options = null, CancellationToken cancellationToken = new CancellationToken())
    {
        var selectedSession = GetRequiredSelectedSession();
        var messageList = messages.ToList();
        TryQueueTitleGeneration(messageList, selectedSession);
		...
        await foreach (var update in selectedSession.Client.GetStreamingResponseAsync(
        	messageList, options, cancellationToken))
            yield return update;
        ...
    }

private void TryQueueTitleGeneration(IEnumerable<ChatMessage> messages, ChatClientSession selectedSession) {
    var threadId = _activeThreadId.Value;
    var firstUserMessage = GetFirstUserMessage(messages);
    ...
    _ = GenerateTitleForThreadAsync(threadId, selectedSession, firstUserMessage);
}

private async Task GenerateTitleForThreadAsync(Guid threadId,
    ChatClientSession selectedSession, string firstUserMessage) {
    try {
        var thread = await _threadStore.GetThreadAsync(threadId, CancellationToken.None);
        if (thread is null || thread.HasGeneratedTitle)
            return;

        var modelSession = AvailableChatClients
            .FirstOrDefault(x => x.Id == thread.ModelSessionId) ?? selectedSession;

        string generatedTitle;
            try {
                generatedTitle = await _titleGenerator.GenerateTitleAsync(modelSession, firstUserMessage, CancellationToken.None);
            }
            catch {
                generatedTitle = _titleGenerator.BuildFallbackTitle(firstUserMessage);
            }

            if (string.IsNullOrWhiteSpace(generatedTitle)) {
                generatedTitle = _titleGenerator.BuildFallbackTitle(firstUserMessage);
            }

            await _threadStore.UpdateTitleAsync(threadId, generatedTitle, true, CancellationToken.None);
            lock (_syncRoot) {
                _titledThreadIds.Add(threadId);
            }
            ThreadTitleUpdated?.Invoke(threadId, generatedTitle);
        }
        catch (OperationCanceledException) { }
        finally {
            lock (_syncRoot)
                _titleGenerationInProgress.Remove(threadId);
        }
}

The example includes an in-memory store. The IChatThreadStore interface allows for replacement with an EF Core-backed implementation for applications that require persistent history.

To download and explore our implementation, navigate to the following DevExpress GitHub repository: Blazor AI Chat — Multi-Model Chat with Conversation History.

MCP Server Integration

The DevExpress Blazor AI Chat — Integration with Model Context Protocol example connects our Blazor AI Chat component to external data through the Model Context Protocol (MCP).

The solution includes two projects.

AIChatMcpServer is a custom MCP server that exposes sample tools, resources, and prompt templates to the client application.
AIChatMcpClient is a Blazor Server application that hosts DxAIChat and loads MCP capabilities at startup through a hosted McpRepository service.

The sample MCP server exposes three primitives: tools (executable functions the AI model can call automatically), resources (static content such as logs, text files, and binary images), and prompts (reusable parameterized templates). McpRepository loads these primitives at startup and passes them to DxAIChat.

Each primitive maps directly to a DxAIChat feature. Resources map to AIChatResource objects and populate the Resources collection. Prompts map to DxAIChatPromptSuggestion entries displayed when the chat opens. Tools attach to IChatClient through UseFunctionInvocation at startup.

Index.razor:

<DxAIChat FileUploadEnabled="true"
          Resources="Resources"
          IncludeFunctionCallInfo="true">
        <PromptSuggestions>
            @foreach (var suggestion in PromptSuggestions){
                <DxAIChatPromptSuggestion PromptMessage="@suggestion.PromptMessage" Title="@suggestion.Title" Text="@suggestion.PromptMessage"/>
            }
        </PromptSuggestions>
        <AIChatSettings>
            <DxAIChatFileUploadSettings MaxFileSize="10000000" MaxFileCount="3"/>
        </AIChatSettings>
    </DxAIChat>

@code {
    IEnumerable<AIChatResource> Resources { get; set; } = [];
    IEnumerable<PromptSuggestion> PromptSuggestions { get; set; } = [];

    protected override async Task OnInitializedAsync() {
        // Map MCP resources to AIChatResource — DxAIChat fetches content on demand via LoadResourceData
        Resources = McpRepository.Resources.Select(x =>
            new AIChatResource(x.Uri, x.Name, LoadResourceData, x.MimeType, x.Description));
        // Map MCP prompt templates to prompt suggestions shown in the chat UI
        PromptSuggestions = McpRepository.PromptSuggestions;
    }

    async Task<IList<AIContent>> LoadResourceData(AIChatResource resource, CancellationToken ct) {
        var result = await McpRepository.Client.ReadResourceAsync(resource.Uri, cancellationToken: ct);
        return result.Contents.ToAIContents();
    }
}

Program.cs:

using Azure;
using Azure.AI.OpenAI;
using AIChatMcpClient;
using AIChatMcpClient.Components;
using AIChatMcpClient.Services;
using Microsoft.Extensions.AI;
...

builder.Services.AddSingleton<McpRepository>();
builder.Services.AddHostedService(sp => sp.GetRequiredService<McpRepository>());

builder.Services.AddSingleton<IChatClient>(sp => {
    var mcpRepository = sp.GetService<McpRepository>();
    var azureOpenAIClient = new AzureOpenAIClient(
        new Uri(azureOpenAISettings.Endpoint),
        new AzureKeyCredential(azureOpenAISettings.ApiKey));
    var chatClient = azureOpenAIClient.GetChatClient(azureOpenAISettings.DeploymentName).AsIChatClient();
    return new ChatClientBuilder(chatClient)
        .ConfigureOptions(co => {
            co.Tools = mcpRepository.Tools.ToArray<AITool>();
        })
        .UseFunctionInvocation()
        .Build();
});
...

The implementation follows MCP standards. Client code requires no changes when you switch to another MCP-compliant backend. To connect the Blazor application to a different MCP server, modify the McpRepository endpoint:

using AIChatMcpClient.Models;
using ModelContextProtocol.Client;
using ModelContextProtocol.Protocol;
...
public class McpRepository : IHostedService, IAsyncDisposable {
    private readonly string _mcpEndpoint;

    public McpClient Client { get; private set; } = null!;
    public List<McpClientTool> Tools { get; } = [];
    public List<McpClientResource> Resources { get; } = [];
    public List<McpClientPrompt> Prompts { get; } = [];
    public List<PromptSuggestion> PromptSuggestions { get; } = [];

    public McpRepository(IConfiguration configuration) {
        _mcpEndpoint = configuration.GetSection("McpServer:Endpoint").Value 
                       ?? throw new InvalidOperationException("McpServer:Endpoint is not configured in appsettings.json");
    }

    public async Task StartAsync(CancellationToken cancellationToken) {
        var transport = new HttpClientTransport(new() { Endpoint = new(_mcpEndpoint) });
        Client = await McpClient.CreateAsync(transport);
        
        var tools = await Client.ListToolsAsync(cancellationToken: cancellationToken);
        var resources = await Client.ListResourcesAsync(cancellationToken: cancellationToken);
        var prompts = await Client.ListPromptsAsync(cancellationToken: cancellationToken);
        
        Tools.AddRange(tools);
        Resources.AddRange(resources);
        Prompts.AddRange(prompts);

        // Preload prompt suggestions at startup
        foreach (var prompt in Prompts) {
            var result = await prompt.GetAsync();
            var content = result.Messages[0].Content;
            PromptSuggestions.Add(new PromptSuggestion {
                PromptMessage = ((TextContentBlock)content).Text,
                Title = prompt.Title ?? "Untitled"
            });
        }
    }

    public Task StopAsync(CancellationToken cancellationToken) => Task.CompletedTask;

    public async ValueTask DisposeAsync() {
        await Client.DisposeAsync();
    }
}

To download and explore our implementation, navigate to the following DevExpress GitHub repository: DevExpress Blazor AI Chat — Integration with Model Context Protocol.

What's Coming in v26.1

Our v26.1 release is scheduled for mid-June 2026 and includes the following enhancements to DevExpress AI Chat components for Blazor, WinForms, and WPF.

Microsoft Agent Framework and OpenAI Responses API Support

The most substantial addition is a new IChatResponseProvider abstraction layer that decouples the chat UI from the underlying AI service. This layer allows you to bind DxAIChat to a wider set of AI backends beyond the standard IChatClient interface, including the Microsoft Agent Framework (with support for agents, executors, and multi-step workflows), the OpenAI Responses API, and Azure AI Projects. The API also supports custom IChatResponseProvider implementations for usage scenarios that don't fit standard providers.

Planned demos will illustrate how to connect our AI Chat Control to individual agents, composite workflows, AG-UI backends, and tool approval workflows in agentic pipelines.

API Enhancements

v26.1 replaces the MessageSent event with MessageSending. This event fires before the message is added to chat history and sent to the AI service. Additionally, this event exposes an e.Cancel parameter that allows you to block send operations entirely. Use it to preprocess and validate input, filter content, call external services and handle the messaging pipeline manually. Alternatively, if e.Cancel is set to false, the AI Chat Control will continue sending and displaying messages and allow you to log and audit user messages without disruption to the normal message pipeline.

The new event also supports augmentation before delivery — for example, appending a system message or supplemental context to the chat history via the new AppendMessageAsync method:

async void AiChatControl1_MessageSending(object sender, AIChatControlMessageSendingEventArgs e) {
    // Append a system message before sending the user's prompt to the AI service.
    await e.Chat.AppendMessageAsync("Translate text to Spanish", ChatRole.System);
}

Empty Chat Customization

v26.1 introduces two new properties designed to customize initial chat state. EmptyMessageAreaText specifies text dispalyed in the empty chat area, and InputBoxNullText specifies placeholder text in the input box. These properties allow you to align the initial chat experience with application context and tone:

<DxAIChat EmptyMessageAreaText="How can I help you today?"
          InputBoxNullText="Ask a question or describe a task..." />

Looking for a particular code example? Contact us via the DevExpress Support Center to share your usage scenario and we'll be happy to recommend an implementation.

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.

Developer Express Inc.

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: Reporting Setup and Viewer Customisation

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

What's New in CodeRush 26.1: Mermaid Diagrams, LaTeX Formulas, and Smarter AI

Mermaid Diagrams in Rich Comments

Enhanced LaTeX Support

AiGen Works with Code, Diagrams, and Formulas

Expanded AI Model Support

Copy Failed Test Report

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

Your Feedback Matters!

XAF Blazor/WinForms UI — Case Study by DataWerkes: Field Services Management Platform (TimeWerkes)

Do You Have a Story to Share?

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!

DevExpress Blazor AI Chat — Multi-Model Support, MCP Server Integration, and a Look at What's Coming Next

Multi-Model Chat with Conversation History

MCP Server Integration

What's Coming in v26.1

Microsoft Agent Framework and OpenAI Responses API Support

API Enhancements

Empty Chat Customization

Share Your Feedback

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!