Author: Edin Kapic

Microsoft has released version 0.29 of DevProxy, a command-line tool for simulating APIs. The new version includes AI support for configuring and using the tool.

DevProxy (formerly known as Microsoft 365 Developer Proxy) helps developers to add resilience to their API-related code by simulating a vast number of API and network behaviours. By default, the tool acts as a proxy that fails half the time. It can also simulate throttling, rate-limiting or slow API responses. It can be used to mock responses to specific APIs. Combined with dev tunnels CLI, a ngrok-like tool, it can also inspect cloud services communication to understand what messages are being passed in cloud calls.

To support DevProxy configuration using natural language, the development team has released a MCP server. It allows AI agents such as GitHub Copilot to automatically correctly configure DevProxy for user’s needs. The MCP is exposed via DevProxy Toolkit Visual Studio Code extension or via a standalone npm package called @devproxy/mcp.

DevProxy internally uses language models (LLMs) to generate OpenAPI or TypeSpec files from API call samples. In this release, the prompts that DevProxy uses are exposed in the prompt folder directory where DevProxy is installed. The prompts are saved in Prompty specification format.

The new version brings breaking changes that will require some adjustments for developers building DevProxy plugins. The new architecture uses a different base class coming from DevProxy.Abstractions assembly, with the standard plugins contained in the DevProxy.Plugins assembly.

For troubleshooting issues with the tool, this version includes categories for debug and trace messages, helping developers quickly identify where the error message is originating.

Lastly, when DevProxy is uninstalled, it automatically uninstalls the root certificate that’s installed for decrypting HTTPS traffic.

An updated DevProxy Toolkit extension for Visual Studio Code editor is released together with the tool.

DevProxy is an open-source project on GitHub and a new member of the .NET Foundation non-profit organisation. The complete release notes for this version are available on the site. There are 26 contributors and 53 open issues at the moment. The project has been starred 676 times.

Microsoft has announced experimental support for .slnx files in the .NET CLI v9.0.200, unifying the developer experience among the .NET tooling. This new feature aims to remove clutter in the solution file and to reduce friction when working with large solutions.

Traditionally, .sln files have been the standard for Visual Studio solutions, but they come with limitations such as manual maintenance of project references and path dependencies, difficult merging of source code changes, and overall verbosity, as can be seen in this example:

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 17
VisualStudioVersion = 17.9.34511.98
MinimumVisualStudioVersion = 10.0.40219.1
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "DotNetMonitorWebApp", "DotNetMonitorWebAppDotNetMonitorWebApp.csproj", "{1385B389-B20C-4D19-8FE0-85629BC41343}"
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Any CPU = Debug|Any CPU
Release|Any CPU = Release|Any CPU
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{1385B389-B20C-4D19-8FE0-85629BC41343}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{1385B389-B20C-4D19-8FE0-85629BC41343}.Debug|Any CPU.Build.0 = Debug|Any CPU
{1385B389-B20C-4D19-8FE0-85629BC41343}.Release|Any CPU.ActiveCfg = Release|Any CPU
{1385B389-B20C-4D19-8FE0-85629BC41343}.Release|Any CPU.Build.0 = Release|Any CPU
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
GlobalSection(ExtensibilityGlobals) = postSolution
SolutionGuid = {C12E911E-FAA3-4ACE-B6BF-C3605E866483}
EndGlobalSection
EndGlobal

The new .slnx format, based on XML and introduced in 2024, provides a more robust and flexible alternative, similar to project files in Visual Studio. It has a minimal footprint, removing the duplication of information already present in the project files. It uses a human-readable format that reduces the chances of accidental errors when manually editing the solution file.

MSBuild already fully supports the .slnx format since version 17.13. The experimental support for .NET CLI in version 9.0.200 allows developers to use .slnx files directly with dotnet commands (e.g., dotnet build, dotnet test). Visual Studio support for the new format might require developers enabling the ‘Use Solution File Persistence Model‘ option listed under Environment / Preview Features.

A new dotnet command called migrate helps developers convert their .sln files into .slnx files. Alternatively, from Visual Studio developers can right-click the solution node in the Solution Explorer and save the solution in the new format (if enabled in the preview options). The official recommendation is to keep either .sln or .slnx file, but not both of them in the solution folder.

The .slnx file format is still officially in preview, with Microsoft encouraging developers to try the new format in their workflows and sharing their feedback with the appropriate tooling team owners. The stated goal is to make the new format the default in both Visual Studio and the .NET CLI tool. According to Microsoft, the new format will also work with legacy .NET Framework solutions.

Microsoft has also released a library called Microsoft.VisualStuidio.SolutionPersistence that allows programmatic access to both .sln and .slnx file operations. This allows third-party tools to leverage the new solution format without having to create a parser for it.

The comments by the developer community are mixed. Some praise the new format for simplicity and straightforward migration. Other developers think that new features such as globbing (dynamic project discovery inside a folder tree) should be added to the new format.

Microsoft’s latest ASP.NET Core 10 Preview 2 release from March 18th introduces targeted improvements to Blazor’s navigation behavior, OpenAPI documentation generation, and developer tooling, addressing community feedback. The update focuses on small enhancements rather than new features, refining existing capabilities ahead of .NET 10’s stable release later this year.

The most relevant change in Preview 2 is the revamping of the navigation system in Blazor to eliminate jarring user experience issues. When using NavigateTo for same-page navigations (e.g., query string updates), the browser will no longer forcibly scroll to the top. In previous versions, this was a behavior that developers had to work around manually.

The NavLink component also sees improvements, now ignoring query strings and fragments by default when matching using NavLinkMatch.All. This means a link will be active even if the query strings or fragments in the URL change. An AppContext switch reverts to the legacy behavior for teams needing backwards compatibility. For custom matching behaviour, NavLink now exposes an overridable ShouldMatch method.

Blazor’s reconnection UI, visible when the client loses WebSocket connection to the server, receives structural upgrades in the project template, with a new ReconnectModal component that separates CSS and JavaScript for stricter Content Security Policy (CSP) compliance. A custom components-reconnect-state-changed event provides finer-grained control over connection states, including a new “retrying” phase.

API developers gain built-in support for propagating XML source code comments into OpenAPI documents. The feature requires enabling documentation file generation in the project file (GenerateDocumentationFile property) and moves comment processing to compile time via a source generator. However, minimal API endpoints must now use named methods rather than lambdas to leverage this feature, which can be seen as a trade-off for better discoverability.

The underlying OpenAPI.NET library is updated to version 2.0.0-preview7, introducing breaking changes for advanced users. Schema definitions now use interfaces, and the Nullable property for the schema is replaced with JsonSchemaType.Null checks.

The Preview 2 also introduces minor quality of life improvements:

• Blazor QuickGrid control adds a CloseColumnOptionsAsync method for programmatically dismissing column menus, simplifying filter interactions.
• Form binding now treats empty strings as null for nullable types, matching minimal API behavior elsewhere.
• New authentication metrics for Aspire dashboard track sign-in/sign-out events and authorization attempts, while request duration telemetry helps identify performance bottlenecks.

Preview 2 is available now via the .NET 10 Preview SDK. Developers should test navigation changes and OpenAPI integration, with particular attention to the breaking schema modifications. The team expects the .NET 10 to be released around November 2025.

The latest version of OpenSilver 3.2, a remake of Microsoft’s retired Silverlight web application framework, extends the platform to mobile devices using a .NET MAUI Hybrid approach.

OpenSilver was launched in October 2021 by a French company, Userware. It is an open-source, MIT-licensed reimplementation of Silverlight. OpenSilver compiles .NET and XAML code into HTML5 and WebAssembly, reimplementing standard and selected third-party controls. It allows developers to reuse their legacy Silverlight or XAML applications instead of rewriting them. The latest update to OpenSilver was version 3.1 in December 2024, with a Visual Studio Code XAML designer and modern themes for the UI.

Until now, OpenSilver focused on WPF and Silverlight code parity on modern browsers. In version 3.2, there are new project templates featuring .NET MAUI hybrid applications. In these applications, there is a native app container for every platform that hosts the native WebView, which runs the OpenSilver application.

The benefits for the developers include maintaining a single codebase, with a consistent UI on all platforms. Native apps can use their platform APIs in the OpenSilver applications. Lastly, native apps are packaged and distributed on the app stores, making it easier for users to find them. The included ToDoCalendar sample application that illustrates how cross-platform OpenSilver works was ported from the app initially written for the defunct Windows Phone.

Right now, the supported platforms for .NET MAUI hybrid OpenSilver applications are iOS, Android, Windows, macOS, web browsers and Linux (using Photino, a native Linux framework using web technologies).

When asked how have developers received OpenSilver, Giovanni Albani, Userware founder and CEO answers:

The reception has been remarkably positive, particularly among enterprise development teams with significant WPF investments. We’ve seen adoption across finance, healthcare, and manufacturing sectors, where preserving complex business logic while expanding platform reach is essential. What resonates most with businesses is the cost-effectiveness of modernizing existing applications without rebuilding from scratch, while leveraging their teams’ existing C# and XAML expertise. Microsoft’s recommendation of WPF for new desktop application development has reinforced this interest. Interestingly, new generations of developers are discovering WPF through OpenSilver and finding its capabilities impressive. They appreciate that it’s a stable, well-documented platform with abundant samples and tutorials.

Other features in this release include a couple of updates for WPF compatibility, such as improved event bubbling (matching behaviour present in WPF) and support for RTL languages. The company intends to further improve WPF code compatibility in future releases. Additionally, the XAML editor previously available for Visual Studio Code is now available for Visual Studio 2022.

According to Giovanni Albani, (the) XAML visual editor for VS Code generated particular excitement in the developer community, with its Reddit announcement garnering over 100,000 views and more than 120 comments.

The OpenSilver source code is available on GitHub. The repository containing OpenSilver has 1067 stars and has been forked 122 times. Beyond the Userware developer team, there are other active contributions to the project, with a total of 47 contributors. According to the OpenSilver website, companies that rely on this framework include Bayer, TATA, KPMG, and others.

Fluent Assertions, a well-known .NET library that allows expressive asserts in unit tests, has launched version 8 with a proprietary license in partnership with Xceed, replacing the existing Apache 2.0 licence. The new license allows free non-commercial use, but any commercial use will require a paid license. The move has been negatively received by the developer community.

On January 13th 2025, Xceed Software published a notice of partnership with Fluent Assertions, where “Fluent Assertions will be integrated into (Xceed’s) suite of development tools”. The notice mentioned that the library will be licensed under a paid Xceed commercial license, but will continue to honour free licenses for open-source and non-commercial projects.

Xceed Software is a Canadian .NET component provider, with UI controls and other helper libraries such as .ZIP format tooling. Fluent Assertions is now shown as a library offered with a commercial license and support on the company website. The license for a single developer seat is stated to be 129.95 USD per year.

At the same time, the previous major version of the library, v7, will be kept “indefinitely” under its existing Apache license, allowing for free use in any kind of project, commercial or not.

Fluent Assertions was created by Denis Doomen, a Dutch developer, with the first version dating back to 2010. Since 2018, Jonas Nyrup, a Danish developer, has joined Denis in maintaining and evolving the library. Fluent Assertion is one of the most popular libraries in the .NET space, with over 450 million downloads on NuGet. It allows for more natural specification of asserts in unit tests, reading almost like a sentence in English.

string actual = "ABCDEFGHI";
actual.Should().StartWith("AB").And.EndWith("HI").And.Contain("EF").And.HaveLength(9);

The license change in v8 has led to a strongly-worded exchange on the project GitHub pull request comments. Developers argue that the price tag for the library is excessive, given its nature as a syntactic sugar for unit tests. Other developers think that maintaining all prereleases of the v8 under the existing Apache license while changing it to a proprietary license in the final pull request was a bad-faith move by the library maintainers. While the previous Apache 2.0 license allows derivative works with a different license, there are opinions among the developers that the change is against the license’s terms.

Some developers have mentioned that this move is reminiscent of other .NET ecosystem libraries that moved to commercial licenses, like the .NET drawing library ImageSharp or the Excel formatting library EPPlus.

Developers wanting to stay on the v7 branch should block the major version number in their .csproj file using a bracketed version tag to ensure that a package update doesn’t inadvertently put them in breach of the new license model.

One Fluent Assertions user has created a fork with the pre-release code of the library, still under the original license, with a new name of AwesomeAssertions. It is to be used as a direct replacement for current features only, without any evolution.

Alternatively, developers can remove the dependency on Fluent Assertions and use a similar library called Shouldly. There is an onboarding guide to Shouldly for Fluent Assertions users.

Microsoft released version 8.1 of the Windows Community Toolkit in August 2024. The new release has updated dependencies, .NET 8 support, two new controls and several changes to existing controls and helpers.

The Windows Community Toolkit (WCT) is a collection of controls and libraries that help Windows developers by providing additional features that the underlying platform doesn’t yet offer. Historically, the features provided by the toolkit were gradually incorporated into the Windows development platform itself.

The Windows Community Toolkit is not to be confused with the .NET Community Toolkit (NCT), which contains the common features of WCT that aren’t tied to any underlying UI platform.

There are no major changes in version 8.1. The most important ones are the updated dependencies and the older NuGet package redirects.

The dependencies of the toolkit are now updated to the latest versions, Windows App SDK 1.5 and Uno Platform 5.2. The minimum Windows target version is bumped to version 22621. This move allows WCT consumers to target .NET 8 features in their apps.

When WCT 8.0 was released last year, namespaces were rationalised to remove redundancies. In version 8.1, there are NuGet package redirects to point the code targeting version 7.x of the toolkit to the equivalent namespaces in version 8.x. For example, Microsoft.Toolkit.Uwp.UI.Controls.Primitives will now redirect to CommunityToolkit.Uwp.Controls.Primitives.

Beyond the new dependencies and package redirects, there are several new features in the updated version. The most prominent ones are the ColorPicker and the ColorPickerButton controls. They were previously available in WCT 7.x and now are ported back again with Fluent WinUI look-and-feel and several bug fixes.

Another control ported from version 7.x is the TabbedCommandBar. It has been also updated with new WinUI styles and a bug regarding accent colour change was fixed in this new version.

Minor fixes in version 8.1 include making camera preview helpers work with Windows Apps SDK, support for custom brushes to act as overlays for ImageCropper control, and new spacing options for DockPanel control.

The migration process for the users of the older 7.X version of the WCT involves updating the TargetFramework property in the .csproj file and the publishing profile to point to the new version of Windows SDK.

Microsoft recommends developers check and contribute to the Windows Community Toolkit Labs, a repository for pre-release and experimental features that aren’t stable enough for the main WCT repository. Still, the issue of several controls dropped in the move from version 7 to version 8 of the toolkit is a source of frustration for WCT developers.

Version 8.1.240821 was pre-released on June 6th 2024 and released for general availability on August 22nd 2024. The source code for the toolkit is available on GitHub.

Microsoft released a CoreWCF service library and a WCF client library with the bindings for Azure Storage Queue. The new bindings allow developers to use Azure Service Queues for reliable and scalable messaging solutions. They also unlock simple migration of legacy Microsoft MSMQ WCF solutions to an Azure cloud-based architecture.

The Azure Storage Queue is a cloud-based queue service built on top of Azure Storage that allows any components to send, store and receive messages reliably and asynchronously.

It is worth clarifying that the Azure Storage Queue binding in CoreWCF, like the legacy MSMQ (Microsoft Message Queuing) binding, is a one-way operation, meaning the client gets no response for the service invoked via the binding. Consequently, only void methods are allowed in the CoreWCF service interface. The MSMQ support in CoreWCF remains in the preview stage, and it has been in development for over a year.

There are two packages for Azure Storage Queue support: one for the client scenario (sending messages to the queue) and one for the server scenario (reading the messages from the queue and processing them). The Azure Storage Queue client library and Azure Identity library are pulled together with the packages as a dependency. There is a sample of the usage of the new bindings on the Azure SDK for .NET GitHub account.

The bindings are released by the Azure SDK for .NET team and not by the CoreWCF team. Also, the client library is released as a .NET package compatible with the Windows-only .NET Framework WCF stack. The stated goal of the packages is to enable migrating existing WCF clients to .NET that are currently using MSMQ and wish to deploy their service to Azure, replacing MSMQ with Azure Queue Storage.

To call an Azure Storage Queue using CoreWCF or WCF, the developers must add Microsoft.WCF.Azure.StorageQueues prerelease NuGet package to their .NET project. The first step is to authenticate the client that is calling the Azure Storage Queue. The default mechanism is to leverage the DefaultAzureCredential provider using a parameterless constructor for AzureQueueStorageBinding. The queue address is passed to the CoreWCF’s regular ChannelFactory class to create a communication channel for the service that will be invoked.

// Create a binding instance to use Azure Queue Storage.
// The default client credential type is Default, which uses DefaultAzureCredential
var aqsBinding = new AzureQueueStorageBinding();

// Create a ChannelFactory to using the binding and endpoint address, open it, and create a channel
string queueEndpointString = "https://MYSTORAGEACCOUNT.queue.core.windows.net/QUEUENAME";
var factory = new ChannelFactory(aqsBinding, new EndpointAddress(queueEndpointString));
factory.Open();
IService channel = factory.CreateChannel();
channel.Open();

// Invoke the service
await channel.SendDataAsync(42);

To create a CoreWCF service that will be exposed as a consumer of the Azure Storage queue, developers have to use Microsoft.CoreWCF.Azure.StorageQueues prerelease NuGet package. The process of creating the service binding starts with adding the queue transport to the CoreWCF services collection in the service configuration step. In the app builder configuration step, the binding itself is constructed. Then, the service is connected to the queue using the AddServiceEndpoint method, passing the instantiated binding and specifying the queue address.

public class Startup
{
  public void ConfigureServices(IServiceCollection services)
  {
    services.AddServiceModelServices();
    services.AddQueueTransport();
  }

  public void Configure(IApplicationBuilder app, IHostingEnvironment env)
  {
    app.UseServiceModel(services =>
      {
        serviceBuilder.AddService ();
        var aqsBinding = new AzureQueueStorageBinding();
        string queueEndpointString = "https://MYSTORAGEACCOUNT.queue.core.windows.net/QUEUENAME";
        serviceBuilder.AddServiceEndpoint  (aqsBinding, queueEndpointString);
      });
  }
}

Although these examples use the default Azure authentication, the binding library allows for the use of either a storage shared key credential, a SAS (shared access signature), an OAuth token or an Azure Storage connection string. There is a Security.Transport.ClientCredentialType option in the AzureQueueStorageBinding class to specify these settings.

The CoreWCF project was officially released in April 2022, although it had already begun in 2019. It aims to provide a subset of the most frequently used functionality from WCF service on the .NET platform. It is .NET Standard 2.0 compatible, allowing it to be migrated in place on .NET Framework 4.6.2 or above. It covers HTTP and TCP transport protocols with mainstream WCF bindings and other protocols such as Kafka or RabbitMQ. The current version is 1.6.0.

The Azure Storage Queue binding support for CoreWCF comes almost a year after the AWS team released a similar package supporting AWS SQS (Simple Queue Service) queues.

The long-term-support (LTS) version 6 of Microsoft .NET Framework is slated to go out of support on November 12, 2022. Microsoft recommends upgrading .NET 6 applications to .NET 8 to stay supported for the future.

Microsoft .NET Framework version 6, released in November 2021, is approaching the end of its support date. According to Rahul Bhandari, program manager at Microsoft .NET team, customers using version 6 should move to .NET 8 to still receive official support and security patches.

Mr. Bhandari explains that the .NET 6 applications will still run after the end of support date, but that customers can be exposed to potential security flaws that will be patched only for supported versions.

Version 6 is what Microsoft calls a long-term-support (LTS) release, having a support lifecycle of three years since the release date. Non-LTS (or “current”) releases, such as .NET 7, have a shorter support lifecycle of 18 months, as Microsoft will support them for six months after the release of the next LTS version. Microsoft schedules .NET versions to launch one major version of .NET a year, alternating between LTS and current versions.

The latest LTS version of .NET is 8, which Microsoft plans to support until November 2026. Microsoft expects to release .NET 9, a non-LTS version, in November 2024, meaning that the current .NET 6 customers can choose between upgrading to .NET 8 or 9 when version 6 support ends. .NET version 7 already went out of support in May 2024.

Upgrading to .NET 8 involves a change of one line in the project file to change the target framework version. However, there might be runtime or source-code incompatibilities between .NET 6 and .NET 8.

Microsoft recommends that developers check the official compatibility guide for any issues when upgrading their applications and provides an open-source upgrade tool called upgrade-assistant. The tool analyses the application code, updates the project files, checks for breaking changes, and does some automatic code fixes – but developers will still have to do some manual fixes.

The developer community’s reactions on social networks are mixed.In this Reddit thread some developers think that the speed of releases is too fast and that the “short overlap (of versions) is ridiculous”, while others argue that “taking a day to update to a new LTS every two years is hardly a scary prospect”.

Microsoft regularly publishes summarised telemetry information derived from the usage of .NET SDK. According to the data for May 2024, the most used version of .NET Framework for applications is precisely the .NET 6, accounting for 39% of the telemetry data, with .NET 8 being second with 26% of the installations.

The latest version of OpenSilver 2.2, a remake of Microsoft’s retired Silverlight web application framework, includes support for migrating applications created with Visual Studio LightSwitch that targeted Silverlight.

OpenSilver was launched in October 2021 by a French company, Userware. It is an open-source, MIT-licensed reimplementation of Silverlight. OpenSilver compiles .NET and XAML code into HTML5 and WebAssembly, reimplementing standard and selected third-party controls. It allows developers to reuse instead of rewriting their legacy Silverlight or XAML applications. The latest update to OpenSilver was version 2.1 in February 2024, with the support for F# language.

Visual Studio LightSwitch was a framework for the rapid creation of business data-centric applications with visual drag-and-drop designers and support for C# and XAML. It was programmed with data-access abstraction via Entities and used the Model-View-ViewModel (MVVM) paradigm for the UI. It would generate a Silverlight application as an output. With the demise of Silverlight, the only available alternative for developers would be to rewrite their existing LightSwitch applications.

OpenSilver 2.2 can now migrate LightSwitch applications without changing the code. The generated files for the LightSwitch project can be imported into an empty OpenSilver project. By referencing a NuGet package called “LightSwitch Compatibility Pack”, the original application files will be compiled into static HTML and JS files. This NuGet package is licensed, and the developers can sign up for a trial.

To illustrate the migration, Userware migrated a sample LightSwitch application to the OpenSilver version that can be run in the browser without a Silverlight plugin. The source code for both applications is available on GitHub.

For the moment, the migration doesn’t allow the modification of screens created by LigthSwitch. The developers have to make the change in LightSwitch and import the application files again into the OpenSilver project. The interactive editor is on the OpenSilver roadmap.

The reactions from developers have been generally positive. On Reddit, a corporate user called Yukti_Solutions says that “massive selling points are the cost savings plus the fact that migrated apps still work and look the same”.

The OpenSilver 2.2 press release states that the roadmap will include a WYSIWYG XAML designer with full drag-and-drop support, as current support is limited to rendering the XAML in the Forms Designer. Future support for .NET MAUI, XAML Hot Reload, macOS, VS Code and Rider are mentioned, too.

The OpenSilver source code is available on GitHub. The repository containing OpenSilver has 928 stars and has been forked 115 times. Beyond the Userware developer team, there are other active contributions to the project, with a total of 48 contributors. According to the OpenSilver website, companies that rely on this framework include Bayer, TATA, KPMG, and others.

On March 29th, 2024, Microsoft released version 8.0.0 of their open-source MAUI Community Toolkit. The new version adds touch animation behavior, a rewritten Snackbar component and many bug fixes.

.NET MAUI Community Toolkit (NMCT) is one of Microsoft’s .NET community toolkits hosted on GitHub, covering the MAUI developers. Their purpose is to let the community contribute useful code missing from official frameworks. The community toolkits are released as open-source software, and they encourage the developers to submit their contributions. Some toolkit additions can be later promoted into the official Microsoft libraries.

MAUI is an acronym that stands for Multiplatform Application UI. According to Microsoft, it’s an evolution of Xamarin and Xamarin Forms frameworks, unifying separate target libraries and projects into a single project for multiple devices. Currently, MAUI supports writing applications that run on Android 5+, iOS 11+, macOS 10.15+, Samsung Tizen, Windows 10 version 1809+, or Windows 11.

The previous major version of NMCT, 7.0.0, was launched concurrently with the .NET 8 official launch, in November 2023. The version 8.0.0 comes four months later.

The big new feature in the new version is the availability of TouchBehavior. It is a declarative ability to interact with a visual element, based on a touch or a mouse event. In the Xamarin cross-platform library, deprecated and with the official end of life slated for May 1st 2024 , it was known as TouchEffect. The NCMT team ported it from the Xamarin Comunity Toolkit to the .NET MAUI Community Toolkit.

Another change is the Snackbar component, which represents a notification on the lower edge of the screen. It has been completely rewritten. For Windows developers, there is a breaking change that requires component preparation in the package.xappmanifest file and the MauiAppBuilder class. Other platforms don’t require any additional steps.

The navigation bar on the Android platform now supports changing the color and the light/dark style.

Among the rest of the fixes in this release, there are several regarding the Popup control: fixing the size and position on Android, gesture support for size change on iOS, and fixing the active window popup detection on Windows.

The .NET MAUI Community Toolkit is versioned in different releases, frequently updated. The toolkit versions evolved from 3.1.0 in January 2023 to 8.0.0 in March 2024. The reason for this multiplicity of version numbers is the presence of breaking changes, which force a major version number increase. Microsoft acknowledged the progress and the acceptance of the toolkit with a mention on their .NET developer blog.

The updated documentation for the .NET MAUI Community Toolkit is available on the Microsoft Learn website. The project repository is hosted on GitHub and currently has 108 open issues.