News

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

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

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

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

The focus of this survey is as follows:

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

Your Feedback Matters!

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

Application Security — Documents Are Untrusted Input

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

A .docx is a ZIP file

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

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

Loading a document implies a security boundary.

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

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

”Compatible” is not “secure”

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

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

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

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

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

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

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

Office & PDF File API: compliance and safety by design

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

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

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

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

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

Some of these changes may be “breaking”

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

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

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

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

Compatibility and security

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

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

There are two recommendations for navigation of this tension.

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

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

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

Your Feedback Matters!

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

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

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

Why This Matters

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

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

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

What's Available Today (Preview)

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

Each SBOM:

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

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

Current Scope

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

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

Your Feedback Matters

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

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

Microsoft Build 2026 is coming!

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

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

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

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

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

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

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

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

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

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

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

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

Transform Your Development Experience with the DevExpress Documentation MCP Server

Dmitry Tokmachev (DevExpress) — Thu, 16 Oct 2025 01:45:00 Z

The Model Context Protocol (MCP) transforms the way AI assistants interact with external tools and data sources. Developed by Anthropic, MCP is an open standard that allows developers to establish secure, two-way connections between databases, APIs, and AI-powered tools. Instead of building a separate custom integration each time an AI application needs to connect to a data source or API, MCP offers a single, standardized interface. This means each AI app and each external resource only need to connect once, and from there, everything can work together seamlessly.

To meet growing demand for AI-assisted coding, we’ve configured an MCP server that connects GitHub Copilot and other MCP-compatible AI tools directly to our comprehensive documentation database. We continuously update this database as we enhance existing DevExpress documentation content and publish new help topics. You'll always have relevant, contextual, and up-to-date guidance for DevExpress components without leaving your IDE. With access to over 300,000 help topics, our server makes it easy to find the information you need using natural language queries.

In this announcement, I'll describe how to set up the DevExpress MCP server across multiple IDEs, configure AI Assistants to work with our MCP server, and offer guidance on maximizing the benefits of AI-powered documentation access.

Why Use the DevExpress Documentation MCP Server?

Traditional documentation workflows require constant context switch — you need to leave your IDE, search through docs and/or Google, and manually piece together solutions found in different sources. The DevExpress Documentation MCP server eliminates this friction by:

Contextual help: Ask questions about DevExpress components and get targeted answers with code examples retrieved from our documentation
Intelligent search: Search our entire documentation database (with more than 300,000 help topics) using natural language
Real-time documentation access: Supply up-to-date information directly to your AI assistant's context
Seamless integration: Thanks to the MCP protocol, you can leverage this capability when using GitHub Copilot's Agent Mode and other MCP-compatible tools

Here are just a few examples of what you can accomplish by delegating development tasks to AI coding agents powered by our Documentation MCP server:

Desktop Platforms

Create a WPF Window or Windows Form with a Ribbon, file menu actions, and DevExpress Grid controls.
Create a master-detail report mockup showing orders and line items from an EF Core data source directly in the DevExpress Visual Studio Report Designer.
Create a new Delphi app with our VCL components and display a report viewer with a single button click.

Web Platforms

Add a new Razor Page with our Blazor Grid, complete with editing capabilities and bound to a large data source.
Build a responsive dashboard page with range selectors, multiple chart types, and toolbar controls — or design a fully custom edit form with validation using our DevExtreme product suite (React/Angular/Vue/jQuery).
Create a DevExtreme-powered React or Angular web application using Application Templates with a single prompt.
Integrate the DevExpress Report Viewer into an ASP.NET Core application.

File and Document APIs & Cross-Platform App Framework

Generate Word mail merge documents with rich text formatting using our Document Processing APIs.
Create spreadsheets with calculated totals and summaries using our Spreadsheet APIs.
Generate business classes with proper data modeling attributes for XAF applications.

And much more...

At present, our Documentation MCP server provides AI assistants with access to documentation for the last two major versions (v24.2 and v25.1) via separate endpoints.

The DevExpress Documentation MCP server offers the following tools:

devexpress_docs_search: Performs semantic search through the documentation database and returns the top 5 matches for a user query
devexpress_docs_get_content: Allows agents to download complete help topics by URL

Additionally, our MCP server includes a built-in prompt (dxdocs.devexpress_docs_query_workflow) accessible via / in compatible coding assistants. This prompt guides the AI agent through the proper workflow and constraints for DevExpress documentation queries.

The server operates exclusively over the Streamable HTTP protocol. If you’re familiar with MCP, simply add the following endpoints to your AI assistant’s configuration and give it a try:

{
  "servers": {
    "dxdocs": {
      "url": "https://api.devexpress.com/mcp/docs",
      "type": "http"
    },
    "dxdocs24_2": {
      "url": "https://api.devexpress.com/mcp/docs?v=24.2",
      "type": "http"
    }
  }
}

DOWNLOAD THE MCP.JSON FILE

If you are not familiar with MCP, the following sections of this blog post list step-by-step setup/config instructions for the DevExpress MCP server across multiple IDEs, including Visual Studio, VS Code, and JetBrains Rider.

Using the DevExpress MCP Server

Basic Usage Pattern

Open your AI assistant in your IDE
Use Chat mode to find answers to your questions
Use Agent Mode with the MCP server for code generation
When asking DevExpress-related questions in Agent Mode, add the "Use dxdocs" (or "Use dxdocs24_2") phrase to the end of your prompt to ensure the MCP server is invoked. Alternatively, use the built-in prompt.
Approve tool execution when prompted
Review the code generated by the agent and examine comprehensive responses with code examples and documentation links

General Usage Recommendations for AI-Assisted Code Development

To maximize the effectiveness of AI-powered development tools, it's essential to approach them with the right strategy and expectations. Start by understanding the fundamentals — familiarize yourself with how large language models work and what makes different AI coding tools unique. Think of your AI assistant as a new teammate: give it detailed context, clearly explain what you need, and don’t be afraid to write long, precise prompts.

For complex tasks, first research best practices and architectural approaches using AI's Chat or Ask mode. Once you've created a solid plan, delegate the implementation to the AI agent with clear, specific instructions. Always request that the coding assistant ask clarifying questions before starting implementation if anything is unclear. Then, break down complex tasks into smaller, manageable pieces. Do not expect AI to handle multiple abstraction layers simultaneously.

Different AI models have different strengths — some excel at deep reasoning and problem-solving, others at rapid code generation. Experiment to see which works best for each task and choose the best model instead of cutting corners with weaker options: the quality compounds and impacts the effectiveness of all other practices.

Keep your existing codebase clean and well-documented, as AI assistants perform significantly better when they can reference clear and consistent patterns rather than contradictory code. When asking questions, explicitly include relevant source code files to provide necessary context.

Most importantly, always review AI-generated output: check for architectural problems, security vulnerabilities, and adherence to project standards. Ultimately, you are fully responsible for all code committed to your repository.

And last, but not least: remember that AI cannot replace domain knowledge — if requirements or implementation strategy are unclear, AI won't help much beyond completing simple tasks.

As it relates to DevExpress components and APIs, we identified multiple practices or prompt instructions that can help you get the most out of AI Assistants and our MCP server:

Be specific about the DevExpress component you're working with
Include "Use dxdocs" in your queries to force MCP tool usage
Ask follow-up questions to dive deeper into specific aspects
Request code examples when you need implementation guidance
Ask about best practices for component configuration and usage
Request the use of public APIs and adherence to established themes and style guidelines, instead of relying on custom solutions.

For instance, the instructions below help AI assistants concentrate on designer files and leverage the InitializeComponent method body in Windows Forms applications (to address UI generation tasks):

Use designer files for UI layout. All form and control layout code must go in the designer.cs file. Do not write manual layout code in the main .cs file unless you are dynamically modifying the UI at runtime
Initialize and configure WinForms controls within the InitializeComponent method call. Set properties such as Dock, Anchor, LookAndFeel, and Appearance within InitializeComponent rather than in event handlers

Prerequisites

Supported IDEs:

Visual Studio 2022 (version 17.14 or later)
Visual Studio Code
Cursor IDE
JetBrains Rider 2025.1+

Coding Assistants:

GitHub Copilot
JetBrains AI Assistant
...or other MCP-compatible AI assistants (such as Claude or Claude Code)

Since technology evolves rapidly and newer releases often include important fixes, I recommend using the latest versions of your IDE and plugins.

Setup Guide

Step 1: Enable Agent Mode in Your IDE

The DevExpress Documentation MCP server works with AI assistants that support agent mode. In this mode, AI Assistants use the MCP server to connect to external tools and data sources. This guide lists setup steps for GitHub Copilot.

Visual Studio

Update Visual Studio 2022 to at least v17.14.12.
Enable Agent Mode. Go to Tools > Options > GitHub > Copilot and activate the "Enable MCP server integration in agent mode" and "Enable Agent mode in the chat pane" options:

Please refer to the following help topic for additional information: Microsoft's Agent Mode documentation.

VS Code

To get started with GitHub Copilot's agent mode, install or update the GitHub Copilot extension. Agent mode is active by default in recent versions of VS Code, so you do not need to configure this setting. To access agent mode, open the Chat view and sign in to your GitHub account. Select Agent from the Chat mode dropdown. For detailed setup instructions, refer to the VS Code Agent Mode Guide.

Cursor

In the most recent versions of the Cursor IDE, you don't need to activate Agent mode. Simply access the chat interface with agent capabilities. For additional information, refer to Cursor's Agent documentation.

JetBrains Rider Setup

To set up AI assistance in JetBrains Rider, you'll need to update to Rider 2025.1 or later. Check that the AI Assistant plugin is already installed and install if necessary. For detailed guidance, review the following JetBrains help topic: AI Assistant Installation. Alternatively, you can install the GitHub Copilot Plugin from the JetBrains Marketplace.

Step 2: Configure the DevExpress MCP Server

Now we'll add the DevExpress documentation MCP server to your IDE configuration. MCP servers can be configured through workspace settings, user settings, or direct installation methods.

Visual Studio

Create the MCP configuration file:

Navigate to your user profile directory: %USERPROFILE%
Paste the following MCP Server configuration code to a new file named .mcp.json:

{
    "servers": {
    	"dxdocs": {
    		"url": "https://api.devexpress.com/mcp/docs",
    		"type": "http"
    	}
    },
    "inputs": []
}

Refer to the following help topic for more information: Use MCP servers.

VS Code

Use the following link for one-click installation, or proceed with the manual setup.

If you prefer manual setup, you can use either a personal or shared configuration. To configure the server at the workspace level (and share the configuration with your team), paste the following code into a new file: project/.vscode/mcp.json.

{
  "servers": {
    "dxdocs": {
      "url": "https://api.devexpress.com/mcp/docs",
      "type": "http"
    }
  },
  "inputs": []
}

For personal configuration, open the Command Palette using Ctrl+Shift+P on Windows/Linux or ⌘+Shift+P on Mac. Run the "MCP: Add Server" command and complete the setup wizard to add the DevExpress MCP server.

For additional information about MCP server setup in VS Code, refer to the following help topic: Use MCP servers in VS Code.

Cursor

You can use our pre-configured script or set up the MCP Server manually. To apply the pre-configured script, use the following one-click installation link:

For manual configuration, create a new file in your preferred configuration location:

project/.cursor/mcp.json for project-specific configuration
home_directory/.cursor/mcp.json for global configuration

To learn more about Model Context Protocol support in Cursor, navigate to the following help topic: Connect external tools and data sources to Cursor using MCP.

Paste the following code into the configuration file:

{
  "mcpServers": {
    "dxdocs": {
      "url": "https://api.devexpress.com/mcp/docs",
      "type": "sse"
    }
  }
}

Alternatively, use Cursor's MCP Settings UI: navigate to the Tools & Integrations section, click New MCP Server, and enter server details.

Refer to the following help topic for additional information: Model Context Protocol (MCP).

JetBrains Rider

Add a new MCP server as detailed in the following JetBrains Rider help topic: Model Context Protocol.

Note that at present, JetBrains Rider can only use stdio protocol with MCP servers. To set up DevExpress MCP Server, follow the documented workaround for remote servers.

If you use the GitHub Copilot Chat plugin, change the chat mode to Agent and add new tools as described in the GitHub documentation.

Step 3: Verify DevExpress MCP Server Connection

Visual Studio

To verify the connection in Visual Studio, open the GitHub Copilot Chat pane and click the Tools icon (🛠️) to view available MCP servers. Verify that the list contains DevExpress tools.

VS Code

Open the Github Copilot Chat pane using the icon in the title bar. Use the mode selector to activate Agent Mode. Click the Tools icon (🛠️) to view available MCP servers and confirm that the server list contains "dxdocs" and associated tools.

Cursor

Open Settings and navigate to Tools & Integration. Check the "dxdocs" MCP server status: the slider next to the server name should be green (indicates a successful connection).

JetBrains Rider

In JetBrains Rider, open the AI Assistant and type / to see available commands. Verify that the DevExpress MCP tools appear in the command list:

If using the GitHub Copilot Chat plugin, change the chat mode to Agent, click the Tools icon (🛠️), and ensure that DevExpress MCP tools are selected:

Step 4: Optimize Your AI Assistant with Custom Instructions

For best results when using the DevExpress documentation MCP server, define custom instructions to guide your AI assistant on how to use the tools effectively.

Use The Predefined DevExpress MCP Server Prompt

To activate the predefined prompt:

Run the following command in the chat window:/mcp.dxdocs.devexpress_docs_query_workflow.
Specify your question and submit the request.

Custom Instructions — VS Code, Visual Studio, and JetBrains Rider (GitHub Copilot)

Add a .github/copilot-instructions.md file to your solution directory. Below is a sample instructions file that you can customize and extend based on your requirements:

---
description: 'Answer questions about the DevExpress UI Components and their API using the dxdocs server'
---

You are a .NET/JavaScript programmer and DevExpress products expert.

Your task is to answer questions about DevExpress components and their APIs using dxdocs MCP server tools.

When replying to **ANY** question about DevExpress components, use the dxdocs server to construct your answer.

## Workflow:
1. **Call devexpress_docs_search** to obtain help topics related to the user's question
2. **Call devexpress_docs_get_content** to fetch and read the most relevant help topics  
3. **Reflect on the obtained content** and how it relates to the question
4. **Provide a comprehensive answer** based solely on retrieved information

## Constraints:
- **Use devexpress_docs_search only once** per question to avoid redundant queries
- **Answer questions based solely** on information obtained from MCP server tools
- If relevant code examples are available in documentation, **include those code examples**
- **Reference specific DevExpress controls and properties** mentioned in the docs
- If a user specifies a version (e.g., v24.2 or 24.2), invoke corresponding MCP server tools (e.g., dxdocs24_2)

Learn more about GitHub Copilot custom instructions in the following help topics:

Cursor

Navigate to the Settings > Rules & Memories window. Run the Add Rule command and specify a rule with similar content. For additional information about Rules in Cursor IDE, refer to the following help topic: Rules.

JetBrains Rider (AI Assistant)

Create a custon propmt in the AI Assistant chat as described in the following help topic: JetBrains Rider – Add and customize prompts.

Advanced Features

Custom Chat Modes (VS Code Only)

VS Code supports custom chat modes for specialized workflows. Chat modes are predefined configurations that allow you to tailor AI chat behavior in Visual Studio Code for specific tasks. You can switch between chat modes at any time in the Chat view, based on what you wish to accomplish.

Note: Custom chat modes are available for VS Code version 1.101 and are currently in preview.

A chat mode file is a Markdown file with the .chatmode.md suffix that contains:

Front Matter Metadata:

description: Brief description displayed as placeholder text and in hover tooltips
tools: List of available tools or tool sets for this mode
model: Specific AI model to use (optional)

Body Content:

Detailed instructions and guidelines for the AI to follow
References to instruction files using Markdown links

Create a DevExpress Chat Mode

Open the Command Palette:
- Windows/Linux: Ctrl+Shift+P
- macOS: Cmd+Shift+P
Run the command: Chat: New Mode File. Alternatively, select "Configure Modes" from the chat mode dropdown
Choose the location: Select workspace or user profile
Enter a chat mode name (e.g., DevExpress Agent Mode)
Configure the chat mode file.

By default, VS Code looks for workspace chat mode files in the .github/chatmodes folder.

Here's a custom DX Agent Chat mode that you can tailor to your needs. The chat mode description is inspired by the Beast Mode prompt:

---
description: 'DevExpress development assistant using MCP server integration'
tools: ['codebase', 'usages', 'think', 'problems', 'changes', 'terminalSelection', 'terminalLastCommand', 'fetch', 'searchResults', 'githubRepo', 'editFiles', 'search', 'runCommands', 'runTasks', 'dxdocs', 'microsoft-docs']
model: 'Claude Sonnet 4'
---
You are a .NET/JavaScript programmer and DevExpress products expert.

Your task is to answer questions about DevExpress components and their APIs, and assist in application development. For **ANY** question about DevExpress components, use the dxdocs server to construct your answer.

## Workflow:

1. Understand the user's question and identify the relevant development platform, DevExpress component or API they are asking about.
   - If the question is about a specific DevExpress control, property, or feature, make sure to note it.
   - If the question is about a general concept or best practice, try to relate it to a specific DevExpress component or feature.  
   - Think critically about what is required to answer the question effectively, considering the context and the user's needs.
   - If the question is vague or lacks detail, ask for clarification to ensure you provide the most relevant information.
   - Use sequential reasoning to break down complex questions into manageable parts, focusing on the specific DevExpress components or APIs involved.
   - Develop a clear, step-by-step plan to address the question, ensuring you cover all necessary aspects related to DevExpress components and their APIs.
   - Implement code changes incrementally, make small, testable changes, and verify each step to ensure correctness.

2. Tool Usage:
    1. **Call devexpress_docs_search** to obtain help topics related to the user's question
    2. **Call devexpress_docs_get_content** to fetch and read the most relevant help topics
    3. **In case you receive the document not found error**, try to search again with a different query or use the **fetch** tool to get the content directly from the DevExpress documentation website
    4. **Reflect on the obtained content** and how it relates to the question
    5. **Provide a comprehensive answer** based on the retrieved information

## Guidelines:

- **Use devexpress_docs_search only once** per question to avoid redundancy
- **Base answers solely** on information from MCP server tools
- **Always include code examples** when available in documentation
- **Reference specific DevExpress controls and properties** mentioned in docs
- **Share links to relevant documentation** for further reading
- **Make incremental, testable changes** when implementing solutions

## Memory:

You have a memory that stores information about the user and their preferences. This memory is used to provide a more personalized experience. You can access and update this memory as needed. The memory is stored in a file called `.github/instructions/memory.instruction.md`. If the file is empty, you'll need to create it.

When creating a new memory file, you MUST include the following front matter at the top of the file:

---
applyTo: '**'
---

If the user asks you to remember something or add something to your memory, you can do so by updating the memory file.

For additional information (creating and customizing custom chat modes) see: VS Code Chat Modes

Troubleshooting Common Issues

MCP Server Not Appearing

Symptoms: DevExpress tools don't appear in the AI interface

Solutions:

Verify configuration file syntax — JSON must be valid
Restart your IDE after configuration changes
Check the server URL — ensure it's https://api.devexpress.com/mcp/docs
Confirm Agent Mode is enabled in your IDE settings

Tool Calls Failing Silently

Symptoms: The AI assistant doesn't use DevExpress tools even when requested

Solutions:

Add "Use dxdocs" explicitly to your queries
Check tool permissions in assistant settings
Verify network connectivity to the DevExpress MCP server
Restart the MCP server connection through IDE settings

Performance Issues

Symptoms: Slow responses or timeouts

Solutions:

Check network connection — ensure stable internet connectivity
Reduce query complexity — break complex questions into smaller parts
Monitor rate limits — avoid excessive requests in short timeframes
Try different AI models — switch between available models if experiencing issues

Additional Resources

Official Documentation

Model Context Protocol Quickstart Guide
Anthropic's MCP Introduction
Microsoft's MCP Setup Guides for VS Code and Visual Studio
Cursor MCP Documentation
JetBrains MCP Guide
Official MCP Servers Repository — Browse other available MCP servers
GitHub MCP Registry — GitHub curated directory of MCP servers

Video Tutorials

Visual Studio MCP Overview — Comprehensive setup walkthrough
VS Code MCP Usage — Practical examples and tips
Advanced VS Code MCP — Deep dive into advanced features

Related Tools

Microsoft .NET Docs MCP Server: https://learn.microsoft.com/api/mcp — Helpful for general .NET development
GitHub MCP Server: Official GitHub integration for repository management
Playwright MCP Server: Browser automation capabilities using Playwright

Your Feedback Counts

We'll actively develop and improve our MCP server in the coming months, and we'd love to hear your feedback on our current implementation.

Quick Survey

Share Your Experience

We'd love to hear about your use cases and success stories: please report issues or request features via the DevExpress Support Center.

What's Next?

The DevExpress MCP server is just the start - We expect to introduce the following enhancements in the near future:

Search through DevExpress Breaking Change documents to streamline/improve the upgrade process
Access to DevExpress demo source code and examples
Integration with the public community solutions database found in our Support Center

.NET Aspire Support For An XAF Blazor Project — Custom Telemetry, Service Orchestration, Database Dependency

Oliver Sturm (DevExpress) — Mon, 21 Apr 2025 20:28:00 Z

In a recent blog post I described how an XAF Blazor project can be adjusted to support .NET Aspire. With a couple of changes to the startup logic, in both the standard XAF project template and the code added by the Aspire Visual Studio wizard, it became possible to run the XAF Blazor project as part of an Aspire orchestration - but it was the smallest possible orchestration, with just one module!

As promised, I will demonstrate a few more aspects of the Aspire based project structure. I’m leaving deployment considerations for a third post (watch out for it in the near future!), but below I’ll describe the changes I made to the sample project for the following three scenarios:

Log custom activities and metrics through Open Telemetry to the Aspire Dashboard
Make SQL Server a dependency which runs in a container coordinated by Aspire
Add an extra service to the orchestration to illustrate a slightly more complex application system

The complete sample project is available in this GitHub repository. Based on the state I described in the first blog post, please read on for details of the new functionality.

Utilize the Open Telemetry Support for Custom Application Metrics and Activities

The integration of the Aspire dashboard is one of the most obvious new features in many application projects, right after integrating Aspire. As you have seen in the first step of the demo project, it is easy to activate various default sources for tracing and metrics. After that the question quickly becomes: how do you use the telemetry system for your own needs, for logging and reporting your own metrics and activities?

As a first step, I created the file XafAspireDemo.Blazor.Server/Controllers/ImportantBusinessOperationsController.cs, with a basic implementation of an XAF controller that supplies an action. This action becomes visible in the UI automatically, so you can use it as an interactive test trigger. Here’s the code:

namespace XafAspireDemo.Blazor.Server.Controllers
{
    public class ImportantBusinessOperationsController : Controller
    {
        SimpleAction importantBusinessAction;
        IServiceProvider serviceProvider;

        public ImportantBusinessOperationsController()
        {
            importantBusinessAction = new SimpleAction(
                this,
                "ImportantBusinessAction",
                PredefinedCategory.View
            );
            importantBusinessAction.Execute += ImportantBusinessAction_Execute;
        }

        [ActivatorUtilitiesConstructor]
        public ImportantBusinessOperationsController(IServiceProvider serviceProvider)
            : this()
        {
            this.serviceProvider = serviceProvider;
        }

        private async void ImportantBusinessAction_Execute(
            object sender,
            SimpleActionExecuteEventArgs e
        )
        {
            var logger = serviceProvider.GetRequiredService<
                ILogger<ImportantBusinessOperationsController>
            >();

            importantBusinessAction.Enabled["ImportantBusinessActionRunning"] = false;

            logger.LogInformation("ImportantBusinessAction started.");

            try
            {
                // This is where we perform the magic for the important business action.
                // Run a task that waits a random time between half a second and five seconds.
                await Task.Run(() =>
                {
                    Thread.Sleep(new Random().Next(500, 5000));
                });
            }
            catch (Exception ex)
            {
                logger.LogError(ex, "ImportantBusinessAction failed.");
                throw;
            }
            finally
            {
                importantBusinessAction.Enabled["ImportantBusinessActionRunning"] = true;
            }
        }

        protected override void OnActivated()
        {
            base.OnActivated();

            var logger = serviceProvider.GetRequiredService<
                ILogger<ImportantBusinessOperationsController>
            >();
            logger.LogInformation("ImportantBusinessOperationsController activated.");
        }

        protected override void OnDeactivated()
        {
            var logger = serviceProvider.GetRequiredService<
                ILogger<ImportantBusinessOperationsController>
            >();
            logger.LogInformation("ImportantBusinessOperationsController deactivated.");

            base.OnDeactivated();
        }
    }
}

As you can see, this code is already instrumented with some log output instructions. It uses the standard ILogger<T> interface that is part of .NET, coupled with constructor injection with IServiceProvider, which is preferred by XAF to retrieve the injected service in the controller implementation.

The logging functionality supplied by the ASP.NET Core infrastructure integrates with the Aspire Dashboard automatically. With the above changes, you can run the application and click the Important Business Action button. The implementation disables the button for a random duration and outputs log lines during initialization and on startup of the interactive process. In the Aspire Dashboard, the Structured Logs page displays this output.

Now, in order to record Open Telemetry activities and work with meters, these objects need to be initialized on application startup, and any code that should interface with the generated objects must be able to retrieve them. This could be achieved by a global singleton implementation, for example, but in the demo app it makes more sense to take advantage of dependency injection again and let it handle the singleton aspect.

Here is the implementation of the class XafAspireDemo.Blazor.Server.Telemetry:

namespace XafAspireDemo.Blazor.Server
{
    public class Telemetry : IDisposable
    {
        public ActivitySource ActivitySource { get; }
        public Meter Meter { get; }
        public string MeterName => Meter.Name;
        public Counter<long> ImportantBusinessOperationCounter { get; }
        public Histogram<double> ImportantBusinessOperationDuration { get; }

        public Telemetry(
            string serviceName = "XafAspireDemo.Blazor.Server",
            string version = "1.0.0"
        )
        {
            ActivitySource = new ActivitySource(serviceName, version);
            Meter = new Meter(serviceName, version);

            ImportantBusinessOperationCounter = Meter.CreateCounter<long>(
                "important_business_operation.execution_count"
            );
            ImportantBusinessOperationDuration = Meter.CreateHistogram<double>(
                "important_business_operation.execution_duration"
            );
        }

        public void Dispose()
        {
            ActivitySource.Dispose();
            Meter.Dispose();
        }
    }
}

The types ActivitySource, Meter, Counter<T> and Histogram<T> are all from the System.Diagnostics.Metrics namespace. The class simply instantiates these on startup and disposes of them when the application run ends. Now you just need a few lines to create an instance and register it as a singleton for dependency injection. Of course other patterns are possible, but this approach is convenient for the structure of the demo.

This code goes in XafAspireDemo.Blazor.Server/Startup.cs:

    builder.AddEntityFrameworkCoreInstrumentation();
});

--> var telemetry = new Telemetry();
--> services.AddSingleton(telemetry);

--> services
-->     .AddOpenTelemetry()
-->     .WithTracing(tracing => tracing.AddSource("XafAspireDemo.Blazor.Server"))
-->     .WithMetrics(metrics =>
-->     {
-->         metrics.AddMeter(telemetry.MeterName);
-->     });

services.AddSingleton(
    typeof(Microsoft.AspNetCore.SignalR.HubConnectionHandler<>),

What remains is to use the new features in the sample controller. I added a few lines to the execution handler for the ImportantBusinessAction:

private async void ImportantBusinessAction_Execute(
    object sender,
    SimpleActionExecuteEventArgs e
)
{
-->    var telemetry = serviceProvider.GetRequiredService<Telemetry>();
    var logger = serviceProvider.GetRequiredService<
        ILogger<ImportantBusinessOperationsController>
    >();

    importantBusinessAction.Enabled["ImportantBusinessActionRunning"] = false;

-->    using var activity = telemetry.ActivitySource.StartActivity("ImportantBusinessAction");
    logger.LogInformation("ImportantBusinessAction started.");

    try
    {
		...
    }
    catch (Exception ex)
    {
        logger.LogError(ex, "ImportantBusinessAction failed.");
-->        activity?.SetStatus(ActivityStatusCode.Error);
-->        activity?.AddException(ex);
        throw;
    }
    finally
    {
-->        activity?.Stop();

        importantBusinessAction.Enabled["ImportantBusinessActionRunning"] = true;

-->        telemetry.ImportantBusinessOperationCounter.Add(1);
-->        telemetry.ImportantBusinessOperationDuration.Record(
-->            activity.Duration.TotalMilliseconds
-->        );
    }
}

At the top of the method, the reference to the singleton is retrieved from dependency injection, just like the ILogger<T>. An activity is started near the top of the method, and further code below adds details to this activity if an error occurs, and uses the activity’s Duration property to figure out how long the process ran. The two meter elements ImportantBusinessOperationCounter and ImportantBusinessOperationDuration are modified to include details about the current run.

With these elements in place, the Aspire Dashboard now displays the new metrics and activities when the business operation is executed. Note that a link is also generated between a meter entry (for instance a duration record) and the corresponding activity - the Open Telemetry system is clever and handles much of this automatically.

Add SQL Server as a Container Dependency

One of the best things about Aspire is that it can handle infrastructure dependencies of your application system for you. There are numerous NuGet packages by now, usually named starting with Aspire.Hosting., which provide wrappers to interface with specific architectural components. One such component is SQL Server, and as expected the package Aspire.Hosting.SqlServer makes this available.

Note that the NuGet package reference needs to be added to the project XafAspire.AppHost, since this is where the SQL Server instance will be configured as part of the orchestration!

A second note: to run containers as part of an Aspire orchestration, you need to have a container runtime installed. Please check out this Microsoft documentation page in case you need help with this step.

To declare that the orchestration requires a SQL Server component, and that it will be a dependency for the Blazor Server process, all you need are a few lines of code in the file XafAspireDemo.AppHost/Program.cs:

var builder = DistributedApplication.CreateBuilder(args);

--> var sql = builder.AddSqlServer("sql")
-->    .WithLifetime(ContainerLifetime.Persistent);

--> var db = sql.AddDatabase("XafAspireDemoDb");

builder
    .AddProject<Projects.XafAspireDemo_Blazor_Server>("xafaspiredemo-blazor-server")
    .WithHttpsEndpoint()
-->    .WithReference(db)
-->    .WaitFor(db);

builder.Build().Run();

First, the call to AddSqlServer establishes the component of the orchestration for your application system. The call WithLifetime(ContainerLifetime.Persistent) is often useful in development, because the container would otherwise be started and stopped with each run of the application system, which results in loss of any test data. With the Persistent parameter, the container is left running when the rest of the application system stops, which speeds up the next run and retains data.

The database reference for a demo database is passed through to the Blazor Server project, and the WaitFor call makes sure that the database is ready for action before the Blazor Server app attempts to access it.

That’s all it is on the orchestration side! It’s interesting that this approach to working with SQL Server does not need you to understand anything about connection strings and other specific details, for the first time in SQL Server history!

Nevertheless, of course we need to find out how the Blazor Server app connects to the new dependency now. Aspire has some automatic handling that finds out how the container with SQL Server can be contacted, and it provides a connection string automatically in an environment variable. The name of that variable is constructed similar to those environment variables that overload configuration file content, and it incorporates the name of the database in the setup. For the code above, the environment variable name is ConnectionStrings__XafAspireDemoDb.

By running the application at the current point, keeping in mind that the connection to the new containerized database is not being used yet, you can see that a SQL Server container is started (for example in Docker Desktop), and that the dashboard displays the new dependency correctly. The environment variable with the connection string is also visible in the dashboard.

The connection string includes a local port number, which is served by a proxy service provided by Aspire. The password for the database user sa is auto-generated by the Aspire adapter.

One change is now missing to allow the Blazor Server app to use the containerized SQL Server. Edit the file XafAspireDemo.Blazor.Server/Startup.cs and find the block in the ConfigureServices method where the connectionString is assigned. In the default XAF template, the code loads the connection string by calling Configuration.GetConnectionString. Replace this code with a simple evaluation of the environment variable:

    //options.UseInMemoryDatabase("InMemory");

    // The environment variable is published by the Aspire Host
-->    string connectionString = 
-->        Environment.GetEnvironmentVariable("ConnectionStrings__XafAspireDemoDb");

#if EASYTEST
    if (
        Configuration.GetConnectionString("EasyTestConnectionString")

Now you can run the application again, and the SQL Server in the container will be used instead of any other instance you used before.

A little bit more…

One of the great details about setting your project up to use infrastructure containers is that other devs can easily execute the project on their machines without having to prepare their environment. For example, I was able to run the complete demo solution on my Mac at this point! There are two details I’d like to bring up in this regard.

First, I simply used dotnet run --project XafAspireDemo.AppHost on the Mac, and there was a surprisingly large number of warnings and errors as soon as I tried to do anything in the dashboard. It turned out that this happened because I had not explicitly trusted the dev-time HTTPS certificates generated by .NET. This is usually not a big deal in my experience, it just leads to the occasional warning, but the Aspire Dashboard seems to rely on these certificates to a much greater extent for its gRPC connections.

You can read all about using HTTPS with ASP.NET Core in this Microsoft documentation, and the simple command dotnet dev-certs https --trust establishes the necessary trust and the gRPC connection issues go away.

Second, when running without a debugger attached, the standard behavior of XAF changes with regard to automatic database schema updates and updater execution. In a production deployment, you would deal with this as described in the XAF documentation here, but for my dev purposes I decided to extend the automatic update mechanism to cover the Aspire scenario I was using.

I edited the file XafAspireDemo.Blazor.Server/BlazorApplication.cs, which includes a line where the environment is checked for an attached debugger - if this is found, an automatic update is executed. I extended this line to accept an environment variable as an alternative:

--> if(Environment.GetEnvironmentVariable("ASPIRE_DEBUG") != null || System.Diagnostics.Debugger.IsAttached) {
    e.Updater.Update();
    e.Handled = true;
}

Now I modified the Aspire host startup logic in XafAspireDemo.AppHost/Program.cs to set this variable on startup:

builder
    .AddProject<Projects.XafAspireDemo_Blazor_Server>("xafaspiredemo-blazor-server")
-->    .WithEnvironment("ASPIRE_DEBUG", "true")
    .WithHttpsEndpoint()
    .WithReference(db)
    .WaitFor(db);

With these changes in place, the demo solution now runs perfectly on my Mac!

Orchestrate Additional Application Services

So far, the orchestration has two parts: the SQL Server and the Blazor Server app. I’ll add an extra service to the application system now, which will be called from the test controller in the Blazor app.

I start by creating a new project and adding it to the solution. Then I add a reference to the project XafAspireDemo.ServiceDefaults to the new project, and a reference to the new project to the project XafAspireDemo.AppHost.

> dotnet new webapi -n XAFAspireDemo.DemoService

> dotnet sln add XAFAspireDemo.DemoService/XAFAspireService.DemoService.csproj

> dotnet add XAFAspireDemo.DemoService/XAFAspireService.DemoService.csproj reference XafAspireDemo.ServiceDefaults/XafAspireDemo.ServiceDefaults.csproj

> dotnet add XafAspireDemo.AppHost reference XAFAspireDemo.DemoService/XAFAspireService.DemoService.csproj

I add a class Telemetry to the new service project, similar to the one in the Blazor Server project, but using its own identifiers and names.

using System.Diagnostics;
using System.Diagnostics.Metrics;

namespace XafAspireDemo.DemoService
{
    public class Telemetry : IDisposable
    {
        public ActivitySource ActivitySource { get; }
        public Meter Meter { get; }
        public string MeterName => Meter.Name;
        public Counter<long> ImportantBusinessValueRetrievalCounter { get; }
        public Histogram<double> ImportantBusinessValueRetrievalDuration { get; }

        public Telemetry(string serviceName = "XafAspireDemo.DemoService", string version = "1.0.0")
        {
            ActivitySource = new ActivitySource(serviceName, version);
            Meter = new Meter(serviceName, version);

            ImportantBusinessValueRetrievalCounter = Meter.CreateCounter<long>(
                "important_business_value.retrieval_count"
            );
            ImportantBusinessValueRetrievalDuration = Meter.CreateHistogram<double>(
                "important_business_value.retrieval_duration"
            );
        }

        public void Dispose()
        {
            ActivitySource.Dispose();
            Meter.Dispose();
        }
    }
}

I replace the template code in XAFAspireDemo.DemoService/Program.cs with this:

using XafAspireDemo.DemoService;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddOpenApi();

builder.Services.AddAspireServiceDefaults();
builder.Services.ConfigureOpenTelemetry(builder.Configuration, builder.Environment);

var telemetry = new Telemetry();
builder.Services.AddSingleton(telemetry);

builder
    .Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing.AddSource("XafAspireDemo.DemoService"))
    .WithMetrics(metrics =>
    {
        metrics.AddMeter(telemetry.MeterName);
    });

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}

app.UseHttpsRedirection();

app.MapGet(
        "/important-business-value",
        (Telemetry telemetry) =>
        {
            using var activity = telemetry.ActivitySource.StartActivity(
                "ImportantBusinessValueRetrieval"
            );

            var importantBusinessValue = Random.Shared.Next(1, 10000);

            telemetry.ImportantBusinessValueRetrievalCounter.Add(1);

            if (activity != null)
            {
                activity.Stop();
                var durationMs = activity.Duration.TotalMilliseconds;
                telemetry.ImportantBusinessValueRetrievalDuration.Record(durationMs);
            }

            return Results.Ok(new { ImportantBusinessValue = importantBusinessValue });
        }
    )
    .WithName("GetImportantBusinessValue")
    .WithOpenApi();

app.MapDefaultAspireDevEndpoints();

app.Run();

This is all familiar code by now, just a few details to point out:

The helpers AddAspireServiceDefaults, ConfigureOpenTelemetry and MapDefaultAspireDevEndpoints are shared with the Blazor Server project for consistency
The startup pattern is very similar to that used in the Blazor Server app as well
The implementation of the handler for the /important-business-value endpoint uses the same patterns for the activity and the meters as the code in the sample controller of the Blazor app.

Now I modify the file XafAspireDemo.AppHost/Program.cs to add the new project to the orchestration. Note that I change the existing call to WithHttpsEndpoint to pass an explicit name - Aspire doesn’t like more than one parameterless call because it doesn’t assign auto-generated names.

...
var db = sql.AddDatabase("XafAspireDemoDb");

--> var demoService = builder
-->     .AddProject<Projects.XAFAspireDemo_DemoService>("demoservice")
-->     .WithHttpsEndpoint(name: "demoservice-https");

builder
    .AddProject<Projects.XafAspireDemo_Blazor_Server>("xafaspiredemo-blazor-server")
    .WithEnvironment("ASPIRE_DEBUG", "true")
-->   .WithHttpsEndpoint(name: "xafaspiredemo-blazor-server-https")
    .WithReference(db)
-->   .WithReference(demoService)
    .WaitFor(db);

To call the new service from the test controller, I need to make an HTTP client available to it. I modify XafAspireDemo.Blazor.Server/Startup.cs and add this line:

...
services.ConfigureOpenTelemetry(Configuration, WebHostEnvironment);

--> services.AddHttpClient();

services.ConfigureOpenTelemetryTracerProvider(builder =>
...

Now I can use the HTTP client to call the service from the controller in XafAspireDemo.Blazor.Server/Controllers/ImportantBusinessOperationsController.cs.

...
	{
	    Thread.Sleep(new Random().Next(500, 5000));
	});
	
--> 	var httpClientFactory = serviceProvider.GetRequiredService<IHttpClientFactory>();
--> 	var httpClient = httpClientFactory.CreateClient();
--> 	var response = await httpClient.GetFromJsonAsync<ImportantBusinessValueResponse>(
--> 	    "https://demoservice/important-business-value"
--> 	);
--> 	logger.LogInformation(
--> 	    "Received important business value from service: {ImportantBusinessValue}",
--> 	    response?.ImportantBusinessValue
--> 	);
}
catch (Exception ex)
{
...

An interesting detail: the URL for the service request uses the hostname demoservice. This is possible because the host configures the service as a dependency. As a consequence, DNS resolution for the Blazor Server allows access to this name and resolves it to the target service.

That completes the changes! When I run the application now, the Aspire Dashboard shows the new structure. The log output includes items from the new service now, the metrics are included (select the correct resource to see them!), and since the service endpoint reports its own activities, you also see nested activities in the Traces page now.

Your Feedback Matters!

In the final upcoming part of this small series, I will go into some deployment scenarios for this GitHub sample. As always, please send your feedback about Aspire, our plans or your existing and future uses of Aspire — thanks to all of you who have already done that! — and any questions or ideas, we will attempt to consider everything!

News

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

Your Feedback Matters!

Application Security — Documents Are Untrusted Input

A .docx is a ZIP file

”Compatible” is not “secure”

Office & PDF File API: compliance and safety by design

Some of these changes may be “breaking”

Compatibility and security

Your Feedback Matters!

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

Why This Matters

What's Available Today (Preview)

Current Scope

Your Feedback Matters

Microsoft Build 2026 is coming!

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

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!

Transform Your Development Experience with the DevExpress Documentation MCP Server

Why Use the DevExpress Documentation MCP Server?

Desktop Platforms

Web Platforms

File and Document APIs & Cross-Platform App Framework

Using the DevExpress MCP Server

Basic Usage Pattern

General Usage Recommendations for AI-Assisted Code Development

Prerequisites

Setup Guide

Step 1: Enable Agent Mode in Your IDE

Visual Studio

VS Code

Cursor

JetBrains Rider Setup

Step 2: Configure the DevExpress MCP Server

Visual Studio

VS Code

Cursor

JetBrains Rider

Step 3: Verify DevExpress MCP Server Connection

Visual Studio

VS Code

Cursor

JetBrains Rider

Step 4: Optimize Your AI Assistant with Custom Instructions