Read only the projects of a solution that hold the application - #63
Conversation
Cratis.Screenplay moves to 1.8.0 so that 'screenplay validate' compiles documents with the same compiler the shipped Stage image runs — a document the CLI gate accepted was not guaranteed to be one Stage accepts. Cratis.Arc.Screenplay moves to 21.0.1, and Chronicle and Fundamentals to their latest, none of which changes anything the CLI reads.
Cratis.Screenplay 1.7.0 added an optional 'Types' parameter to the ApplicationSyntax primary constructor. Source compatible, binary breaking: the published Cratis.Arc.Screenplay is compiled against 1.5.2, so its call site names a constructor that no longer exists and every generation ends in Method not found: 'Void Cratis.Screenplay.Syntax.ApplicationSyntax..ctor(...)' Verified against both 1.7.0 and 1.8.0. The compiler used by 'screenplay validate' therefore stays a release behind the one the Stage image runs until a Cratis.Arc.Screenplay built against 1.7.0 or later is published.
The generator can name the module of each feature after the outermost segment of its namespace, and reaches that only when nothing named a module and no single assembly names the application - so an application whose namespaces already say what its modules are comes back as one module holding every feature, with no way to ask for anything else. --modules-from-namespace-roots asks for it. Where every slice shares a root namespace, that outermost segment is the root, so it pairs with --skip-segments to move the modules down to the segment that tells them apart: Samples/Library then emits Authors, Inventory and Lending as modules rather than as features of one module Library.
Three ways a document came to describe something other than the application it names: A workspace opens a multi-targeted project once per target framework and tells the results apart by appending the framework to the name, so a project arrived as Lib(net10.0) and Lib(netstandard2.0). The spec-name test was asked of that decorated name and no longer recognized MyApp.Specs, and the dedupe grouped by it and so could never group anything - both compilations of every multi-targeted project were handed to the generator. Both questions are now asked of the name with the framework removed, and one target framework is picked deterministically. Whether a project holds part of the application is now asked of what it can see: every artifact is declared with an attribute the framework ships, so a project resolving neither the Arc nor the Chronicle one is left out. A Roslyn analyzer or a build-time tool beside the application no longer says something about the solution that is not true. Pointing at a single project still reads it whatever it can see. The host integration specs start the application in is turned away with the specs it serves, by name, because it references the same framework the application does and nothing it can see tells it apart. A solution filter is accepted and read as the solution it filters.
An unrestored project still opens and still yields a compilation - one with no package reference resolved, in which every framework type the application uses reads as missing. Generating against an unrestored solution therefore produced eleven SP0024 errors saying 'Chronicle' does not exist in the namespace 'Cratis', a 494-line document describing nobody's application, and not one word about running a restore. The assets file is asked for before anything is compiled, and its absence is reported as CLI0005 naming the projects and the command to run. Nothing is generated, because a document read from a half-resolved compilation can only mislead. Where the intermediate output folder was moved - the artifacts output layout of the SDK moves it out of the project folder - it is found through the assembly the project compiles into it, and a project neither path says anything about is taken for restored rather than failed.
|
Reviewer context. Gates. Verified end to end on a repro solution —
The baseline document contained a whole On Studio,
A question for you on the new flag. I left Not done: |
1 participant
Summary
Fixes which projects of a solution take part in Screenplay generation, and updates the Cratis packages.
Added
--modules-from-namespace-rootsonscreenplay generate, taking each outermost namespace segment as a module rather than nesting everything under one.slnfsolution filters are accepted as a generation targetChanged
Cratis.Arc.Screenplay20.68.0 to 21.0.1, Chronicle packages 16.11.0 to 16.19.1,Cratis.Fundamentals7.16.6 to 7.17.1Fixed