dotnet/wpf · error · ArgumentException
NotAllowedPackageUri
Error message
NotAllowedPackageUri
What it means
PackageStore.AddPackage rejects pack URIs that collide with the framework's reserved base URIs. PackUriHelper.Create normalizes the input, and if the resulting pack URI equals BaseUriHelper.PackAppBaseUri (pack://application:,,,) or SiteOfOriginBaseUri (pack://siteoforigin:,,,), ArgumentException(SR.NotAllowedPackageUri) is thrown. Applications may not register a Package under the URIs WPF itself uses for application resources and site-of-origin files.
Solutions
- Use a distinct custom pack authority, e.g. pack://myapp:,,,/..., instead of application: or siteoforigin:.
- Check the URI against BaseUriHelper.PackAppBaseUri / SiteOfOriginBaseUri before calling AddPackage.
- If you intended to load application resources, use Application resource APIs rather than PackageStore.
Example fix
// before
PackageStore.AddPackage(new Uri("pack://application:,,,/"), pkg); // throws
// after
PackageStore.AddPackage(new Uri("pack://myapp:,,,/"), pkg); Defensive patterns
Strategy: validation
Validate before calling
Uri packUri = PackUriHelper.Create(uri);
if (PackUriHelper.ComparePackUri(packUri, BaseUriHelper.PackAppBaseUri) == 0 ||
PackUriHelper.ComparePackUri(packUri, BaseUriHelper.SiteOfOriginBaseUri) == 0)
throw new ArgumentException("reserved pack URI", nameof(uri)); Try / catch
try { PackageStore.AddPackage(uri, pkg); }
catch (ArgumentException ex) when (ex.ParamName == nameof(uri)) { /* use a custom authority like pack://myapp:,,, */ throw; } Prevention
- Never register packages under application: or siteoforigin: authorities
- Use a custom authority for add-in packages
- Normalize with PackUriHelper.Create before comparing URIs
When it happens
Trigger: Calling PackageStore.AddPackage with a Uri that normalizes to pack://application:,,, or pack://siteoforigin:,,, (or trivially different casing/equivalent forms).
Common situations: Attempting to override the application's own resource package; registering a container with an empty or root pack URI built from misconfigured base strings.
Understand the failure class
Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.
Related errors
- PackageAlreadyExists
- SR.UriMustBeAbsolute
- ' ' cannot contain the path delimiter: ' '.
- ' ' cannot start with the reserved character range…
- ' ' ID is not a valid XSD ID.
AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14).
Data as JSON: /api/errors/a801ab6d66782277.
Report an issue: GitHub.
Appendix: source
Thrown at src/Microsoft.DotNet.Wpf/src/PresentationCore/System/IO/Packaging/PackageStore.cs:95
/// The package will not be automatically replaced within the store.
/// </remarks>
public static void AddPackage(Uri uri, Package package)
{
ValidatePackageUri(uri);
// There are well-known package types that are only for internal use (for resource loading)
// (i.e. ResourceContainer - "application://" and SiteOriginContainer - "siteoforigin://"
// Adding packages with such key uri will have no effect on PackWebRequest since
// they cannot be overriden. So, calling this method with such key Uris should be prevented
// However, uri.Equal cannot be used here since the key Uris are used as a pack Uri form and
// only PackUriHelper.ComparePackUri can do the proper comparison of pack Uris.
Uri packUri = PackUriHelper.Create(uri);
if (PackUriHelper.ComparePackUri(packUri, BaseUriHelper.PackAppBaseUri) == 0 ||
PackUriHelper.ComparePackUri(packUri, BaseUriHelper.SiteOfOriginBaseUri) == 0)
{
throw new ArgumentException(SR.NotAllowedPackageUri, nameof(uri));
}
ArgumentNullException.ThrowIfNull(package);
lock (_globalLock)
{
if (_packages == null)
{
_packages = new HybridDictionary(2);
}
if (_packages.Contains(uri))
{
throw new InvalidOperationException(SR.PackageAlreadyExists);
}
_packages.Add(uri, package);
}View on GitHub (pinned to 81131a70a4)