{"id":55320,"date":"2025-01-21T10:00:00","date_gmt":"2025-01-21T18:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=55320"},"modified":"2025-01-21T13:31:55","modified_gmt":"2025-01-21T21:31:55","slug":"introducing-winforms-analyzers","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/introducing-winforms-analyzers\/","title":{"rendered":"WinForms: Analyze This (Me in Visual Basic)"},"content":{"rendered":"

If you\u2019ve never seen the movie Analyze This<\/em>, here\u2019s the quick pitch: A member\nof, let\u2019s say, a New York family clan with questionable habits decides to\nseriously considers therapy to improve his mental state. With Billy Crystal and\nRobert De Niro driving the plot, hilarity is guaranteed. And while Analyze\nThis!<\/em> satirically tackles issues of a caricatured MOB world, getting to the\nroot of problems with the right analytical tools is crucial everywhere. All the\nmore in a mission critical LOB-App world.<\/p>\n

Enter the new WinForms Roslyn Analyzers<\/strong>, your domain-specific “counselor”\nfor WinForms applications. With .NET 9, we\u2019re rolling out these analyzers to\nhelp your code tackle its potential issues\u2014whether it\u2019s\nbuggy behavior, questionable patterns, or opportunities for improvement.<\/p>\n

What Exactly is a Roslyn Analyzer?<\/h2>\n

Roslyn analyzers are a core part of the Roslyn compiler platform, seamlessly\nworking in the background to analyze your code as you write it. Chances are,\nyou’ve been using them for years without even realizing it. Many features in\nVisual Studio, like code fixes, refactoring suggestions, and error diagnostics,\nrely on or even just are<\/em> Analyzers or CodeFixes to enhance your development\nprocess. They\u2019ve become such an integral part of modern development that we\noften take them for granted as just “how things work”.<\/p>\n

\"Screenshot<\/p>\n

The coolest thing: This Roslyn based compiler platform is not a black box.\nThey provide an extremely rich API, and not only Microsoft’s Visual Studio IDE\nor Compiler teams can create Analyzers. Everyone can. And that’s why WinForms\npicked up on this technology to improve the WinForms coding experience.<\/p>\n

It’s Just the Beginning \u2014 More to Come<\/h2>\n

With .NET 9 we\u2019ve laid the foundational infrastructure for WinForms-specific\nanalyzers<\/strong> and introduced the first set of rules. These analyzers are designed\nto address key areas like security, stability, and productivity. And while this\nis just the start, we\u2019re committed to expanding their scope in future releases,\nwith more rules and features on the horizon.<\/p>\n

So, let’s take a real look of what we got with the first sets of Analyzers we’re\nintroducing for .NET 9:<\/p>\n

Guidance for picking correct InvokeAsync Overloads<\/h2>\n

With .NET 9 we have introduced a series of new Async APIs for WinForms. This\nblog\npost<\/a>\ndescribes the new WinForms Async feature in detail. This is one of the first\nareas where we felt that WinForms Analyzers can help a lot in preventing issues\nwith your Async code.<\/p>\n

One challenge when working with the new Control.InvokeAsync<\/code> API is selecting\nthe correct overload from the following options:<\/p>\n

public async Task InvokeAsync(Action callback, CancellationToken cancellationToken = default)\r\npublic async Task<T> InvokeAsync<T>(Func<T> callback, CancellationToken cancellationToken = default)\r\npublic async Task InvokeAsync(Func<CancellationToken, ValueTask> callback, CancellationToken cancellationToken = default)\r\npublic async Task<T> InvokeAsync<T>(Func<CancellationToken, ValueTask<T>> callback, CancellationToken cancellationToken = default)<\/code><\/pre>\n
Each overload supports different combinations of synchronous and asynchronous\nmethods, with or without return values. The linked blog post provides\ncomprehensive background information on these APIs.<\/p>\n
Selecting the wrong overload however can lead to unstable code paths in your\napplication. To mitigate this, we\u2019ve implemented an analyzer to help developers\nchoose the most appropriate InvokeAsync<\/code> overload for their specific use cases.<\/p>\n
Here\u2019s the potential issue: InvokeAsync<\/code> can asynchronously invoke both\nsynchronous and asynchronous methods. For asynchronous methods, you might pass a\nFunc<Task><\/code>, and expect it to be awaited, but it will not. Func<T><\/code> is\nexclusively for asynchronously invoking a synchronous called method – of which\nFunc<Task><\/code> is just an unfortunate special case.<\/p>\n
So, in other words, the problem arises because InvokeAsync<\/code> can accept any<\/em>\nFunc<T><\/code>. But only Func<CancellationToken, ValueTask><\/code> is properly awaited by\nthe API. If you pass a Func<Task><\/code> without the correct signature\u2014one that\ndoesn\u2019t take a CancellationToken<\/code> and return a ValueTask<\/code>\u2014it won\u2019t be awaited.\nThis leads to a \u201cfire-and-forget\u201d scenario, where exceptions within the function\nare not handled correctly. If such a function then later throws an exception, it\nwill may corrupt data or go so far as to even crash your entire application.<\/p>\n
Take a look at the following scenario:<\/p>\n
private async void StartButtonClick(object sender, EventArgs e)\r\n{\r\n   _btnStartStopWatch.Text = _btnStartStopWatch.Text != \"Stop\" ? \"Stop\" : \"Start\";\r\n\r\n    await Task.Run(async () =>\r\n    {\r\n        while (true)\r\n        {\r\n            await this.InvokeAsync(UpdateUiAsync);\r\n        }\r\n   });\r\n\r\n   \/\/ ****\r\n   \/\/ The actual UI update method\r\n   \/\/ ****\r\n   async Task UpdateUiAsync()\r\n   {\r\n         _lblStopWatch.Text = $\"{DateTime.Now:HH:mm:ss - fff}\";\r\n         await Task.Delay(20);\r\n   }\r\n}<\/code><\/pre>\n
This is a typical scenario, where the overload of InvokeAsync which is supposed\nto just return something other<\/em> than a task is accidentally used. But the\nAnalyzer is pointing that out:<\/p>\n
\"Async<\/p>\n
So, being notified by this, it also becomes clear that we actually need to\nintroduce a cancellation token so we can gracefully end the running task, either\nwhen the user clicks the button again or – which is more important – when the\nForm actually gets closed. Otherwise, the Task would continue to run while the\nForm gets disposed. And that would lead to a crash:<\/p>\n
    private async void ButtonClick(object sender, EventArgs e)\r\n    {\r\n        if (_stopWatchToken.CanBeCanceled)\r\n        {\r\n            _btnStartStopWatch.Text = \"Start\";\r\n            _stopWatchTokenSource.Cancel();\r\n            _stopWatchTokenSource.Dispose();\r\n            _stopWatchTokenSource = new CancellationTokenSource();\r\n            _stopWatchToken = CancellationToken.None;\r\n\r\n            return;\r\n        }\r\n\r\n        _stopWatchToken = _stopWatchTokenSource.Token;\r\n        _btnStartStopWatch.Text = \"Stop\";\r\n\r\n        await Task.Run(async () =>\r\n        {\r\n            while (true)\r\n            {\r\n                try\r\n                {\r\n                    await this.InvokeAsync(UpdateUiAsync, _stopWatchToken);\r\n                }\r\n                catch (TaskCanceledException)\r\n                {\r\n                    break;\r\n                }\r\n            }\r\n        });\r\n\r\n        \/\/ ****\r\n        \/\/ The actual UI update method\r\n        \/\/ ****\r\n        async ValueTask UpdateUiAsync(CancellationToken cancellation)\r\n        {\r\n            _lblStopWatch.Text = $\"{DateTime.Now:HH:mm:ss - fff}\";\r\n            await Task.Delay(20, cancellation);\r\n        }\r\n    }\r\n\r\n    protected override void OnFormClosing(FormClosingEventArgs e)\r\n    {\r\n        base.OnFormClosing(e);\r\n        _stopWatchTokenSource.Cancel();\r\n    }<\/code><\/pre>\n
The analyzer addresses this by detecting incompatible usages of InvokeAsync<\/code> and\nguiding you to select the correct overload. This ensures stable, predictable\nbehavior and proper exception handling in your asynchronous code.<\/p>\n
Preventing Leaks of Design-Time Business Data<\/h2>\n
When developing custom controls or business control logic classes derived from\nUserControl<\/code>, it’s common to manage its behavior and appearance using\nproperties. However, a common issue arises when these properties are\ninadvertently set at design time. This typically happens because there is no\nmechanism in place to guard against such conditions during the design phase.<\/p>\n
\"Screenshot<\/p>\n
If these properties are not properly configured to control their code serialization behavior, sensitive data set during design time may unintentionally leak into the generated code. Such leaks can result in:<\/p>\n