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
- Obtain documentUri from the package itself (e.g. via GetParts / fixed document sequence) instead of hard-coding it.
- Verify the URI exists with _metroPackage.PartExists(documentUri) before calling.
- Fix the URI format: use a valid pack part URI with correct casing and leading '/'.
- 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
- Derive document URIs from the package's own part list, not hard-coded strings.
- Normalize part URIs with PackUriHelper where possible.
- Log available part URIs when a lookup fails to speed diagnosis.
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
- Only writers can call this method.
- Package must contain an XPS PackagePart.
- PackagePart already has associated Thumbnail.
- PackagePart URI does not correspond to a FixedDocument.
- ReachPackaging_OpenDocOrElementAlreadyCalled
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)