cefsharp/CefSharp · error · Exception
RequestContext can only be of type {0} or null
Error message
RequestContext can only be of type {0} or null What it means
Thrown by the WPF ChromiumWebBrowser.RequestContext setter when value.UnWrap() is not assignable to CefSharp.Core.RequestContext. The native bridge requires the exact core concrete type; a custom IRequestContext whose UnWrap() returns a different type is rejected. The message names the expected type for clarity. Mirror of the WinForms RequestContext type error.
Source
Thrown at CefSharp.Wpf/ChromiumWebBrowser.cs:234
}
}
/// <summary>
/// Gets or sets the request context.
/// </summary>
/// <value>The request context.</value>
public IRequestContext RequestContext
{
get { return requestContext; }
set
{
if (browserCreated)
{
throw new Exception("Browser has already been created. RequestContext must be " +
"set before the underlying CEF browser is created.");
}
if (value != null && !Core.ObjectFactory.RequestContextType.IsAssignableFrom(value.UnWrap().GetType()))
{
throw new Exception(string.Format("RequestContext can only be of type {0} or null", Core.ObjectFactory.RequestContextType));
}
requestContext = value;
}
}
/// <summary>
/// Implement <see cref="IRenderHandler"/> and control how the control is rendered
/// </summary>
/// <value>The render Handler.</value>
public IRenderHandler RenderHandler { get; set; }
/// <summary>
/// Implement <see cref="IAccessibilityHandler" /> to handle events related to accessibility.
/// </summary>
/// <value>The accessibility handler.</value>
public IAccessibilityHandler AccessibilityHandler { get; set; }
/// <summary>
/// Raised every time <see cref="IRenderWebBrowser.OnPaint"/> is called. You can access the underlying buffer, though it's
/// preferable to either override <see cref="OnPaint"/> or implement your own <see cref="IRenderHandler"/> as there is no outwardlyView on GitHub (pinned to 16bc6e0711)
Solutions
- Use `new CefSharp.Core.RequestContext(...)` rather than a custom implementation.
- Align all CefSharp.* assembly versions so RequestContextType identity matches.
- Verify value.UnWrap().GetType() is assignable to the Core type before assigning.
- Pass null for the default context if you do not need isolation.
Example fix
// before Browser.RequestContext = customCtx; // UnWrap() is a foreign type // after Browser.RequestContext = new RequestContext();
Defensive patterns
Strategy: type-guard
Validate before calling
var rc = new RequestContext();
if (rc.UnWrap() is CefSharp.Core.RequestContext)
{
browser.RequestContext = rc;
} Type guard
static bool IsValidRequestContext(IRequestContext value)
=> value == null || value.UnWrap() is CefSharp.Core.RequestContext; Prevention
- Only use RequestContext from CefSharp.Core / ObjectFactory.
- Align all CefSharp.* assembly versions so the Core type identity matches.
- Verify UnWrap() returns the Core type when integrating wrappers.
When it happens
Trigger: Assigning a custom IRequestContext implementation whose UnWrap() does not return CefSharp.Core.RequestContext; passing a mock/stub; mixing CefSharp assembly versions so the Core type identity differs.
Common situations: Unit tests with stub IRequestContext; version-mismatched CefSharp assemblies; decorator wrappers that do not UnWrap to the core type.
Related errors
- RequestContext can only be of type {0} or null
- Browser has already been created. RequestContext must be set
- BrowserSettings can only be of type {0} or null
- Browser has already been created. RequestContext must be set
- Screenshot already in progress, you must wait for the previo
AI-assisted analysis of cefsharp/CefSharp@16bc6e0711 (2026-08-13).
Data as JSON: /api/errors/e596cfa2b6cc45f8.
Report an issue: GitHub.