dotnet/wpf · error · InvalidDataException

Document PackagePart URI is not valid.

Error message

Document PackagePart URI is not valid.

What it means

GetSignatureDefinitionPart looks up the document part by its URI via _metroPackage.GetPart(documentUri) and throws InvalidDataException (SR.ReachPackaging_InvalidDocUri) when GetPart returns null, meaning the package contains no part at that URI. This indicates the documentUri supplied does not address an existing part in the package.

Solutions

  1. Obtain documentUri from the package itself (e.g. via GetParts / fixed document sequence) instead of hard-coding it.
  2. Verify the URI exists with _metroPackage.PartExists(documentUri) before calling.
  3. Fix the URI format: use a valid pack part URI with correct casing and leading '/'.
  4. Re-open the correct package — the URI may belong to a different document than the one loaded.

Example fix

// before
var sigPart = xpsManager.GetSignatureDefinitionPart(new Uri("/Documents/1/Pages/1.fpage", UriKind.Relative));
// after
var docUri = new Uri("/Documents/1/Pages/1.fpage", UriKind.Relative);
if (!package.PartExists(docUri)) throw new FileNotFoundException($"Document part {docUri} not found in package");
var sigPart = xpsManager.GetSignatureDefinitionPart(docUri);
Defensive patterns

Strategy: validation

Validate before calling

var docUri = new Uri(path, UriKind.Relative);
if (!_metroPackage.PartExists(docUri)) throw new ArgumentException($"Document part '{path}' does not exist in the package");

Type guard

bool DocumentExists(Package pkg, Uri uri) => pkg?.PartExists(uri) == true;

Try / catch

try { return xpsManager.GetSignatureDefinitionPart(docUri); }
catch (InvalidDataException ex) when (ex.Message.Contains("URI")) { /* enumerate package parts to find the correct document URI */ return null; }

Prevention

When it happens

Trigger: Calling GetSignatureDefinitionPart with a documentUri that does not resolve to a part in the opened XPS package — wrong part path, typo in URI, or the document part was never added/removed.

Common situations: Hard-coded part URIs (e.g. "/Documents/1/Pages/1.fpage") that don't match the actual package layout; packages edited or regenerated with different document numbering; case-sensitivity or missing leading slash in the URI.

Understand the failure class

Background: "Not found" and "does not exist" errors: why "Task not found", "No such folder", and "Can't find" fire when a lookup comes back empty — this error's family across 14 libraries.

Related errors


AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14). Data as JSON: /api/errors/ea0e3693bd3a1638. Report an issue: GitHub.

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/ReachFramework/Packaging/XpsManager.cs:579

                documentPart.CreateRelationship(
                    sigDefPart.Uri,
                    TargetMode.Internal,
                    XpsS0Markup.SignatureDefinitionRelationshipName
                    );
            }
            return sigDefPart;
        }

        public
        PackagePart
        GetSignatureDefinitionPart(Uri documentUri)
        {
            PackagePart documentPart = _metroPackage.GetPart( documentUri );
            PackagePart sigDefPart = null;

            if( documentPart == null )
            {
              throw new InvalidDataException(SR.ReachPackaging_InvalidDocUri);
            }

            ContentType SignitureDefType =
                XpsS0Markup.SignatureDefintionType;
            PackageRelationship SigDefRel = null;

            foreach (PackageRelationship rel in
                     documentPart.GetRelationshipsByType(XpsS0Markup.SignatureDefinitionRelationshipName))
            {
                if (SigDefRel != null)
                {
                    throw new InvalidDataException(SR.ReachPackaging_MoreThanOneSigDefParts);
                }

                SigDefRel = rel;
            }
            if (SigDefRel != null)
            {

View on GitHub (pinned to 81131a70a4)