Add DotNetSdkSupportsVSHostObjectRemoting property#53100
Merged
YuliiaKovalova merged 4 commits intorelease/10.0.3xxfrom Feb 24, 2026
Merged
Add DotNetSdkSupportsVSHostObjectRemoting property#53100YuliiaKovalova merged 4 commits intorelease/10.0.3xxfrom
YuliiaKovalova merged 4 commits intorelease/10.0.3xxfrom
Conversation
Emit DotNetSdkSupportsComRemoting=true as an MSBuild property via the SDK resolver's propertiesToAdd, following the pattern used for SdkResolverMSBuildTaskHostRuntimeVersion. This allows VS tooling to check for COM remoting support via a property rather than version comparison. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adds a new MSBuild property DotNetSdkSupportsComRemoting to signal COM remoting support in the SDK resolver, following the established pattern from PR #45364. This enables Visual Studio tooling (WebTools) to reliably detect the consolidated VSHostObject implementation from PR #53028 without fragile SDK version comparisons.
Changes:
- Added
DotNetSdkSupportsComRemotingconstant and unconditionally emits it as "true" in SDK resolver'spropertiesToAdd - Updated three test methods to verify the new property is correctly added and increment property count assertions
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/MSBuildSdkResolver.cs | Added constant definition and property emission logic following the established pattern |
| test/Microsoft.DotNet.MSBuildSdkResolver.Tests/GivenAnMSBuildSdkResolver.cs | Updated test constant, count assertions, and added property value verification in 3 test methods |
602bb50 to
9550d22
Compare
…e VSHostObject Set DotNetSdkSupportsVSHostObjectRemoting=true in Microsoft.NET.Build.Containers.props (near CreateNewImage UsingTask) and Microsoft.NET.Sdk.Publish.targets (parent of ZipDeploy, OneDeploy, MSDeploy UsingTasks), so VS tooling can detect COM remoting support without fragile SDK version comparisons. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
9550d22 to
329ba66
Compare
src/Containers/packaging/build/Microsoft.NET.Build.Containers.props
Outdated
Show resolved
Hide resolved
rainersigwald
approved these changes
Feb 24, 2026
This was referenced Feb 24, 2026
tmat
added a commit
to tmat/dotnet
that referenced
this pull request
Mar 12, 2026
commit 3d009596d1c130ded9be7576d45a4e3cc8a31d41
Author: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Date: Thu Mar 12 08:10:03 2026 -0700
[sdk] Source update 6e514f6 → 8cbac4a
Diff: https://github.com/dotnet/sdk/compare/6e514f6189902a6422a6ab91324804c37035315b..8cbac4a5cdf27c2bb606a282cc47e60a7c4ced45
From: dotnet/sdk@6e514f6
To: dotnet/sdk@8cbac4a
[[ commit created by automation ]]
```
C:\sdk>darc vmr forwardflow --build 303236 --vmr C:\dotnet
info: Flowing build 20260224.4 (303236) of commit 8cbac4a...
info: Making sure commit '8cbac4a5cdf27c2bb606a282cc47e60a7c4ced45' is present in repository 'C:\sdk'...
info: Flowing sdk's commit 8cbac4a to VMR at C:\dotnet...
info: Last flow was back flow: d346a57 -> f284d9f49aec157d49233ab5785cbcf78ed1ea58
info: Current flow is in the opposite direction
info: Creating a working branch darc/forward/8cbac4a-d346a57
info: Synchronizing sdk from 6e514f6189902a6422a6ab91324804c37035315b to https://github.com/dotnet/sdk / 8cbac4a5cdf27c2bb606a282cc47e60a7c4ced45
info: Updating VMR sdk from 6e514f6 to 8cbac4a..
info: Rebasing darc/forward/8cbac4a-d346a57 onto UpdateSdk1...
info: Auto-resolving expected conflicts...
info: Successfully auto-resolved 1 expected conflicts
info: Resolving dependency updates in source 6e514f6189902a6422a6ab91324804c37035315b..HEAD and target d346a57..UpdateSdk1
info: Changes staged in C:\dotnet
info: PRs from original repository included in this codeflow update:
- dotnet/sdk#53090
- dotnet/sdk#52347
- dotnet/sdk#53100
- dotnet/sdk#53056
```
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Set \DotNetSdkSupportsVSHostObjectRemoting=true\ near the \UsingTask\ declarations for tasks that use \VSHostObject\ COM remoting.
This allows VS tooling (WebTools) to detect COM remoting support via a well-known property instead of fragile SDK version comparisons.
Context
Connected to #53028 — after consolidating the VSHostObject implementations, the VS side needs a reliable way to know when the SDK supports the new remotable host object protocol.
Changes