Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Dec 2, 2025

Proposed changes

Servers running in the same process as clients can now use isolated encodeable factories, preventing type registration conflicts. When a server registers custom types, clients in the same process previously could see these types and skip loading them via the complex type system.

API Changes

  • ServiceMessageContext(ITelemetryContext, IEncodeableFactory) - new constructor accepting a private factory
  • ApplicationConfiguration.CreateMessageContext(IEncodeableFactory) - new overload for private factory
  • ApplicationConfiguration.CreateMessageContext(bool) - marked obsolete (parameter was never used)
  • ServerBase.PrivateEncodeableFactory - new property to set private factory before server startup

Usage

// Option 1: Set on server before startup
var server = new StandardServer();
server.PrivateEncodeableFactory = EncodeableFactory.Create();
await server.StartAsync(configuration);

// Option 2: Create message context with private factory
var factory = EncodeableFactory.Create();
var context = configuration.CreateMessageContext(factory);

Related Issues

Types of changes

  • Bugfix (non-breaking change which fixes an issue)
  • Enhancement (non-breaking change which adds functionality)
  • Test enhancement (non-breaking change to increase test coverage)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected, requires version increase of Nuget packages)
  • Documentation Update (if none of the other choices apply)

Checklist

  • I have read the CONTRIBUTING doc.
  • I have signed the CLA.
  • I ran tests locally with my changes, all passed.
  • I fixed all failing tests in the CI pipelines.
  • I fixed all introduced issues with CodeQL and LGTM.
  • I have added tests that prove my fix is effective or that my feature works and increased code coverage.
  • I have added necessary documentation (if appropriate).
  • Any dependent changes have been merged and published in downstream modules.

Further comments

The existing CreateMessageContext(bool clonedFactory) parameter was never implemented—it was always ignored. This change deprecates it in favor of explicit factory injection, which provides actual isolation guarantees.

Internal callers (Session, DefaultSessionFactory, GDS clients) updated to use the new parameterless CreateMessageContext().

Original prompt

This section details on the original issue you should resolve

<issue_title>A server can not be initialized with a private encodeable factory</issue_title>
<issue_description>### Type of issue

  • Bug
  • Enhancement
  • Compliance
  • Question
  • Help wanted

Current Behavior

The server is initialized with a reference to the global factory. If someone add to the globalfactory (e.g. the server has custom types) a client in the same process is already aware of the types and refuses to load them by the complex type system, effectively not creating a private instance.

Expected Behavior

one or multiple servers and clients can use their private copy the encodeable factory

Steps To Reproduce

No response

Environment

- OS:
- Environment:
- Runtime:
- Nuget Version:
- Component:
- Server:
- Client:

Anything else?

No response</issue_description>

Comments on the Issue (you are @copilot in this section)


💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

Copilot AI and others added 3 commits December 2, 2025 17:17
- Add new ServiceMessageContext constructor that accepts a custom IEncodeableFactory
- Add CreateMessageContext(IEncodeableFactory) overload to ApplicationConfiguration
- Mark CreateMessageContext(bool) as obsolete since the clonedFactory parameter was never used
- Add PrivateEncodeableFactory property to ServerBase for specifying a private factory
- Update all internal calls to use the new parameterless CreateMessageContext()

Co-authored-by: romanett <7413710+romanett@users.noreply.github.com>
Co-authored-by: romanett <7413710+romanett@users.noreply.github.com>
Co-authored-by: romanett <7413710+romanett@users.noreply.github.com>
Copilot AI changed the title [WIP] Enhance server initialization with private encodeable factory Add support for private encodeable factory in server initialization Dec 2, 2025
Copilot AI requested a review from romanett December 2, 2025 17:32
@romanett
Copy link
Contributor

romanett commented Dec 2, 2025

@marcschier do we want to merge this or will you fix the issue with a future MessageContext Refactoring?

@marcschier marcschier marked this pull request as ready for review December 5, 2025 13:20
@marcschier marcschier merged commit dc85d52 into master Dec 5, 2025
166 of 186 checks passed
@romanett romanett deleted the copilot/enhance-private-encodeable-factory branch December 20, 2025 15:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

A server can not be initialized with a private encodeable factory

4 participants