Repository navigation
Feat/sgf 1.2.2 aot blazor - #151
Merged
Merged
Conversation
1.2.1 copied Purview.SourceGeneratorFramework.dll to the output of every project that referenced the generator as an analyzer-only ProjectReference. Built on main, all eight sample bins carried it. With 1.2.2 only the generator and refactorings projects' own output holds it.
The SDK refreshed its managed .editorconfig, which changes only the version marker on the first line. The solution builds with no new warnings and the skill rule set passes unchanged.
…nsumers just smoke-packed-consumers packs the generator to an isolated feed and cache, then builds consumers that reference the .nupkg only, each with a class library of its own telemetry: - a Native AOT console, published with -warnaserror and run with in-process listeners and a capturing logger, asserting activities, tags, baggage, events, metrics, v1 and v2 logs, log-level gating, multi-target methods and TelemetryNames aggregation - a Blazor WebAssembly app, published trimmed and with RunAOTCompilation; the trimmed assemblies must keep every generated member, and every generated method must be AOT-compiled - a Blazor Server host, rendered on a TestServer, with the same telemetry assertions Every bin and publish folder is scanned for compiler-host assemblies by scripts/assert-no-compiler-host-assemblies.ps1 (also just scan-compiler-host-leaks).
…ach rule PackValidation ForbiddenContent now keeps Purview.SourceGeneratorFramework* and Microsoft.CodeAnalysis* out of analyzers/ (the generator ships IL-merged) and out of every folder NuGet hands to an application, and the generator and refactorings out of lib/, ref/ and runtimes/. scripts/test-pack-validation-rules.ps1 (just verify-pack-rules) injects a matching file per rule into scratch copies of the package and shows the real purview-build validation rejects each one.
The leak scan must catch every kind of leak it claims to, and fail on nothing to scan. Every workflow job that builds the samples or publishes must run it, the packed-consumers job must run the gate and the rule proof, the Justfile recipes must run their scripts, the consumers must reference the generator as a package, and no ForbiddenContent rule may be removed.
A new packed-consumers job runs the gate for linux-x64 with -WasmAot Require, then the forbidden-content rule proof. It fails at its first step, with what to do, until Purview.SourceGeneratorFramework 1.2.2 and Purview.BuildSdk 1.2.0 restore from nuget.org or the TELEMETRY_PRERELEASE_FEED repository variable. The samples job also builds SampleApp.MultiProject, and scans every sample's bin for compiler-host assemblies: that is where SGF 1.2.1 leaked its DLL.
global.json named rc.2, which is not installed here, so every local build already rolled forward to rc.3 while CI installs rc.2. The packed consumers use the rc.3 ASP.NET Core packages (Components.WebAssembly, TestHost), so CI now installs the SDK that matches them.
Release-Flow.md gains a Release gates table (what each gate proves, and where it runs locally and in CI), the prerelease build-dependency note and a pre-release checklist. release-process.md and the AGENTS.md quality gates point at it. CHANGELOG.md starts at 5.0.7-prerelease.1.
A patch prerelease: the generated code and the package contents are unchanged. The release moves the build to Purview.SourceGeneratorFramework 1.2.2 and Purview.BuildSdk 1.2.0, which are not on nuget.org yet, and adds the release gates.
…d.dll The benchmark project referenced Purview.SourceGeneratorFramework.Shared.dll as an analyzer, a file no SGF version ships (its sources are compiled into Purview.SourceGeneratorFramework.dll), so every target failed with CS0006 before the generator ran. The project sits outside src/, so Purview.BuildSdk never asked the generator for its analyzer files. The ProjectReference now names Targets="GetSourceGeneratorAnalyzerFiles", which returns the merged, self-contained generator with no framework dependency to load, in every build mode, including BenchmarkDotNet's UseSharedCompilation=false host build. That exposed net48 compile errors: ArgumentNullException.ThrowIfNull does not exist there, and the generator emits no IMeterFactory constructor on .NET Framework. CA1515 is suppressed because BenchmarkDotNet needs public benchmark types.
…s no SGF type The merge reported PSGFR41: MessageTemplateHole was the generator's only public non-component type, and its positional init accessors carry a modreq to IsExternalInit, which Purview.SourceGeneratorFramework defines publicly (by design) and the merge internalizes. Nothing outside the assembly uses it - the template tests parse into their own TestMessageTemplateHole - so it is now internal like every other pipeline model. PurviewMergePublicSurfaceSeverity is set to error in src/Directory.Build.props, so a leak like this fails the build (and the PSGFR41 analyzer fails it while editing) instead of logging a message nobody reads. ReleaseGateTests keeps that setting in place.
5.0.6 shipped a README telling consumers to install 5.0.5. The package README is src/src/SourceGenerator/Sdk/README.md, a symbolic link to the repository README.md, and its version was only ever rewritten by `just update-version`, a manual step the release pipeline does not run. The installation section now carries no version: `dotnet add package` writes the latest one, and the snippet shows the analyzer-only PrivateAssets/IncludeAssets shape without one. PackagedDocumentationTests in Repository.UnitTests fails when any packaged Sdk/*.md pins a version (a Version="..." attribute, --version/-Version switches, the Current Version marker, or a version beside the package id), and when the generator's Sdk/README.md does not resolve to README.md, as it would in a checkout without symbolic link support.
…efix
The README said OpenTelemetry naming prefixes instrument names with the meter name
("myapp.products.record.count"). It never has: MeterNameGenerationType defaults to DotNet in the
attribute, the pipeline and every version since the option arrived, and the default name is the
interface-derived prefix plus the snake_case instrument name ("product.record_count") - as the
packed consumers' "order.orders.placed" shows. The docs were wrong, and are corrected.
The opt-in MeterNameGenerationType.OpenTelemetry was wrong too. Its comment, the FAQ and the
Metrics page all describe the meter name as the outermost namespace, but it was inserted between
the interface prefix and the instrument name ("product.my_app.products.record_count"). It now
comes first ("my_app.products.product.record_count"). Only that opt-in mode changes.
The README, Metrics, FAQ, Generation and Breaking Changes pages now use one example interface,
and the Generate_GivenTheDocumentedExample* tests pin its default, OpenTelemetry-meter-name and
legacy names. A further test checks the meter name does not accumulate across instruments.
The generator implemented, and the analyzer validated, every method on a telemetry interface, static ones included. A static helper was emitted as an instance method on the generated class, and a static overload of a telemetry method was reported as a duplicate name (TSG1003). Static members are not part of what a class implements. Interfaces could declare them on .NET Core 3.0+ and .NET 7+ already, and C# 15 (.NET 11) allows non-virtual static members on older runtimes too, so they are now skipped everywhere the interface's methods are enumerated.
…ry on opt-in .NET 11 adds System.Diagnostics.ActivitySourceFactory, registered by services.AddTracing(), the tracing counterpart of IMeterFactory. [assembly: ActivitySourceGeneration(..., UseActivitySourceFactory = true)] now makes each generated class take an ActivitySourceFactory constructor parameter and create its source with Create(new ActivitySourceOptions(name)) instead of a static ActivitySource. The constructor is emitted by whichever target owns it (Logging, then Metrics, else Activities itself), so the decision lives on TelemetryCapabilities. It is gated on the compilation resolving the type, not on the TFM, because the System.Diagnostics.DiagnosticSource 11 package brings it to net462 and netstandard2.0. When the option is set but the type is missing, the static source is kept and the analyzer reports TSG3023. The option is opt-in because it changes the generated constructor. The integration tests gain a net11.0 leg, where the factory tests run; the fallback tests run on the earlier legs. In the packed-consumer gate every consumer assembly opts in (the library does not) and calls AddTracing(); the Native AOT console and Blazor Server host assert the orders source was created by the factory and the library's was not, and the Blazor WebAssembly checks require InitializeActivitySource to survive trimming and be AOT-compiled. The consumers' Microsoft .Extensions.* packages move to the .NET 11 version they target, for AddTracing(). RS2002 joins RS2003 in NoWarn: release tracking cannot follow the analyzer's descriptors, so an unshipped rule is reported as unsupported for the same reason the shipped ones were.
…et supported Adds docs/wiki/Platform-Support.md: what's new for .NET 11, the target-framework and hosting matrix (console, ASP.NET Core, Aspire, Native AOT, Blazor WebAssembly trimmed and AOT, Blazor Server, .NET Framework) with the gate that verifies each, the trim/AOT guarantees, the .NET 11 features with their minimums, and a "Not yet supported" table with primary sources. Activities documents UseActivitySourceFactory, Diagnostics documents TSG3023, Installation and Home cover .NET 11 and the shared-framework abstractions, and the README gains a "What's new for .NET 11" section. Its usage sample now compiles, and its Agent Skills section names the real install command. AGENTS.md records the net11.0 test leg and the rule to gate new APIs on the compilation. The quickstart skill pinned 4.5.0 and named skills that do not exist, and the design skill claimed a meter-name prefix by default. All three are corrected, and the diagnostics skill lists TSG3023.
Adds the opt-in .NET 11 ActivitySourceFactory generation (TSG3023 when unavailable), and fixes the MeterNameGenerationType.OpenTelemetry ordering, static interface members, the packaged README version, the PSGFR41 public-surface leak and the benchmark build.
TSG1011 told consumers that defining PURVIEW_TELEMETRY_NON_NULLABLE suppresses it. Nothing ever implemented that. The message arrived with the net48 work in #91, while the framework check only read NET8_0_OR_GREATER and NET48_OR_GREATER, and IsUnsupportedTargetFramework kept that shape. The define did still do one thing. The marker attribute files used it, beside NET48_OR_GREATER, to omit the #nullable enable directive and declare plain string members. That opt-out goes with it, so the marker attributes now switch on NET48_OR_GREATER alone. A net8.0+ project that defined it gets the string? declarations every other modern project gets, which accept everything plain string did. The TSG1011 message now says nothing is generated for the target, and names net8.0+ and net48+ as the way out, with a conditional package reference for a multi-targeted library. The wiki, the diagnostics skill and the net48 sample README drop the define. UnsupportedTargetFrameworkTests pins the message and shows the define no longer suppresses the diagnostic. MarkerAttributeNullabilityTests pins the marker guard.
The skills installed from other repositories are kept in source again. .agents/skills/ and the
skills CLI's skills-lock.json had been left untracked, and were then deleted from a working tree
as if they were throwaway install output.
Restored with the skills CLI, into the universal .agents/skills/ location and nothing else:
npx -y skills@1 add purview-dev/sourcegenerator-framework -s '*' -a universal -y
npx -y skills@1 add purview-dev/build-sdk -s '*' -a universal -y
That is the six purview-sourcegenerator-* skills the tree had before, plus the eight
purview-buildsdk-* skills AGENTS.md has always told contributors to install.
/.claude/ is now gitignored, and src/Directory.Build.props sets PurviewSkillsAgents to universal,
so the SDK's InstallPurviewSkills target no longer defaults to writing a copy for every agent.
InstalledSkillTests checks that the lockfile and .agents/skills/ agree, and that no .claude/skills/
copy exists.
AGENTS.md said .agents/ was a gitignored, package-delivered mirror and that skills-lock.json went with it. Neither is true. The installed skills and the lockfile are committed, and are written only into .agents/skills/ by the skills CLI with -a universal. The new Installed skills section lists each skill, its source and when to load it, and gives the commands to add, update and restore them. The copilot instructions and the Contributing page pointed at a Source-generator and testing skills section that no longer existed, and now point at that one.
Rewords TSG1011 so it no longer offers the PURVIEW_TELEMETRY_NON_NULLABLE opt-out, which never suppressed it, and removes that define from the generated marker attributes.
…ew repos Adds the two checks zodsharp and sourcegenerator-framework already carry: the authored skills in skills/ are never copied into .agents/skills/, and no CLAUDE.md is added beside AGENTS.md.
…own-skills rule Every purview repository installs purview-dev/engineering-playbook alongside build-sdk, with -a universal only. AGENTS.md lists the six skills and says that this repository's own skills in skills/ are for consumers and are never installed into its .agents/skills/.
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.
No description provided.