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 (

40 comment(s)
Manuel Grundner [DevExpress MVP]

Right choice Julian!

XP needs to die anyway. As for the C# Version: why didnt you go for vs17 ans the latest c# Version? Vs17 Community is 'free' and the vs17 build Tools are also free. Those people that Care about rebuilding the dx sources are normally not that picky what vs version you need to Install, or are they?

Regards, Manuel

10 July, 2018

Good news!

I believe it's the best way.

Because asynchronous programming brings a lot of benefits.

Regards, Alex S Fonseca

11 July, 2018
Del W

Great news, you can always keep a virtualized setup to support older versions. VS2015 and VS2017 are so much better than their predecessors.

11 July, 2018
Eric Upton 1

Looks like the correct choice to me. I'm particularly interested in how it impacts XAF and XPO. Thanks for sharing this info.

11 July, 2018

You have my approval

11 July, 2018
Paul Fuller

I have no issue and fully support the move.

11 July, 2018
Manuel 1814

It's definetly time to move forward. I don't think that living in the past forever will help anybody. I usually tend to upgrade to newer versions very fast, because with the latest movement on C#'s side lots of work can be leveraged by using newer language features. I never experienced any issues with that, so I'm happy would you finally move to more up-to-date tech.

11 July, 2018
Michael D.

This is great news and have our full support!!!

To use a famous quote :

“There are far, far better things ahead than any we leave behind. ” — C.S. Lewis

11 July, 2018
Andrew Fraser

Makes perfect sense to me - I am behind the move 100%

11 July, 2018
James Baker

Great news! Looking forward to 18.2!

12 July, 2018

This is welcome news!

12 July, 2018
cedrus bank

We are always looking forward for newer versions of anything, whether .NET, Visual Studio, SQL Server or DevExpress.

Moving into newer versions is always welcome and recommended by our side.

The moment you guys post a minor or major version update, we rush to get the update because we believe that newer is always better.

12 July, 2018
Jesper Nørregaard

Great seeing you leave the past behind!

... Personally I would have no problem if you went even further...

Please share your thoughts on not moving to .net framework 4.6.2 and c#7

(too little benefits vs. too many customers still using the older versions?)

12 July, 2018
Peter Bossier

I fully agree. Although I'm on VS2017, I think it is a good option to still support VS2015. I know it is still used a lot.

12 July, 2018
Norbert K.

I fully agree: .NET v4.5.2, Visual Studio 2017 (Visual Studio 2015 can be skipped), and C# 6

12 July, 2018
Christopher Jay

Works for us.

12 July, 2018
Santiago Moscoso

I agree with the changes.

I see no mention of Visual Basic. Are you still supporting VB.NET?

Will you provide an upgrade tool for XAF workflows XML? They are different on .NET 4.0 than on .NET 4.5

12 July, 2018

Sounds good, no problem for me.

12 July, 2018
Robert Schlesinger

This move means also we have to move from Coderush Classic to Coderush for Roslyn.

Now I work both in VS2010 (means with CRC) and VS2017 (means with CRR) and even you try hard to improve CRR, still there are some CRC features missing in CRR.

I hope Coderush team will continue going ahead quickly to add missing features.

It would also make more sense to do such big moves with version X.1, means you could do with 18.1 or 19.1. Maybe the next time :)

Anyway I am also ok with to move to VS2017 as the others mentioned.

12 July, 2018
Markus Hastreiter

Seems absolutely reasonable and I support this decision. We are working with VS2017 and C# 7. We're currently targeting .Net 4.5.2, but are in the process of moving to 4.7.x.

So, moving to an even higher framework version than 4.5.2 would be fine for us as well.

12 July, 2018
Julian Bucknall (DevExpress)

@Santiago: Yes, we are still supporting VB.NET with our demo apps. However, we write all our framework and component code in C#, hence the discussion about which version of C# we'll use going forward.

Cheers, Julian

12 July, 2018
Julian Bucknall (DevExpress)

@Robert: Our intention is to move forward porting over features from CodeRush classic to CodeRush for Roslyn. Absolutely. I will say though (wink, wink) that if there are important features you'd rather see sooner than later, contact us.

Cheers, Julian

12 July, 2018
Dennis (DevExpress Support)

@Eric:  XPO-related details are already included in Julian's post. Let me know if you have any specific questions. As for XAF, I briefly described our thoughts on these here: We will also elaborate on near term tech matters on our XAF team blog once shortly.

12 July, 2018
Marcelo Paiva

Very good, I believe this is the best way. We have 3 applications with XAF / XPO and I imagine it would be good to have support for .Net Core.

12 July, 2018
Edhy Rijo

Hi Julian,

You said:

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

Can you please clarify if this change would mean that the latest version of DX that would be supported on XP is 18.1?  Even if the application is compiled using .Net 4.7?

12 July, 2018
Dennis (DevExpress Support)

@Santiago: We've not planned to create any migration tool for Windows Workflow Foundation (WF). This is not specific to our product directly, and you may look for migration guidelines from Microsoft. For instance:

We may provide a toggle similar to CanSetTargetFramework45 discussed at

As far as we know, the new WF designer or runtime can read old workflow definitions with no problem. The new WF designer or runtime may save workflow definitions incompatible with the old framework, though.

Please let me know if you have any specific requirements.

13 July, 2018
Joseph Kellerer 2

Imho you even can update to VS 2017 and .NET 4.6 or even 4.7

13 July, 2018
Mark Douglass

I think this is absolutely the right direction. If you want legacy support (i.e. XP), keep an older version of the components and dev environment in a separate VM that you can spin up (that's what we do). I love this move.

13 July, 2018
Uwe Porsch

I personally can live without XP but I now that still much people use ist. Customers with XP will maybe not upgrade to newer DevEX releases. So it's DevExpress thing wether they are willing to accept missing them. New version sometimes brings progress, so I'm fine.

13 July, 2018
A G 4

Good for me as long as examples and support is still available in VB.NET.

13 July, 2018
Paolo KALC

Great news! Looking forward to 18.2!

14 July, 2018
Tomas Homola

Great! I welcome async methods. We've already moved to .NET 4.6/4.6.1/4.6.2, C# 7+ and Visual Studio 2017

16 July, 2018
Baldur Fürchau

Concerning the Async/Await-Implementation i have recognized, that this works always with Task-Objects.

This Objects are depending on the available cpu's, so you can not have more active tasks than cpu's.

The same is the implementation of Parallel-Library (Parallel.ForEach/For).

If a Task have only calculations, than Task make sense because threads are not faster than tasks.

But you can start as many threads as you want, also as tasks, but tasks are pooled and will be started only, if cpu's are ready to execute.

So if i read a file or execute a SQL against a database with Asyn/Await, the Task will block any further Task on the same CPU until the result is available.

If i do the same in a thread, the thread can wait until the operation is finshed without blocking other threads or tasks.

I have checked the with Parallel-Linq, that uses the same technic with tasks.

On big data (1 million rows in core is not sooo big), i made a parallel aggregation on an I7 with 8 Groups and 10 Aggregates, that works fast and give me a result within 20 Seconds.

Now i need the same aggregates in an hierachie from group 1 to 8 and i have tested this to do also in an Parallel.ForEach. This slows down the inner parallel.linq from 20 seconds to 90 seconds.

So the time i need for 8 parallel aggregats is now 8 x 90 = 720 Seconnds!

In a sequential for 1 to 8 i need 8 * 20 = 160 Seconds.


So the async/await is a good feature to do some parallel calculations, also with Parallel-Library and Parallel-Linq.

If i deal with external resources (Files, Database, Network, ...) it is better to start a Thread instead of a Task or you must mark the Task as "LongRunning" to create more treads than available cpu's.

17 July, 2018
Ivan A

Good news. We are working with VS2017 and C# 7. We're currently targeting .Net 4.5.2, but moved to 4.6.2 of end year.

22 July, 2018
sun chao

Windows 7 must be supported.

lasted version of VS must be supported.

For others, I don't care.

22 July, 2018
Eaton Z.

.NET 4.5.2 is still pretty old.. I think you can get away with upgrading your components to a newer version. 😉

23 July, 2018
Randy Blackmond 3

I haven't created a new application based on anything older than 4.6.1 in over 2 years. The 4.5.2 version seems pretty old. I would say once the current version of Visual Studio has been available for a year, drop support for the previous version.  I understand you want to support your paying customers, but if the cost is to support something 2 years old, you might want to rethink.

4 September, 2018
Uwe Porsch

XP has still a high basis on installation and I do not believe that users will switch to a newer OS (especially if the alternative is Windows 10). So in my view for delvelopers with xp-customers  this would be a problem. And I believe this will not a small amount. For me it is not a problem. I generally having problems whith the saving costs argument. My expierence with cost savings in Company often comes with worther quality. I don't hope so with DevExpress.

11 September, 2018
Dave VanderWekke (Automated Wireless Environments)

Thank you for the well detailed write-up.  We have a few customers that are holdouts still running XP and Server 2003.  This is just the push we need to get them to upgrade but it also provides us with the leverage we need to get our own company's leadership to realize the need to get off of .NET 4.0 framework.

20 November, 2018
Paolo F.

C# 6, simplified API,

just curious: why use caller information instead of 'Nameof' to get property Name ?

13 May, 2019

Please login or register to post comments.