Drastically simply packing and namespace management #53
Conversation
|
🧪 Details on macOS Unix 14.7.2✅ StructId.CodeTemplateTests.AddsStructIdNamespace 🧪 Details on Ubuntu 22.04.5 LTS✅ StructId.CodeTemplateTests.AddsStructIdNamespace 🧪 Details on Microsoft Windows 10.0.20348✅ StructId.CodeTemplateTests.AddsStructIdNamespace from dotnet-retest v0.6.3 on .NET 8.0.11 with 💜 |
The ability to customize the namespace of the struct id types seemed a bit of a corner case and it was introducing non-trivial complexity in scenarios involving transitive project references (analyzers are transitive, as well as buildTransitive targets, but analyzer options, contentFiles -with or without compile action- are not). This was leading to hack over hack for no serious gain. So even if we keep the CodeTemplate behavior intact should we figure out how to properly handle changing the namespace, this change removes the copying and content updating on the static files, which are now simply included via nuget's contentFiles feature plus buildAction=Compile. This provides the behavior we're looking for: - Interfaces and types required for struct ids are only added to the project referencing the package - using and codegen for struct ids is supported in projects referencing the "core" one: analyzers are already transitive, we just make the templates transitive too via targets (since we can't via contentFiles).
The ability to customize the namespace of the struct id types seemed a bit of a corner case and it was introducing non-trivial complexity in scenarios involving transitive project references (analyzers are transitive, as well as buildTransitive targets, but analyzer options, contentFiles -with or without compile action- are not). This was leading to hack over hack for no serious gain.
So even if we keep the CodeTemplate behavior intact should we figure out how to properly handle changing the namespace, this change removes the copying and content updating on the static files, which are now simply included via nuget's contentFiles feature plus buildAction=Compile. This provides the behavior we're looking for: