June 2010 - Posts

WinForms issue with Windows 10, version 1803

One of our customers has reported to us a issue with our WinForms controls, one that is related to a GDI resource leak. In their case, it caused an application crash – their system has a limit on how many GDI objects can be allocated.

Upon investigation by the team it turns out that the leak is related to Windows 10 version 1803 (also known as the Windows 10 April 2018 Update), or later.

We devised a really simple test to reproduce the issue:

private void button1_Click(object sender, EventArgs e) {
  for(int x = 0; x < 100; x++) {
    using(var f = new Form() { ShowInTaskbar = false }) {

This particular nasty piece of code – I don’t advise you use it in production! – will “leak” 300 GDI objects, since each form created with ShowInTaskbar = false will leak 3 GDI objects. It’s a very common scenario to have such an option turned on (all popups, tooltips, menus, drag-n-drops, alerts, etc. are examples of such forms), and if the application has a relatively complex UI and is run continuously, sooner or later it will crash or freeze.

We have already devised a workaround for this issue. Needless to say, some rigorous testing is currently being done to make sure we don’t break anything else. We shall be updating our WinForms components from v17.1 or later to include it.

We are contacting Microsoft to see if they aware of the issue, and trying to determine if they have any timeframe for a proper fix.


UPDATE (3-Aug-2018)

It seems I could have been a little more forthcoming and descriptive in my original post, so let me expand a little more. I will also stress that this issue is not specific to DevExpress, but is an “artifact” of the .NET Framework.

Basically the only applications that are really affected are those which use a dynamic UI – that is, apps that create and destroy new forms rather than reuse them (so for example, an invoice/order form where when you create the data entry UI every time the user wishes to enter a new record) – or an app which creates, say, lot of visual notifications.

Since it affects all forms which have ShowInTaskbar = false,  it does apply to almost every one of our UI controls – but I hasten to add that this setting is common practice, and not something we invented here at DevExpress.

Every “dropdown” window is created on the fly in a similar fashion. Examples include: combobox edits, popup menus, lookup edits, backstage menu, filter popups, alert windows, tooltips, drag & drop features, and so on. When you use such editors/controls in a form, a GDI object leak will occur. Now, as it happens, we coded things in such a way to reuse most of these window objects, so if you open the same popup 10 times, say, a leak will occur only once. But if you created a form that contains a combobox 10 times and each time that form is used the user opens the combobox, the app will have leaked 30 GDI handles.

I’d have to say though, since Windows 10 does have a relatively high GDI object limit, the average app would need to be running continuously for a pretty long time before it suffers from a lack of GDI resources.

You can monitor GDI object usage for your apps yourselves: open the Windows Task Manager, go to the Details pane, right-click on the column header row, and choose Select columns. One of the columns is called GDI objects. Select that check box and click OK.

Task Manager GDI object count

Start up your app and watch that new column as you use the UI, especially those forms with examples of those “dropdown” controls I mentioned.

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

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 https://support.microsoft.com/en-us/help/17455/lifecycle-faq-net-framework). 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 (management@devexpress.com) or myself (julianb@devexpress.com).


Build2018: WinForms and .NET Core 3 announcement

Yesterday, both as part of the general Microsoft Build announcements and a blog post from the .NET team, there was a fairly momentous announcement about the proposed .NET Core 3.

In brief, among a bunch of other features, .NET Core 3 will also come with “Desktop packs” for Windows development. These packs will target individual run-times, the main ones being WinForms and WPF, and, unlike .NET Core, will only work on Windows. However, instead of using the full .NET Framework, they will instead use .NET Core. I heartily recommend going to read that blog post for more details.

What I want to do here is to quickly address a couple of questions that you, our customers, may have.

First: this is just an announcement at this particular stage. The first beta release for this is slated for later on in the year, in the autumn, with a possible release of the finished framework in 2019.

Second: we do not have any bits from the .NET team as yet; we heard about this at exactly the same time as everyone else. At this stage, we really cannot comment on how much work would be required to ‘port’ our current set of WinForms and WPF controls over to these new Desktop packs. (I’m reminded as to how long it took Microsoft to get a semi-workable System.Drawing in ASP.NET Core so that we could finally add some kind of export facility.) Or even, to be brutally honest, whether it will be advantageous for us to do so. Remember that the Desktop packs will only work on Windows, this is not a universal panacea to create, say, Mac apps using WinForms.

Third: another part of the announcement was adding the ability for UWP controls to work in a WinForms or WPF app. Again, we can’t profitably promise anything about this until we have the beta.

So, in summary, we’re intrigued, we’ll wait until we have a workable beta, and then experiment and make our decisions. Stay tuned!

Microsoft Build is coming…

…and we shall be there in the hip DevExpress booth.

I’m certain that if you are a developer that uses anything in the Microsoft stack (Azure, Windows, Visual Studio, VSCode) to any great degree, you will know that next week is the week of the Microsoft Build developers’ conference in “sunny” Seattle. May 7th to the 9th, inclusive, to be precise. And, yes, Developer Express will be there with their booth, ably hosted by Amanda; with technical evangelists Areg and Mehul, who really know their stuff and who are ready to discuss your use of our products, and demo our controls and widgets; and … me. I’m pretty good at tidying up the booth and folding the <cough> Eat, Sleep, BUILD <cough> t-shirts we’ll be giving away as swag.

So, if you’re going to Build, please do come on over to the exhibit hall, and specifically to our booth (E24 near the Client and Web area on the expo floor). Come have a chat about your projects, development issues, and to hear how we could help you. Of course, we’ll have some news about our first main major release of 2018 (it’s close!). And did I mention the t-shirts?

We look forward to seeing you there!

DevExpress Roadmap for 2018

Back at the end of 2017, we held a series of four webinars over four days to describe the features and enhancements we were considering for our products in 2018. As a part of that, we sent out a survey to selected users so that they could review those plans and vote on them. This way, we can ascertain what aspects of our roadmap for 2018 our customers are most interested in and thereby direct and focus our development efforts to fulfill those needs.

RateItOur official 2018 roadmap is now live on DevExpress.com for all active customers. You will need to login to our site, and then you can use the links below to review our plans for this year's two major release cycles and tell us what you think of the features we have planned for each platform.

Before I list the platforms and the links though, I must stress the following:

This roadmap is for informational purposes only. You should not rely upon it for major purchase or product planning decisions/commitments. Just like all software development projects, products/features in this roadmap are subject to change or delay, with or without notice. The development or release of a specific feature or product listed on this roadmap is at the sole discretion of Developer Express Inc.

I would strongly encourage you to vote on the features we describe in the roadmap for the platforms you are interested in. If you don’t, we won’t know what you want us to focus on! (And the teams will go off and do something else – a ToDo List control anyone?)

Of course, if you have feedback about the roadmap and would rather contact me directly, I would be delighted to hear from you. My email address is below.

More Posts