Prism (PrismLibrary/Prism): a XAML MVVM framework with a dual licence and per-platform releases

What Prism solves, and who it is actually for

Prism targets a specific kind of application: a XAML desktop or cross-platform app that has grown past a single window with a code-behind file. The README describes it as a framework for building loosely coupled, maintainable and testable XAML applications, and lists the patterns it implements: MVVM, dependency injection, commands and EventAggregator. Those are the four things teams usually hand-roll badly. MVVM without a framework means every view model wires its own bindings and its own navigation. Dependency injection without a framework means either a service locator or a constructor graph nobody wants to maintain. Commands and cross-module messaging are the parts that quietly turn into static event handlers.

The audience is narrower than the description suggests. This is for .NET developers already committed to a XAML UI stack: WPF, Avalonia, .NET MAUI, Uno Platform or WinUI. If your application is a console tool, a web API or a Blazor app, the framework has nothing to offer you, because its value is in the integration between the patterns and the target platform's navigation and view resolution. The README is explicit that platform-specific behaviour lives in the per-platform libraries, not in the shared core.

One design decision worth noting early: Prism's core functionality is a shared code base supported on .NET Standard 2.0, .NET Framework 4.6 and 4.7, and .NET 6.0 and .NET 8.0. That is a wide net, and it is a deliberate constraint. It means the core cannot use newer runtime features, and it means a team on .NET Framework 4.6 gets the same abstractions as a team on .NET 8.

How the core, the containers and the platform libraries fit together

The architecture visible in the README is a three-layer split. At the bottom is a cross-platform core: Prism.Core, Prism.Events and Prism.Container.Abstractions. These are the shared abstractions, and the README calls them the base packages together with Prism's Core assembly as a cross-platform PCL.

The middle layer is the container. Prism does not ship its own IoC container. It ships adapters: Prism.Container.DryIoc and Prism.Container.Unity are listed as cross-platform packages, and each supported container has its own package assisting in the setup and usage of that container together with Prism. The naming convention is given directly: Prism.*Container.Platform*.dll, with Prism.Unity.Wpf.dll as the example. This is the detail that trips people up on a first install. Since version 7.0, Prism moved to separate packages for each platform, so you install two packages, not one.

The top layer is the platform library: Prism.Wpf, Prism.Avalonia, Prism.Maui, Prism.Uno. These hold the parts that must be platform specific, and they are where the framework meets the UI framework's own navigation and view model resolution. The README states that separate releases are available for each platform and that those will be developed on independent timelines. That sentence has operational consequences. A fix in the Avalonia package does not imply a matching release in the MAUI package.

The repository layout reflects the same split. The solution filters are per platform: PrismLibrary_Avalonia.slnf, PrismLibrary_Core.slnf, PrismLibrary_Maui.slnf, PrismLibrary_Uno.slnf, PrismLibrary_Wpf.slnf, with PrismLibrary.slnx as the full solution. The CI workflows follow suit, with separate build jobs for core, WPF, Avalonia, Uno and MAUI. If you plan to contribute a fix, expect to work inside one of these filters rather than the whole solution.

Installing Prism and wiring a first WPF shell

Prism is distributed on NuGet, and the README states that official Prism releases are available there. Because of the container and platform split, a WPF application using Unity needs the container-specific WPF package rather than a single monolithic one. The README gives the naming convention as Prism.*Container.Platform*.dll and names Prism.Unity.Wpf.dll explicitly, with Prism.Unity and Prism.DryIoc listed under the WPF container table.

In practice you add the package to your WPF project. The README gives the package name but no install command, so the restore step is the standard NuGet package reference for Prism.Unity, which pulls in the container adapter and the Prism core assemblies together. The README does not document a project template or a CLI scaffolding command, so the shell and bootstrapper are something you write or copy from the documentation site rather than generate. That is a real difference from frameworks that ship a dotnet new template, and it is worth knowing before you start.

The documentation is not in this repository. The README points to the Prism-Documentation repo under /docs and to docs.prismlibrary.com for a readable version. Support has also moved: the README states that the Prism Team no longer supports or engages with questions posted on StackOverflow, directs general questions to GitHub Discussions, and takes bugs and feature requests through the repository's issue templates. If you are following an older tutorial that ends with a StackOverflow link, that path is dead. For paid tiers, the README lists a [email protected] address for Enterprise Support.

The dual licence is the biggest thing to check before you adopt

Prism 9.0 changed the licence model, and this is the section most teams should read twice. The README states that Prism 9.0 is now dual licensed, that a free Community License continues for the vast majority of the community, and that larger organizations will require a Commercial License to help fund and support development. There is a third tier, Commercial Plus, which the README describes as granting access to additional support libraries built on top of Prism and a private Discord channel for questions and interaction with the Prism Team.

The repository's licence file is reported by the hosting platform as NOASSERTION, meaning the platform's classifier could not reduce it to a standard identifier. That is consistent with a custom dual-licence text, and it is a signal in itself: you cannot assume the terms match a licence you already have approved. What the README does not do is define where the Community tier ends and the Commercial tier begins. The phrase larger organizations is not a threshold. If your legal or procurement process needs a number of employees, a revenue figure or a seat count, the README does not supply one, and you should treat that as an open question to resolve with the Prism Team before you build a dependency on it.

The Commercial Plus feed has a second implication. The README states that Commercial Plus packages are updated with each merged PR, so a paying customer can take a feature as soon as it lands, or a critical bug fix without waiting for a release. That is a real difference in release cadence between tiers, not just a support difference.

Platform timelines, previews and the version you will actually get

The recent release history shows 9.0.537 as a stable release, preceded by 9.0.401-pre and 9.0.271-pre. Those two previews span roughly a year before the stable 9.0.537, which tells you the 9.0 line spent a long time in preview. That is not unusual for a framework with five platform targets, but it does mean older tutorials and answers written against 8.x may not match the current package layout or the licence terms.

The more practical risk is the independent timelines. If you are building a MAUI app and an Avalonia app from the same shared core code, you are depending on two release trains that the README says are developed separately. A behaviour change in one platform package is not guaranteed to appear in the other at the same time. For a single-platform application this is invisible. For a team maintaining a shared library across two XAML platforms, it is a scheduling constraint you should price in.

There is also a versioning question the README leaves open. The core targets .NET Standard 2.0 and .NET Framework 4.6 and 4.7 alongside .NET 6.0 and .NET 8.0. If you are on .NET Framework, you are supported by the shared core, but the per-platform libraries and their release cadence are where the practical support boundary sits. Nothing in the README promises that every platform package tracks the core's target list.

Maintenance status is worth stating plainly. The repository is not archived, and the last push was on 2026-09-11. That is recent activity on the default branch, though it says nothing about which platform packages received it.

The container choice is a real fork, not a detail

Prism supports DryIoc and Unity through separate packages: Prism.Container.DryIoc and Prism.Container.Unity in the cross-platform list, with platform-specific variants such as Prism.DryIoc and Prism.Unity for WPF. This is a genuine architectural fork because the container determines how Prism resolves view models, registers types and handles lifetimes. The abstractions live in Prism.Container.Abstractions, so the framework code is container-agnostic, but your application code and your registration style are not.

Choosing between them is not something the README argues for. It presents both as supported options with their own packages. That is a fair position for a framework, and it also means the decision lands on you. If your team already has a container in the codebase, check whether Prism has an adapter package for it in the list before assuming you can keep it. The README enumerates DryIoc and Unity, and does not describe an adapter for every container in the .NET ecosystem.

The container split also explains a common first-run error. Installing only Prism.Core or only a platform package leaves you without a container adapter, and the framework has nothing to resolve view models with. The README's instruction to install the package for the Container and the Platform of your choice is the fix, and it is easy to miss because the package names look similar.

Alternatives and where Prism is the wrong tool

The obvious alternative in the same space is the CommunityToolkit.Mvvm package, which supplies MVVM primitives such as observable properties and relay commands as source generators. The difference in approach is scope. CommunityToolkit.Mvvm gives you the view model layer and stops there; you bring your own dependency injection container and your own navigation. Prism bundles MVVM with dependency injection, commands and an EventAggregator, and integrates them with the target platform's navigation and view resolution. If you want the smallest possible dependency and you are happy to assemble the rest, the toolkit approach is lighter. If you want the integration layer and you are on a supported XAML platform, that is exactly what Prism is selling.

Prism is the wrong tool in several concrete cases. If your UI is Blazor or ASP.NET, the framework's platform libraries do not apply. If you need a single release train across several UI frameworks at once, the independent timelines work against you. If your organisation is large enough to fall under the Commercial License but the procurement process needs a defined threshold that the README does not provide, you have an unresolved question before you have a technical one. And if you are on a XAML platform that is not in the list of five, there is no package to install.

One more limitation is documentation location. The API documentation lives in a separate repository and on an external site, not in this repository's README. That is normal for a project of this age, but it means the README alone will not get you to a working application, and the README gives no install walkthrough beyond the package tables.

Editorial conclusion

Adopt Prism if you are building a XAML application on WPF, Avalonia, MAUI, Uno Platform or WinUI and you want MVVM, dependency injection, commands and an EventAggregator from one shared core rather than assembled yourself. Skip it if you are outside the XAML stack, or if you need one release train across platforms, because the README states each platform is developed on independent timelines. Before committing, verify which licence tier your organisation falls under, confirm the Container and Platform package pairing for your target, and check whether the platform package you need has shipped a 9.x release rather than only the 9.0.401-pre and 9.0.271-pre previews.

Frequently asked questions

Official sources

1. Issues
2. PrismLibrary/Prism on GitHub
3. README
4. Releases