Developer Express Inc.

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

How to Fix This

General Fix Idea (Applicable to All Methods)

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.

Method #1: You Have a Few Projects Only or Are NOT Using Central Package Management (CPM)

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

The standard Microsoft solution is to add a direct NuGet package reference (System.Security.Cryptography.Xml in this case, but it can be another third-party package) to your required projects (CSPROJ/VBPROJ) and set its VersionOverride property to the patched version from the advisory (for example, 8.0.3 for .NET 8):

.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" />

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 2 projects only (so, 2 code lines in total to maintain temporarily).

Method #2: You Have Multiple Projects or Are Using Central Package Management (CPM)

Applicability: Medium to complex applications (more than 5 projects in your solution), CPM configured.
Urgency: High (apply immediately).
Complexity: Low - Temporarily 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 Central Package Management (CPM). CPM is the best or recommended development practice regardless this vulnerability discussion anyway.

Once you configure CPM for your solution, you can add a global package reference to your Directory.Packages.props file:

.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" />

Regardless how many projects you have in your .NET solution (5, 100, 200, etc.), this is always a one-line solution to maintain temporarily - that is the beauty of CPM in action.

CPM is nowadays also super-fast to add to your non-CPM solution with AI assistants. If you already maintain a Directory.Packages.props, replacing "PackageVersion" with "GlobalPackageReference" is fast too with or without AI.

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

Applicability: Applications of any complexity, 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. NOTE: review our hot-fix policy first before applying.

Frequently Asked Questions (FAQ)

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

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

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

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

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

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

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

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

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

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

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

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

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

Application Security — Stronger Hashes and Safer Passwords

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

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

A Quick Primer on Password Hashing

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

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

using System.Security.Cryptography;

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

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

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

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

Document Protection: SHA-512 for Office Documents

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

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

Digital Signatures: OcspClient Defaults to SHA-512

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

XAF Security System: SHA-512 with 600000 Iterations

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

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

Why These Specific Choices?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Bottom Line

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

Your Feedback Matters!

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

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

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

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

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

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

What matters is this:

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

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

The reality of using credentials

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

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

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

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

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

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

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

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

So can we protect connection strings?

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

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

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

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

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

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

What actually helps

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

There are two strategies, and they work best together.

Make credentials less worth stealing

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

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

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

Reduce the blast radius

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

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

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

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

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

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

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

The path most people take

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

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

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

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

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

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

And that’s where the final step becomes unavoidable.

When architecture is the only real fix

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

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

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

That’s a huge difference.

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

A common misconception: .NET "Secure" String

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

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

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

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

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

Your Feedback Matters!

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

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

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

What MAT Deprecation Means in Practice

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

What to Look for in a MAT Alternative

Key requirements for .NET apps:

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

New DevExpress Localization Tool at a Glance

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

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

Key features include:

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

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

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

Future Plans

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

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

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

Your Feedback Matters!

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

Developer Express Inc.

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

How to Fix This

General Fix Idea (Applicable to All Methods)

Method #1: You Have a Few Projects Only or Are NOT Using Central Package Management (CPM)

Method #2: You Have Multiple Projects or Are Using Central Package Management (CPM)

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

Frequently Asked Questions (FAQ)

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

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

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

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

See Also

Application Security — Stronger Hashes and Safer Passwords

A Quick Primer on Password Hashing

Document Protection: SHA-512 for Office Documents

Digital Signatures: OcspClient Defaults to SHA-512

XAF Security System: SHA-512 with 600000 Iterations

Why These Specific Choices?

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

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

The Bottom Line

Your Feedback Matters!

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

The reality of using credentials

So can we protect connection strings?

What actually helps

Make credentials less worth stealing

Reduce the blast radius

The path most people take

When architecture is the only real fix

A common misconception: .NET "Secure" String

Your Feedback Matters!

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

What MAT Deprecation Means in Practice

What to Look for in a MAT Alternative

New DevExpress Localization Tool at a Glance

Future Plans

Your Feedback Matters!