.NET Deployment (WinUI, WPF, Winforms, and WebForms):

ProEssentials installs several assemblies for building and deploying your applications, found under the DotNet48 (.NET Framework 4.8), DotNet80 (.NET 8), and DotNet10 (.NET 10) folders, and as NuGet packages. Each folder also contains a readme file.

There are two kinds of assembly flavor. Architecture-specific flavors (x64, x86, ARM64) reference the native engine by its real name, so you distribute the control assembly plus the matching engine: PEGRP64I.DLL for x64, PEGRP32I.DLL for x86, or PEGRPARM64I.DLL for ARM64. These assemblies are smaller and make the run-time requirement explicit.

AnyCpu flavors, offered on .NET Framework 4.8, .NET 8, and .NET 10, are self-contained. They embed the native engines and, on first run, unpack the one matching the running process - beside your EXE when that folder is writable, otherwise to a per-user cache under %LOCALAPPDATA% (see PeGlobal.CacheBrand) - so nothing extra needs to ship.

One important distinction decides whether AnyCpu actually runs native on ARM64, and it is easy to get wrong. This is a property of .NET itself - true of any executable built for .NET 5 or later, not something specific to ProEssentials. On .NET 8 and .NET 10, an executable has a small native launcher whose architecture is set when you BUILD it (the standard PlatformTarget behavior; see Microsoft's C# compiler output-options documentation). An "AnyCpu" project still produces a launcher matching your build machine - x64 on an x64 machine - and that choice is fixed; it does not adapt at run time, so on an ARM64 device it runs x64-emulated, not native. To run native on ARM64 with .NET 8/10, build a separate ARM64 executable and ship it (your installer can detect the architecture and install the matching EXE). Only the EXE's target needs to be ARM64 - it can still reference our AnyCpu control assembly, which unpacks the ARM64 engine because the process is ARM64. On .NET Framework 4.8, by contrast, an AnyCpu executable is IL-only and genuinely architecture-neutral: a single 4.8 AnyCpu build runs native as x86, native as x64, and - with the "Prefer native ARM64" project option, backed by .NET Framework 4.8.1's ARM64 runtime - native as ARM64. The 4.8 AnyCpu flavor is therefore the only one in the product that delivers all three architectures from a single build. (Set the AnyCpu configuration's "Prefer 32-bit" to false, or it builds 32-bit everywhere.)

Because the native engine self-reports its license (a stamped engine is licensed, an unstamped engine runs in evaluation with a watermark), the same assemblies serve evaluation, development, and distribution.

For the .NET Framework 4.8 AnyCpu flavor specifically, moving from evaluation to licensed is automatic once you install the product: the stamped engine is placed in the Windows system folder, and the control loads it in preference to unpacking its embedded evaluation engine, so development becomes watermark-free with no assembly or NuGet change. One thing to clear first: if an earlier evaluation run already unpacked a PEGRPI.DLL next to your executable, that local copy is found first (the application folder is searched ahead of the system folder) and would keep the watermark, so delete it after installing the product. Our .NET Framework 4.8 example projects do this automatically with a small pre-build step that deletes the output PEGRPI.DLL, and it is the recommended pattern for your own 4.8 AnyCpu projects.

WinUI is our latest and most modern interface, a .NET 10 interface not offered on .NET Framework 4.8 or .NET 8. WinUI 3 is Microsoft's current-generation Windows UI platform and the modern successor to WPF; it is where we recommend new development begin. WPF and Winforms remain fully supported for existing applications.

The WinUI control is three files, not one. Beside Gigasoft.ProEssentialsWinUI.Dll, the DotNet10 folders also carry Gigasoft.ProEssentialsWinUI.pri and Gigasoft.ProEssentialsWinUI.xml. The .pri is the control's compiled XAML resource index - keep it with the DLL when you reference the control directly (a drop-in DLL reference rather than the NuGet package), because your application's build merges it into your app's resources.pri. The .xml is the IntelliSense documentation Visual Studio reads for tooltips; it is a development-time file and does not need to be deployed. The Winform and WPF controls likewise ship an .xml IntelliSense file that need not be deployed.

WinUI deployment differs from WPF / WinForms - please read.

A .NET (Core) application is not a single exe. The exe is a small launcher; your code lives in App.dll, and it needs App.deps.json and App.runtimeconfig.json beside it. Always deploy the entire build or publish output folder, never a hand-picked subset of files.

Unlike WPF and WinForms, a WinUI app also depends on the Windows App SDK. So the target machine needs two runtimes (plus the Visual C++ Redistributable): the .NET 10 Desktop Runtime and the Windows App SDK Runtime. There are two ways to satisfy this:

1. Framework-dependent (smaller apps, shared runtimes): install the two runtimes once on the machine - they are shared by every app - and ship your small app folder. A setup program can chain both Microsoft redistributable installers silently, just like a Visual C++ redistributable. The Windows App SDK installer (WindowsAppRuntimeInstall.exe --quiet) is idempotent and skips itself if the runtime is already present; the .NET Desktop Runtime installer supports /quiet.

2. Self-contained (no prerequisites, but larger and architecture-specific): publish with both runtimes bundled into the app folder -

dotnet publish -c Release -r win-x64 --self-contained true -p:WindowsAppSDKSelfContained=true

(use win-arm64 for ARM64). The result runs on a clean machine with nothing installed, but it is architecture-specific and carries both runtimes inside every app folder.

Keep it lean: reference the Microsoft.WindowsAppSDK.WinUI component package (together with Microsoft.WindowsAppSDK.Runtime) rather than the all-in-one Microsoft.WindowsAppSDK umbrella package. The umbrella pulls in the Windows AI / ML / ONNX runtime - roughly 40 MB across a dozen extra DLLs, including DirectML.dll and onnxruntime.dll - that a charting application never uses. The ProEssentials WinUI control and the shipped WinUI demos already reference the component packages.

Important: a WinUI app will appear to run from an under-filled folder on your development machine, because the runtimes are already installed there. Always validate deployment on a clean machine (no .NET, no Windows App SDK installed) to see what your customers will actually experience. See also the New V11 Features topic.

The WebForms control renders on the server; deploy PEGRP64I.DLL with the site (or install it into the server's System32 as below).

The setup also installs the native engines into the Windows system folders, so the engine is already found during development: PEGRP32I.DLL in Windows\SysWOW64, PEGRP64I.DLL in Windows\System32, and PEGRPARM64I.DLL in Windows\System32 on ARM64 Windows. For distribution, ship the matching engine beside your application (or use an AnyCpu flavor, which carries it for you).

The setup additionally installs a generic-named PEGRPI.DLL in System32 so the AnyCpu control can be placed on a form in the Visual Studio designer. The AnyCpu assembly binds the engine by a generic name, and at design time there is no application folder for it to unpack into, so the designer loads PEGRPI.DLL from System32. It matches the machine's native architecture (the x64 engine on x64 Windows, the ARM64 engine on ARM64 Windows). This file is for design time only; your distributed application uses the engine that unpacks beside it at run time. (If you run a Visual Studio whose architecture differs from the machine's native one, design instead against the matching architecture-specific reference, whose real-named engine is also in System32.)