cefsharp/CefSharp · error · Exception
A call to WithSharedSettings has already been made, it is no
Error message
A call to WithSharedSettings has already been made, it is no possible to provide custom settings.
What it means
Thrown by RequestContextBuilder.ThrowExceptionIfContextAlreadySet (a plain System.Exception, not a domain type) when you call a method that sets custom settings (e.g. WithCachePath) after WithSharedSettings has already stored an _otherContext. The builder cannot both share another context's storage and apply its own settings, so it rejects the contradictory configuration. Note the message typo 'no possible'.
Source
Thrown at CefSharp.Core/RequestContextBuilder.cs:25
using CefSharp.Handler;
using System;
namespace CefSharp
{
/// <summary>
/// Fluent style builder for creating IRequestContext instances.
/// </summary>
public class RequestContextBuilder
{
private RequestContextSettings _settings;
private IRequestContext _otherContext;
private RequestContextHandler _handler;
void ThrowExceptionIfContextAlreadySet()
{
if (_otherContext != null)
{
throw new Exception("A call to WithSharedSettings has already been made, it is no possible to provide custom settings.");
}
}
void ThrowExceptionIfCustomSettingSpecified()
{
if (_settings != null)
{
throw new Exception("A call to WithCachePath has already been made, it's not possible to share settings with another RequestContext.");
}
}
/// <summary>
/// Create the actual RequestContext instance
/// </summary>
/// <returns>Returns a new RequestContext instance.</returns>
public IRequestContext Create()
{
if (_otherContext != null)
{View on GitHub (pinned to 16bc6e0711)
Solutions
- Decide on one strategy: either share via WithSharedSettings OR customise via WithCachePath/WithPreference, never both.
- Split into two separate RequestContextBuilder instances if you need both kinds of contexts.
- Call WithCachePath before any WithSharedSettings is impossible (sharing wins once set), so reorder: build your custom context first if needed.
- Track builder state in your own code so the two paths are mutually exclusive at the source.
Example fix
// before - contradictory
var ctx = RequestContext.Configure()
.WithSharedSettings(parent)
.WithCachePath(@"C:\cache") // throws
.Create();
// after - pick one
var shared = RequestContext.Configure().WithSharedSettings(parent).Create();
// or
var custom = RequestContext.Configure().WithCachePath(@"C:\cache").Create(); Defensive patterns
Strategy: validation
Validate before calling
// Enforce one strategy before building.
RequestContextBuilder Build(bool share, IRequestContext parent, string cache)
{
var b = RequestContext.Configure();
if (share) return b.WithSharedSettings(parent);
return b.WithCachePath(cache);
} Type guard
public static bool CanAddCustomSettings(RequestContextBuilder b) => b.GetOtherContext() == null; // (requires exposing state)
Try / catch
try { return builder.WithCachePath(path).Create(); }
catch (Exception ex) when (ex.Message.Contains("WithSharedSettings has already been made"))
{ /* use a fresh builder for custom settings */ return RequestContext.Configure().WithCachePath(path).Create(); } Prevention
- Never chain WithSharedSettings and WithCachePath on one builder
- Use a dedicated builder per strategy
- Add integration tests covering both code paths
When it happens
Trigger: Chaining .WithSharedSettings(parent).WithCachePath(...) on the same builder; calling WithCachePath twice after a share; any settings mutation after WithSharedSettings.
Common situations: Copy-pasted builder configuration where one branch shares and another customises; refactoring that merged two builders; misunderstanding that sharing and customising are mutually exclusive.
Related errors
- A call to WithCachePath has already been made, it's not poss
- other
- otherRequestContext
- requestContextHandler
- settings
AI-assisted analysis of cefsharp/CefSharp@16bc6e0711 (2026-08-13).
Data as JSON: /api/errors/d498c0527f64c33c.
Report an issue: GitHub.