Repository navigation
fix: keep a component's own internals grants through the merge, and r… - #38
Merged
Merged
Conversation
…elease 1.0.0 A code-fix component that reads its generator's internal diagnostic identity compiled, passed its in-repo tests, and then threw FieldAccessException in the compiler host. The merge tool's StripInternalsGrants removed every assembly-level InternalsVisibleTo from the merged artifact, so the merged generator the IDE loads no longer granted access to the merged code fix. In-repo tests bind the unmerged bin output, which keeps the grant, so nothing caught it. Verified on this repository's own ComponentClosureFixture - built for exactly this scenario, with a non-const internal field so the assembly reference survives: Fixture.Generator.dll (bin, unmerged) 116 grants, including Fixture.Generator.CodeFixers Fixture.Generator.dll (merged analyzer) 0 The grants are now stripped by provenance. The tool already receives the framework assembly separately, so it strips only framework-authored grants and keeps the ones the component wrote. That preserves the documented intent - a shipped analyzer is not the framework's assembly, and a leftover framework grant would let the framework's own test assemblies reach the internalized framework types - without breaking the supported component-to-component arrangement. End to end on the fixture the merged artifact goes from 0 grants to 24 including Fixture.Generator.CodeFixers, with 0 framework grants. CollectInternalsGrants reads an assembly's grants, Apply takes them as frameworkInternalsGrants, and omitting the argument strips everything as before, so the existing behaviour and its test are unchanged. The namespace workarounds this repository needed are gone: Purview.BuildSdk 1.0.3 no longer strips Roslyn component names from RootNamespace, so SourceGeneratorFramework.Analyzers, .Generators, .CodeFixers and .ExampleGenerator.CodeFixers - and their test projects - build clean with no NamespaceRemoveSuffix opt-outs at all. That is what confirms the SDK change was the right fix rather than a workaround moved upstream. First stable release. Adopts Purview.BuildSdk 1.0.3, up from 1.0.0-prerelease.60. Tests: 3752 passing, including the closure-fixture build integration tests that previously failed.
kieronlanning
enabled auto-merge
October 6, 2026 22:41
kieronlanning
disabled auto-merge
October 6, 2026 22:46
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
1 participant
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.
…elease 1.0.0
A code-fix component that reads its generator's internal diagnostic identity compiled, passed its in-repo tests, and then threw FieldAccessException in the compiler host. The merge tool's StripInternalsGrants removed every assembly-level InternalsVisibleTo from the merged artifact, so the merged generator the IDE loads no longer granted access to the merged code fix. In-repo tests bind the unmerged bin output, which keeps the grant, so nothing caught it.
Verified on this repository's own ComponentClosureFixture - built for exactly this scenario, with a non-const internal field so the assembly reference survives:
Fixture.Generator.dll (bin, unmerged) 116 grants, including Fixture.Generator.CodeFixers
Fixture.Generator.dll (merged analyzer) 0
The grants are now stripped by provenance. The tool already receives the framework assembly separately, so it strips only framework-authored grants and keeps the ones the component wrote. That preserves the documented intent - a shipped analyzer is not the framework's assembly, and a leftover framework grant would let the framework's own test assemblies reach the internalized framework types - without breaking the supported component-to-component arrangement. End to end on the fixture the merged artifact goes from 0 grants to 24 including Fixture.Generator.CodeFixers, with 0 framework grants.
CollectInternalsGrants reads an assembly's grants, Apply takes them as frameworkInternalsGrants, and omitting the argument strips everything as before, so the existing behaviour and its test are unchanged.
The namespace workarounds this repository needed are gone: Purview.BuildSdk 1.0.3 no longer strips Roslyn component names from RootNamespace, so SourceGeneratorFramework.Analyzers, .Generators, .CodeFixers and .ExampleGenerator.CodeFixers - and their test projects - build clean with no NamespaceRemoveSuffix opt-outs at all. That is what confirms the SDK change was the right fix rather than a workaround moved upstream.
First stable release. Adopts Purview.BuildSdk 1.0.3, up from 1.0.0-prerelease.60.
Tests: 3752 passing, including the closure-fixture build integration tests that previously failed.