DevExpress Universal: Visual Studio, .NET, and C# support going forward

11 July 2018

As with every planning phase we go through with regard to DevExpress Universal, we have a discussion about which versions of Visual Studio, C#, and .NET we should support in the proposed release. Our discussions about v18.2 (due in November or December this year) are no different.

After some back and forth between the relevant teams – WinForms, WPF, ASP.NET, XAF – we’ve decided to recommend the following as a minimum for our products going forward: .NET v4.5.2, Visual Studio 2015, and C# 6.

Executive summary

Let me quickly summarize the benefits and disadvantages of this recommendation, at least from an “executive” viewpoint:

1. Reduced Development Costs. Our teams will be able to use new .NET and C# features in their code. Certainly, the same functionality could be achieved with the current .NET and C# versions we support, but it does require additional resources/man-hours.

One excellent example of this cost reduction is async/await support, which is available in .NET 4.5 with C# 5. We currently maintain and write our own asynchronous code, but it would be much easier (and cheaper) were we to leverage the work done by Microsoft. Lowering this cost alone will help drive innovation for many products – for instance, it will allow us to introduce async API support for lengthy DB-intensive operations in XPO.

2. Improved Code Maintenance. With regard to our designers, templates, and so on, we are currently forced to support far too many environments and versions of Visual Studio. (For example, only a tiny fraction of our user base still uses and relies on Visual Studio 2012.) By reducing the number of versions we support – Visual Studio 2015, or later – we will simplify our internal tests and will not need to concern ourselves with how a given implementation works in older versions of Visual Studio/.NET.

3. Future Proof. .NET 4.0 was discontinued two years ago. Microsoft is no longer concerned about .NET 4 when it develops new features or applies security fixes. The longer we (and you!) wait, the harder the migration process will be.

Technical rationale

With regard to a more technical perspective, here’s why we’re going for the versions we’re choosing:

.NET 4.5.2


1. Actively maintained. Microsoft dropped .NET 4, 4.5, and 4.5.1 support over two years ago (see All newer security patches are only applied to .NET 4.5.2 and higher.

2. Startup Performance. The Native Image Task available in modern operating systems (that is, Windows 8 or later) can automatically generate native images for assemblies that target .NET 4.5.2. This can improve startup performance on machines where our libraries are installed into the GAC.

3. New Features. eXpressApp Framework’s Mobile UI depends on WCF Data Services for the backend. Known limitations exist, but with .NET 4.5 or higher, we will use ASP.NET Core’s infrastructure and features (API Controllers, dependency injection, security, etc.). .NET 4.5 also opens opportunities for .NET Standard support in certain XAF modules (common code between different .NET platforms).

4. Simplified Demos, Documentation, and Code Examples. We will be able to use the .NET/C# async feature instead of Tasks in the code examples and demos we prepare for all of you.

5. Reporting. The reporting team will be able to integrate Code Completion for scripts in our Report Designers by using Roslyn support (Roslyn requires .NET Framework 4.5.2). Currently this same feature requires an internet connection (even for custom assemblies developed by our customers) to our hosted service for the same functionality. 


1. You will not be able to run your applications on Windows XP.

2. MVC 3 and 4 will not be supported by our ASP.NET MVC server-side extensions.

C# 6


1. Performance. We currently need to determine the caller info in certain segments of our code. The introduction of Caller Information will allow us to do this slightly faster.

2. Simplified Demos, Documentation, and Code Examples. We will be able to use new C# features to simplify both our code base and the code that we provide to you. The most important feature introduced in C# 5 was async, and the most useful features in C# 6 are: null-conditional operators, nameof expressions, and expression-bodied members.

3. Simplified API. Thanks to .NET’s Caller Information feature, certain methods (e.g., the SetProperty/GetProperty methods in our MVVM Framework or the SetPropertyValue/GetPropertyValue methods in our XPO ORM library) will not require us to pass the property name as a parameter.

4. Code Stability. C# 5 fixes certain compiler issues that we currently work around in our code (JIT inlining, IL verification).


1. You will not be able to use Visual Studio 2010, 2012, or 2013 to recompile our source code, however you will still be able to use our pre-compiled assemblies in Visual Studio 2012 and 2013.

Feedback needed

It is without a doubt that some of these proposed changes could affect some of our customers. We do believe however that they are necessary in order to help us and you keep abreast of the latest developments in the .NET space (remember, more news about .NET Core 3 is on its way), and to help us reduce the burden of having to support such a wide breadth of .NET/C#/Visual Studio versions with a single codebase.

If you do have some feedback on these proposals, please email either our management team ( or myself (


Free DevExpress Products - Get Your Copy Today

The following free DevExpress product offers remain available. Should you have any questions about the free offers below, please submit a ticket via the DevExpress Support Center at your convenience. We'll be happy to follow-up.
No Comments

Please login or register to post comments.