

ProEssentials WinUI charting interfaces are used when creating stand-alone client-side EXEs to be distributed and run on an end-user's machine. WinUI 3 is our newest and most modern .NET charting interface, introduced in ProEssentials v11. It renders through Direct3D and Direct2D composition swap chains, targets .NET 10, and runs on both x64 and ARM64 hardware. This WinUI 3 .NET 10 C# Charting walk-through covers Visual Studio 2026. Click here for the WPF walk-through Click here for the WinForms walk-through
It is recommended that the namespace: Gigasoft.ProEssentials.Enums be included at the top of your source code files utilizing ProEssentials. In C#, use the using keyword. For example:
using Gigasoft.ProEssentials.Enums;
Before you start. WinUI 3 charting requires the .NET 10 SDK and the Visual Studio Windows application development workload, which supplies the Windows App SDK project templates. Our WinUI assembly is installed to ProEssentials11\DotNet10\x64, with \AnyCpu and \Arm64 alongside it.
The following information demonstrates how to create your first .NET 10 WinUI 3 charting ProEssentials implementation using the C# language. It discusses using the WinUI interfaces to add interactive scientific charting content to your EXEs. See the other charting examples provided within the product/evaluation.
Unlike our WinForms and WPF interfaces, you will not drag a ProEssentials chart out of the Toolbox. Visual Studio does not include a XAML Designer for WinUI 3 in any version, including VS2026. This is a Microsoft platform gap that affects every control vendor equally, so the WinUI Toolbox is empty by design and the Properties/Events window is not available at design time.
In practice this changes very little. You add our assembly as a reference (or a NuGet package), you hand-type one XAML tag, and you wire events in code. Microsoft's recommended replacement for the designer is the XAML runtime design tools: start the app with F5 (not Ctrl+F5) and use Hot Reload, Live Preview, Live Visual Tree and Live Property Explorer to adjust the running UI and see changes without restarting. Because a ProEssentials chart draws real data, the running app is a far more useful preview than a static designer surface ever was.
PRO TIP: a shorter path through this walk-through is to start with our WinUI starter repo, which already implements steps 1 and 2. Cloning it and starting at step 3 is recommended, though understanding steps 1 and 2 is worth the read.
https://github.com/GigasoftInc/winui-starter
1) Start Visual Studio 2026 and create a new project targeting [C#] [Windows] [WinUI]. Visual Studio offers two WinUI app templates: WinUI Blank App (Packaged) and Blank App (Packaged with WAP Project). Choose the first, the simpler of the two, and accept the default name of [WinUIApp1].
The stock WinUI template is aimed at a Microsoft Store MSIX app that ships the whole Windows App SDK. For a charting EXE several of its defaults are wrong. Two of them prevent ProEssentials from working at all, and one silently adds about 41MB to your output. Make these changes now, before adding our assembly, and the rest of this walk-through is uneventful.
| Template default | Change it to | Why |
|---|---|---|
| net8.0-windows... | net10.0-windows10.0.19041.0 | Our WinUI assembly is .NET 10 only; our NuGet will not install otherwise. |
| packaged (no WindowsPackageType) | WindowsPackageType = None | Lets the EXE run by double-clicking it, with no MSIX identity. |
| Microsoft.WindowsAppSDK (umbrella) | .WinUI + .Runtime components | Drops roughly 41MB of AI/ML runtime you never use. |
| PublishTrimmed = True | False | Trimming is not safe for WinUI XAML and can break the app at Release. |
| x86;x64;ARM64 | x64;ARM64 | There is no x86 WinUI build of ProEssentials. |
a) Retarget to .NET 10. The Visual Studio 2026 WinUI templates still create a .NET 8 project. Our WinUI assembly is .NET 10 only, so our NuGet package will refuse to install into the template's default project. In the project file set...
<TargetFramework>net10.0-windows10.0.19041.0</TargetFramework>
If the target framework refuses to stick and snaps back to .NET 8, check RuntimeIdentifiers for legacy values. .NET 8 and later use a portable RID graph, and old OS-version RIDs such as win10-x64 are no longer valid. They block retargeting and fail the build with NETSDK1083. Use the portable form...
<RuntimeIdentifiers>win-x64;win-arm64</RuntimeIdentifiers>
b) Switch to unpackaged. Both WinUI templates are packaged (MSIX) projects, as Microsoft does not ship an unpackaged WinUI template. A packaged app runs only with package identity, which Visual Studio supplies when you press F5. If you then browse to your bin folder and double-click the EXE directly, the app crashes on startup with...
System.Runtime.InteropServices.COMException (0x80040154): Class not registered (REGDB_E_CLASSNOTREG) at WinRT.ActivationFactory.Get(String typeName) at Microsoft.Windows.ApplicationModel.WindowsAppRuntime.DeploymentManagerCS.AutoInitialize...
This is expected Windows App SDK behavior, not a charting error. Without package identity the Windows App Runtime's WinRT classes cannot be activated. To get an EXE that runs by double-clicking it, the way our WinForms and WPF samples always have, add this line to the PropertyGroup in your project file...
<WindowsPackageType>None</WindowsPackageType>
This makes the project unpackaged, which also switches it to the Windows App SDK bootstrapper; it will prompt to install the runtime if it is missing. Every ProEssentials WinUI sample we ship is unpackaged this way - PewinUIDemo, GigaPrime2DwinUI, GigaPrime3DwinUI and the TestBeds Starter all set it. Keep the MSIX/packaged model only if you specifically intend to distribute through an MSIX package, and in that case launch from the Start menu rather than from bin.
Once the project is unpackaged, the template's MSIX scaffolding is dead weight. You may remove Package.appxmanifest and the Assets folder of Store tile logos, along with these project-file entries...
<EnableMsixTooling>true</EnableMsixTooling> <ProjectCapability Include="Msix" /> <!-- and the ItemGroup holding it --> <HasPackageAndPublishMenu>true</HasPackageAndPublishMenu> <!-- and its PropertyGroup --> <Content Include="Assets\..." /> <!-- the Store logo entries -->
Keep app.manifest. It is not MSIX scaffolding. It carries the DPI-awareness and supported-OS declarations, and our samples all keep it.
c) Use the Windows App SDK component packages, not the umbrella. The template references the all-in-one Microsoft.WindowsAppSDK package. That metapackage transitively pulls in the entire Windows AI/ML stack - onnxruntime.dll at about 21MB and DirectML.dll at about 18MB, plus the Microsoft.Windows.AI.* projections - roughly 41MB of payload into the output folder of a chart application that never calls any of it. Replace the umbrella with the two component packages you actually need...
<!-- remove: <PackageReference Include="Microsoft.WindowsAppSDK" Version="2.2.0" /> --> <PackageReference Include="Microsoft.WindowsAppSDK.WinUI" Version="2.2.1" /> <PackageReference Include="Microsoft.WindowsAppSDK.Runtime" Version="2.2.0" />
Keep both: .WinUI supplies the XAML framework, and .Runtime supplies the framework dependency and the unpackaged bootstrapper. Our own NuGet packages already reference exactly these two, so if you install ProEssentials from NuGet you can simply delete the umbrella reference.
d) Turn off trimming. The template enables PublishTrimmed for every non-Debug build. Trimming is not safe for WinUI 3: the Microsoft.Windows.SDK.NET and WinRT.Runtime assemblies produce trim warnings, and XAML type resolution is reflection-driven, so a trimmed Release build can fail at run time even though Debug worked perfectly. This bites the first time you publish, long after the code is written.
<PublishTrimmed Condition="'$(Configuration)' != 'Debug'">False</PublishTrimmed>
e) Drop the x86 platform. The template offers x86, x64 and ARM64. ProEssentials WinUI ships x64, ARM64 and AnyCpu assemblies only. There is no x86 WinUI build, and our AnyCpu assembly embeds the x64 and ARM64 native engines only. 32-bit development continues through our .NET 4.8 interfaces and PEGRP32I.DLL. Trim both lists...
<Platforms>x64;ARM64</Platforms> <RuntimeIdentifiers>win-x64;win-arm64</RuntimeIdentifiers>
2) When the new project opens, you will be presented with "App.xaml / App.xaml.cs" and "MainWindow.xaml / MainWindow.xaml.cs". Opening MainWindow.xaml shows the XAML text editor only; there is no split designer view, per the note above. XAML IntelliSense is fully available in the text editor.
3) Adding the ProEssentials WinUI charting interface to your project. There are two methods for VS2026 and either is fine.
Method 1 - Edit the project file (recommended). This is the simplest and clearest method, and it keeps our native engine visible in your project rather than hidden inside a package.
<ItemGroup>
<Reference Include="Gigasoft.ProEssentialsWinUI">
<HintPath>.\Gigasoft.ProEssentialsWinUI.dll</HintPath>
</Reference>
</ItemGroup>Note: the .pri file must sit beside the DLL. It carries our control templates (Generic.xaml) and is merged into your application's .pri at build time. Without it the chart will not render its template.
Note: the x64 assembly expects PEGRP64I.DLL to be distributed with your EXE. Use the \Arm64 assembly with PEGRPARM64I.DLL for ARM64 hardware, or the \AnyCpu assembly, which embeds both the x64 and ARM64 native engines inside the assembly and unpacks the correct one at run time.
Method 2 - NuGet Package Manager.
4) Open MainWindow.xaml and hand-type the chart into your window. First add our XAML namespace to the Window tag, then place a chart tag between the Grid tags. Your MainWindow.xaml should look like...
<Window x:Class="WinUIApp1.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:pe="using:Gigasoft.ProEssentials"
Title="WinUIApp1">
<Grid x:Name="RootGrid" UseLayoutRounding="True">
<pe:PegoWinUI x:Name="Pego1" />
</Grid>
</Window>Note the type name. The WinUI control types carry a WinUI suffix: PegoWinUI, PesgoWinUI, Pe3doWinUI, PepcoWinUI and PepsoWinUI. All of our .NET interfaces share the single namespace Gigasoft.ProEssentials and the identical PExxx property API, so only the type name changes between interfaces (WinForms Pego, WPF PegoWpf, WinUI PegoWinUI, WebForms PegoWeb).
* Note, use the Build menu, Rebuild project after adding the reference so the IDE compiles everything necessary for XAML IntelliSense to resolve the pe: prefix.
This represents the default state of a ProEssentials Graph. The default state has one subset with four data points. In the course of constructing your own charts, you'll set the properties PeData.Subsets and PeData.Points which define the quantity of data your chart will hold. You'll then pass data via the PeData.Y[subset, point] two dimensional property array. The following section shows example code of passing data.
ProEssentials uses the terms Subsets and Points but you can think of these as Rows and Columns. Passing data is as simple as filling each Subset with Points worth of data.
5) Open MainWindow.xaml.cs and wire the chart's Loaded event in the constructor, then initialize the chart in that handler.
Important: initialize in the chart's Loaded event, not the Window's. A WinUI Window is not a FrameworkElement and does not raise Loaded, and the root Grid's Loaded fires before our chart's own construction is fully complete. Always initialize a ProEssentials chart from that chart's own Loaded event. This is the pattern used throughout our shipping WinUI demo.
public MainWindow()
{
InitializeComponent();
Pego1.Loaded += Pego1_Loaded;
Pego1.PeDataHotSpot += Pego1_PeDataHotSpot;
}With the Pego1_Loaded handler created, enter the following code into this section. You can copy and paste, but hand-typing a few lines of this code will help familiarize yourself with the Gigasoft.ProEssentials namespace.
Note: adding the following using declarations at the top of "MainWindow.xaml.cs" will shorten enumeration syntax and supply the Color type.
using Gigasoft.ProEssentials.Enums; using Windows.UI; // Color -- WinUI uses Windows.UI.Color, not System.Drawing or System.Windows.Media
void Pego1_Loaded(object sender, RoutedEventArgs e)
{
// Simple to code = simple to implement and maintain //
Pego1.PeString.MainTitle = "Hello World";
Pego1.PeString.SubTitle = "";
Pego1.PeData.Subsets = 2; // Subsets = Rows //
Pego1.PeData.Points = 6; // Points = Columns //
Pego1.PeData.Y[0, 0] = 10; Pego1.PeData.Y[0, 1] = 30;
Pego1.PeData.Y[0, 2] = 20; Pego1.PeData.Y[0, 3] = 40;
Pego1.PeData.Y[0, 4] = 30; Pego1.PeData.Y[0, 5] = 50;
Pego1.PeData.Y[1, 0] = 15; Pego1.PeData.Y[1, 1] = 63;
Pego1.PeData.Y[1, 2] = 74; Pego1.PeData.Y[1, 3] = 54;
Pego1.PeData.Y[1, 4] = 25; Pego1.PeData.Y[1, 5] = 34;
Pego1.PeString.PointLabels[0] = "Jan";
Pego1.PeString.PointLabels[1] = "Feb";
Pego1.PeString.PointLabels[2] = "Mar";
Pego1.PeString.PointLabels[3] = "Apr";
Pego1.PeString.PointLabels[4] = "May";
Pego1.PeString.PointLabels[5] = "June";
Pego1.PeString.SubsetLabels[0] = "For WinUI 3 and .NET 10";
Pego1.PeString.SubsetLabels[1] = "or WPF, WinForms, WebForms";
Pego1.PeString.YAxisLabel = "Simple Quality Rendering";
Pego1.PeColor.SubsetColors[0] = Color.FromArgb(60, 0, 180, 0);
Pego1.PeColor.SubsetColors[1] = Color.FromArgb(180, 0, 0, 130);
Pego1.PeColor.BitmapGradientMode = false;
Pego1.PeColor.QuickStyle = QuickStyle.LightShadow;
Pego1.PeTable.Show = GraphPlusTable.Both;
Pego1.PeData.Precision = DataPrecision.NoDecimals;
Pego1.PeFont.Label.Bold = true;
Pego1.PePlot.Method = GraphPlottingMethod.Bar;
Pego1.PePlot.Option.GradientBars = 8;
Pego1.PePlot.Option.BarGlassEffect = true;
Pego1.PeLegend.Location = LegendLocation.Left;
Pego1.PePlot.DataShadows = DataShadows.ThreeDimensional;
Pego1.PeFont.FontSize = FontSize.Large;
// These settings will be used for all charts //
Pego1.PeConfigure.RenderEngine = RenderEngine.Direct2D;
Pego1.PeConfigure.AntiAliasGraphics = true;
Pego1.PeConfigure.AntiAliasText = true;
// This enables data hot spots, but we need code in the HotSpot event //
Pego1.PeUserInterface.HotSpot.Data = true;
Pego1.PeFunction.ReinitializeResetImage();
}6) The code above enabled the DataHotSpot event, so we should place some appropriate code in the DataHotSpot event.
Because WinUI 3 has no designer, there is no Properties/Events window to double-click. You wire ProEssentials events in code, exactly as shown in the constructor in step 5. Type the Pego1.PeDataHotSpot += Pego1_PeDataHotSpot; line, then place the cursor on Pego1_PeDataHotSpot, press Ctrl+. for Quick Actions and choose Generate method. Visual Studio writes the handler with the correct signature.
WinUI has no MessageBox, so we show the result with a ContentDialog, which needs a XamlRoot and is shown asynchronously. Note the handler is declared async. Add the following code to the Pego1_PeDataHotSpot event.
private async void Pego1_PeDataHotSpot(object sender,
Gigasoft.ProEssentials.EventArg.DataHotSpotEventArgs e)
{
ContentDialog dlg = new ContentDialog();
dlg.Title = "Data HotSpot";
dlg.Content = "Subset " + e.SubsetIndex.ToString() +
", Point " + e.PointIndex.ToString() + " with a value of " +
Pego1.PeData.Y[e.SubsetIndex, e.PointIndex].ToString();
dlg.CloseButtonText = "OK";
dlg.XamlRoot = this.Content.XamlRoot;
await dlg.ShowAsync();
}7) Save and run the project with F5. Move the mouse over the chart and click a bar to trigger the DataHotSpot event. Right click the chart to open our built-in WinUI menu and dialogs.
8) A WinUI 3 application has different deployment requirements than WPF or WinForms. Unlike those interfaces, an unpackaged WinUI app requires two runtimes on the target machine: the .NET 10 Desktop Runtime and the Windows App SDK Runtime. You must also distribute the entire output folder, not just your EXE plus our files. Your development machine already has both runtimes, so always test on a clean machine.
To produce a build that runs on a machine with nothing installed, publish self-contained, which bundles both runtimes into your output folder...
dotnet publish -c Release -r win-x64 --self-contained true -p:WindowsAppSDKSelfContained=true
Use win-arm64 for ARM64 targets.
Package tip: reference the Windows App SDK component packages (Microsoft.WindowsAppSDK.WinUI and Microsoft.WindowsAppSDK.Runtime) rather than the all-in-one Microsoft.WindowsAppSDK umbrella package. The umbrella drags the Windows AI/ML/ONNX runtime into your output folder, adding roughly 40MB you almost certainly do not need. Our NuGet packages already reference the component packages for you.
Please review the demo code and documentation installed with the eval/product. Demo projects can be reached from the Start menu under ProEssentials v11.
Our main WinUI demo is installed to ProEssentials11\WINUI-C#.NET10\PewinUIDemo, and our WinUI GigaPrime samples to ProEssentials11\GigaPrime2DwinUI and ProEssentials11\GigaPrime3DwinUI.
A minimal starting project matching this walk-through is installed to ProEssentials11\TestBeds\Starter\NET10\WinUIApp1.
Our main demo is replicated in native WinUI C#, WPF C#, WinForms C#.NET, VB.NET, VC++ MFC, Delphi and Builder, all accessible from where you installed ProEssentials. These are great for modifying an existing demo to test potential charting modifications before implementing them within your applications.

See how our WinUI charting library compares on performance and licensing.
Thank you for researching. Please contact our engineers if you have a question.
我们的首要目标是通过为您的机构和终端用户提供最简单、最专业的服务,达成您的成功。
ProEssentials是由需要自定义图表组件的专业电气工程师创立的。加入使用ProEssentials的顶级工程公司名单。
感谢您成为ProEssentials的客户,也感谢您研究ProEssentials图表引擎。