dotnet/wpf · error · NotSupportedException
Write-only mode is not supported.
Error message
Write-only mode is not supported.
What it means
UpdateModeFlagFromFileAccess converts a FileAccess into an OLE STGM mode. Write-only access (FileAccess.Write alone) is deliberately unsupported because write-only compound-file scenarios are tricky and rarely used, so a NotSupportedException (SR.WriteOnlyUnsupported) is thrown.
Solutions
- Open with FileAccess.ReadWrite instead of FileAccess.Write
- If write-only semantics are desired, emulate by opening ReadWrite and not reading
- Refactor to avoid reusing the write-only FileAccess value for packaging APIs
Example fix
// before container = new CompoundFileContainer(stream, FileAccess.Write, ...); // after container = new CompoundFileContainer(stream, FileAccess.ReadWrite, ...);
Defensive patterns
Strategy: try-catch
Validate before calling
if (access == FileAccess.Write) access = FileAccess.ReadWrite; // write-only unsupported
Type guard
static bool IsSupportedAccess(FileAccess a) => a != FileAccess.Write;
Try / catch
try { OpenContainer(stream, access); } catch (NotSupportedException) { access = FileAccess.ReadWrite; OpenContainer(stream, access); } Prevention
- Never open WPF packaging containers with FileAccess.Write alone
- Default to FileAccess.ReadWrite for compound-file scenarios
- Centralize FileAccess selection in one helper
When it happens
Trigger: Opening a compound file (e.g. via CompoundFileContainer or related packaging APIs) with FileAccess.Write but not FileAccess.Read.
Common situations: Code that opens files for writing-only elsewhere and reuses FileAccess.Write when opening a WPF package container.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
- ' ' cannot contain the path delimiter: ' '.
- ' ' cannot start with the reserved character range…
- ' ' ID is not a valid XSD ID.
- ' ' is not a valid value for ' '.
- Can only countersign parts with Digital Signature…
AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14).
Data as JSON: /api/errors/b4a255c43524a616.
Report an issue: GitHub.
Appendix: source
Thrown at src/Microsoft.DotNet.Wpf/src/WindowsBase/MS/Internal/IO/Packaging/CompoundFile/NativeCompoundFileAPIs.cs:31
using CultureInfo = System.Globalization.CultureInfo;
namespace MS.Internal.IO.Packaging.CompoundFile
{
internal static class SafeNativeCompoundFileMethods
{
/// <summary>
/// Utility function to update a grfMode value based on FileAccess.
/// 6/12/2002: Fixes bug #4938, 4960, 5096, 4858
/// </summary>
/// <param name="access">FileAccess we're translating</param>
/// <param name="grfMode">Mode flag parameter to modify</param>
internal static void UpdateModeFlagFromFileAccess( FileAccess access, ref int grfMode )
{
// Supporting write-only scenarios container-wide gets tricky and it
// is rarely used. Don't support it for now because of poor
// cost/benefit ratio.
if( FileAccess.Write == access )
throw new NotSupportedException(
SR.WriteOnlyUnsupported);
// Generate STGM from FileAccess
// STGM_READ is 0x00, so it's "by default"
if( ( FileAccess.ReadWrite == (access & FileAccess.ReadWrite) ) ||
( (FileAccess.Read | FileAccess.Write) == (access & (FileAccess.Read | FileAccess.Write))) )
{
grfMode |= SafeNativeCompoundFileConstants.STGM_READWRITE;
}
else if( FileAccess.Write == (access & FileAccess.Write) )
{
grfMode |= SafeNativeCompoundFileConstants.STGM_WRITE;
}
else if( FileAccess.Read != (access & FileAccess.Read))
{
throw new ArgumentException(
SR.FileAccessInvalid);
}View on GitHub (pinned to 81131a70a4)