Supported repository types

Doc gen does not document every repository the same way. Before it writes anything, it classifies the repository, and that classification decides which documents get produced, which analysis skills are applied, and which section of this portal the results land in.

This page describes the repository types Legends supports, how each one is recognized, and what you get for it.

Quick lookup

Type	Supported variants	Support
Framework	.NET Framework libraries (BOF, Framework4); .NET (NCore) libraries	✅ Full
Component	.NET Framework and .NET (NCore) libraries	✅ Full
Front End	BOF WebForms; .NET Framework 4 MVC / Razor; ASP.NET Core Razor Pages	✅ Full
Console App	BOF batch; Framework4 console	✅ Full
Rest API	.NET Framework 4 Web API; ASP.NET Core Web API; API client packages (.NET Framework 4 and ASP.NET Core)	✅ Full
SOAP Service	WCF; ASMX; SOAP client proxies	✅ Full
Desktop App	Windows Forms, WPF	⚠️ Recognized only, no purpose-built documents
Windows Service	ServiceBase, Windows Worker Service	⚠️ Recognized only, no purpose-built documents
Not supported	ASP.NET Core MVC with Views, Blazor, JavaScript front ends	❌ Raise before starting

Variant details

Once you know your type, this table shows how each variant is recognized, where its documents live, and which portal section lists it. All variants of a type record the same type in the manifest.

Type	Variant	Typical repository	Documentation root	Portal section	Support
Framework	.NET Framework libraries (BOF, Framework4)	Repository name contains "Framework"; class libraries only	docs/libraries/<slug>/	Package Libraries	Full
Framework	.NET (NCore) libraries	SDK-style class libraries on modern .NET, packed by a pipeline	docs/libraries/<slug>/, plus service-registration.md where applicable	Package Libraries	Full
Component	.NET Framework or .NET (NCore) libraries	Mid-tier class libraries consuming Framework packages	docs/libraries/<slug>/	Package Libraries	Full
Front End	BOF WebForms	.aspx pages with BOF code-behind and Infragistics controls	docs/application/, docs/screens/	Web	Full
Front End	.NET Framework 4 MVC / Razor	ASP.NET MVC 5 with Razor views and SAIF MVC controller bases	docs/application/, docs/screens/	Web	Full
Front End	ASP.NET Core Razor Pages	Core Razor Pages host built on SAIF.NCore and BolMiddleware	docs/application/, docs/screens/	Web	Full
Console App	BOF batch	VB batch job deriving from clsBatchBase	docs/applications/<app-slug>/	Console	Full
Console App	Framework4 console	C# job built on SAIF.Framework.Windows	docs/applications/<app-slug>/	Console	Full
Rest API	.NET Framework 4 Web API	ASP.NET Web API 2 hosted in IIS through Global.asax	docs/apis/<api-slug>/	REST APIs	Full
Rest API	ASP.NET Core Web API	Microsoft.NET.Sdk.Web host with controllers or minimal APIs, no UI	docs/apis/<api-slug>/, plus hosting-pipeline.md	REST APIs	Full
Rest API	API client packages (.NET Framework 4 or ASP.NET Core)	NuGet package wrapping a SAIF REST API	docs/clients/<client-slug>/	REST APIs, cross-listed in Package Libraries	Full
SOAP Service	WCF	.svc, ServiceHost, or [ServiceContract]	docs/services/<service-slug>/	Web Service	Full
SOAP Service	ASMX	.asmx web service hosted through Global.asax	docs/services/<service-slug>/	Web Service	Full
SOAP Service	SOAP client proxies	Package wrapping a consumed SOAP service	docs/clients/<client-slug>/	Web Service, cross-listed in Package Libraries	Full
Desktop App	Windows Forms, WPF	Desktop executable	General document set only	Own section named after the type	Recognized only
Windows Service	ServiceBase, Windows Worker Service	Background service executable	General document set only	Own section named after the type	Recognized only
Not supported	ASP.NET Core MVC with Views, Blazor, JavaScript front ends	—	—	—	Raise before starting

Two classifications, not one

A repository is classified along two independent axes. Both end up in the repository's docgen-manifest.md.

Axis	Values	What it decides
Documentation type	Framework, Component, Front End, Console App, Rest API, SOAP Service, Desktop App, Windows Service	Which documents are generated, and which portal section the repository is filed under.
Technology	bof, framework4, ncore, unclassified	Which technology-specific analysis and writing skills apply — for example SAIF BOF data access versus NHibernate, BOF batch versus Framework4 console, or .NET Framework versus .NET (NCore) library conventions.

The two are orthogonal. A Front End repository can be BOF or Framework4, and a Framework repository can be either as well. Technology is determined per library from its package and project references: a *.BOF.* reference means bof, a SAIF.Framework.* package reference means framework4, and neither means unclassified — doc gen will not guess from the absence of evidence. The one exception is checked first and comes from the project file rather than a reference: an SDK-style project whose every target framework is modern .NET (net5.0 and later, netstandard*, netcoreapp*) is ncore, because it cannot load a .NET Framework assembly. A project that multi-targets a net4* framework alongside modern ones keeps its bof or framework4 value and additionally gets the NCore packaging treatment.

For a Front End, the library technology does not decide which kind of web application it is. A Razor front end can consume *.BOF.* packages and still have no WebForms in it; the UI flavor is decided separately, from the entry-point project alone (see Front End).

Classification is computed, not judged

Doc gen does not ask you what kind of repository you have, and it does not decide by reading the code and forming an opinion. It works from evidence, in this order:

1. The deployment pipeline. A pipeline referencing the deploy-stages-web-iis.yml template is a web application. One referencing build-steps-console.yml ships a console executable. Pipeline evidence overrides everything else.
2. Entry-point project types. Absent a pipeline marker, an ASP.NET Web API or ASP.NET Core Web API entry point makes it a REST API; a WCF or ASMX entry point makes it a SOAP service; a web or desktop entry point (ASP.NET WebForms, MVC, ASP.NET Core Razor Pages, Blazor, WPF, WinForms) makes it a front-end application; a Console or Windows Service entry point makes it a console application.
3. No entry point at all. The repository is library-only, and the repo name decides between Framework and Component.

The API branch is evaluated before the web branch

A REST API is not a front end. Web API used to be treated as a web entry point, which routed API repositories into the screen and application phases and produced screens and navigation flows for a service that has no user interface. API detection now runs first, specifically to prevent that.

The reverse mistake is also guarded against. SAIF MVC controllers derive from SAIF base classes shipped in packages, so their inheritance chain never visibly reaches ASP.NET's Controller; that once made MVC front ends — and some BOF front ends — look like REST APIs. Those SAIF controller bases are now recognized as MVC, so a front end that merely references System.Web.Http is no longer filed as an API.

A repository currently gets one documentation type. When more than one could apply, the highest tier wins:

Windows Service → Desktop App → SOAP Service → Rest API → Front End → Console App → Component → Framework

The manifest records a one-sentence classification basis explaining the decision, so you can check the reasoning during review.

Repositories that are genuinely more than one thing

Tiering is how the tooling copes today, not a statement that a repository can only be one thing. A repository that ships, say, a REST API and a console job really does contain both, and the lower-tier half is documented as libraries rather than getting its own document set. Support for documenting multiple types in a single repository is planned; until it lands, note the gap in review rather than treating the classification as wrong.

Fully supported types

These six types have dedicated analysis prompts, writing prompts, templates, and review rules. They are what the tooling is built and tested against.

Framework

Lowest-level shared libraries — the repository name contains "Framework" and every project is a class library with no program entry point. These are the packages everything else is built on.

Documentation is library-centric, one set per library under docs/libraries/<slug>/: overview, architecture, public API reference, business rules, an operation catalog with a page per operation, dependencies, and configuration. A packages.md at the repository root lists what the repository publishes.

.NET (NCore) libraries. SDK-style libraries on modern .NET — the shape of Framework.NCore — use the same document set, with differences that follow from how they are built and consumed:

• Packages are found without a .nuspec. The .csproj is the package manifest, and the packaging pipeline decides which projects ship. A project also qualifies when a packed project bundles its assembly into its own package (PrivateAssets="All" plus custom packing code). packages.md reports the pack method, target frameworks, package ID, and every bundled assembly rather than inventing a .nuspec.
• Configuration is .NET configuration. configuration.md documents IConfiguration, options binding, IEnvironmentClient, and environment variables — not an <appSettings> catalog.
• service-registration.md is added when the library exposes IServiceCollection / IHostBuilder / IApplicationBuilder extensions, startup base classes, middleware extensions, or hosted services. It catalogs each registration extension, the services it registers and their lifetimes, and what a host must still register itself.
• Target frameworks are checked. An end-of-support or malformed target framework (for example .net8.0) is recorded as tech debt.

Portal section: Package Libraries.

Component

Mid-tier libraries that consume Framework packages and are consumed in turn by applications. Like Framework repositories, they have no program entry points — the difference is tier, not shape.

Component repositories produce the same library document set as Framework repositories, including the NCore variant described above. They are separated so the portal can present the platform layer and the business-component layer independently.

Portal section: Package Libraries.

Front End

Web applications — ASP.NET WebForms, ASP.NET MVC, or ASP.NET Core Razor Pages. This is the richest document set, because a web application is documented at three levels:

• Screens, under docs/screens/ — one page per screen covering purpose, controls, navigation, and a flow diagram, plus a screen index.
• The application, under docs/application/ — overview, architecture, dependencies, an operation catalog and per-operation pages, application-wide business rules, data model, configuration, security and authorization, and a tech debt register.
• Its libraries, under docs/libraries/ — the same per-library set a Framework or Component repository gets, for every library the application carries.

Front End repositories also get a dependency-scoping pass first, so that libraries pulled in only as third-party noise are not documented as if they were part of the application.

Front End splits into three variants, and the split matters because they are built on entirely different runtimes. Documenting a Razor application with the WebForms pipeline would invent an Infragistics component map and postback behavior that the application does not have, and documenting an ASP.NET Core Razor Pages application as MVC 5 would invent controllers, Global.asax, and an Autofac composition root.

	BOF WebForms	.NET Framework 4 MVC / Razor	ASP.NET Core Razor Pages
Recognized by	Served .aspx pages; code-behind inheriting the BOF page and controller bases	Views\*.cshtml Razor views; controllers deriving from a SAIF MVC base (MenuControllerBase, WebContextControllerBase, ClaimControllerBase, PolicyControllerBase); a RazorViewEngine registration	Entry type ASP.NET Core Razor Pages: AddRazorPages / MapRazorPages, a BolRazorLayoutStartup or OidcRazorStartup subclass, and Pages\*.cshtml — with no AddControllersWithViews, Blazor, Views\*.cshtml, or .razor files alongside
A screen is	An .aspx page	A compiled controller action that returns a full view	An @page file with its page model
UI controls	Infragistics, through SAIF.Presentation	Kendo UI, knockout, and Bootstrap	Tag helpers and HTML controls, with Kendo UI widgets where used, inside BolMiddleware layouts
Architecture page covers	The BOF MVC hybrid pattern and page lifecycle	The Global.asax start-up pipeline, route table, controller hierarchy, and Autofac composition root	Host start-up call by call, the middleware order, the Razor Pages route table, the page-model hierarchy (BolContextModel → BolMenuModel → BolPolicyModel), layouts, the Microsoft DI composition root, and the client-side stack
Extra page	—	docs/application/hosted-endpoints.md, when the application hosts Web API, JSON, or grid actions	docs/application/hosted-endpoints.md, when the application hosts JSON, partial, or file handlers

All three variants record the same Front End type in the manifest and land in the same portal section, so tell them apart by the documents: BOF screen pages describe .aspx controls, Framework 4 Razor screen pages describe controller actions and views, and Core Razor Pages screen pages describe page handlers and their routes. Only the Razor variants can have a hosted-endpoints.md. A few things are specific to the Razor variants and worth knowing during review:

• The pipeline and project type cannot tell the variants apart. All three deploy through deploy-stages-web-iis.yml with AppType: web, and the Framework 4 Razor applications still carry the WebForms project type GUID. Only the UI layer of the entry-point project decides — not the repository name either: Policy.BOF.Web.PHPortal is a Razor application. A .cshtml file cannot tell MVC 5 from Razor Pages, so for ASP.NET Core the entry type itself is decisive.
• The project file defines the screens, not the file system. Only controllers and views that are compiled into the project are documented. Controllers left on disk but excluded from the .csproj are dead code; the screen index names them rather than documenting them as screens. For Razor Pages, the screen index is reconciled against the @page files, not against the page models.
• Hosted endpoints are not a REST API. An incidental ApiController, or a JSON, Kendo grid, or remote-validation action, exists to serve the application's own screens. These are catalogued once on hosted-endpoints.md and linked from each screen that calls them — never published as a separate set under docs/apis/.
• The composition root lives in a companion project. Framework 4 Razor applications keep their Autofac registrations in a sibling SAIF.DependencyMaps.Web.<App> project. That project is treated as part of the application and documented on docs/application/architecture.md, not as a library under docs/libraries/.

Two things are specific to ASP.NET Core Razor Pages:

• Much of the behavior comes from a package. These applications are built on SAIF.NCore and the BolMiddleware component library, so start-up, layout, menu, policy context, and authorization behavior is often contributed by a base class the application source does not show. That behavior is documented from the package documentation and marked † (or ** when it cannot be verified) — never written as an application fact and never left out.
• Core vocabulary, not MVC or WebForms. Operations are written as VERB /<Page>?handler=<Name>, access comes from [SecurityApiAuthorize] on the page model rather than [SaifAuthorize], and each application states whether anti-forgery validation covers its POST handlers. Postback, ViewState, Controller/Action, and an Infragistics section have no place in these documents.

A web entry point with no marker for any variant falls back to BOF WebForms, and doc gen records a warning asking for the flavor to be confirmed. As with the console fallback, that is worth catching in review.

ASP.NET Core MVC with Views and Blazor are not supported

An ASP.NET Core host that uses AddControllersWithViews, Views\*.cshtml, or Blazor components is not a Razor Pages application, and there is no purpose-built pipeline for it. Doc gen is instructed to report such a host rather than force it through the Razor Pages (or any other) front-end pipeline, and JavaScript front ends (Angular, React) are in the same position. Raise these before starting a run so the scope can be set deliberately.

Front ends previously filed as REST APIs

Before MVC / Razor support existed, several Razor front ends — and a few BOF front ends — were classified as Rest API. If a web application appears under REST APIs with endpoint pages instead of screens, re-run doc gen against the source repository; it now classifies as a Front End.

Portal section: Web.

Console App

Batch jobs and scheduled executables. Documentation lives under docs/applications/<app-slug>/ and is oriented around running the job rather than calling an API: overview, architecture, batch or run lifecycle, dependencies, business rules, an operational runbook, data model, configuration, tech debt, and an operation catalog with per-operation pages. Libraries embedded in the repository are documented underneath the application.

Console App splits into two variants on the technology axis, and the difference matters because the two frameworks behave differently:

Variant	Recognized by	Documented specifics
BOF console	Inherits clsBatchBase; *.BOF.* references	Batch streams, return codes, BOF batch lifecycle
Framework4 console	Consumes SAIF.Framework.Windows; inherits SaifStandardProgramBase / ConsoleBase	Runner and argument container, Initialize/Execute/Finish lifecycle, dependency registration, log destinations, exit-code map

Source markers win over package references, because a package reference can be inherited transitively. When a console entry point exists but no marker is found, doc gen falls back to the BOF variant and records a warning naming the evidence it looked for — worth catching in review.

Portal section: Console.

Rest API

REST services come in two variants: .NET Framework 4 services (ASP.NET Web API 2 controllers hosted in IIS through Global.asax) and ASP.NET Core Web API services (controllers or minimal APIs on a Microsoft.NET.Sdk.Web host). Both are filed under the same type. Documentation lives under docs/apis/<api-slug>/ and is organized around the route table, because a REST API's interface is its route table: overview, architecture (hosting model, request pipeline, composition root, error handling), an endpoint catalog with a page per controller, per-operation pages, authentication and authorization, dependencies, configuration, end-to-end service workflows, business rules, data model, operational runbook, and tech debt. Libraries the service carries are documented alongside under docs/libraries/.

There is no screens/ folder and no application/ folder. A REST API has no user interface, and the stock MVC scaffolding that the Visual Studio Web API template ships in every one of these repositories — HomeController, Views\, Areas\HelpPage\, RouteConfig, BundleConfig, FilterConfig — is ignored outright, noted once in overview.md and documented nowhere else.

Detection is deliberately strict, and the pipeline AppType variable does not get a vote: at least one SAIF API ships AppType: web while being a pure REST service. What decides it is source evidence in the entry-point project — a controller resolving to System.Web.Http.ApiController, directly or through a repository-local base class such as ApiBase : ApiController, or a MapHttpAttributeRoutes() / MapHttpRoute(...) registration.

An ASP.NET Core Web API is detected the same way, from the project rather than the pipeline: a Microsoft.NET.Sdk.Web SDK project with an API signal ([ApiController], a ControllerBase subclass, Map<Verb> minimal-API calls, AddControllers(), or a CoreAPIStartup subclass) and no Razor or Blazor UI. A SAIF.NetCore.* package reference alone is not evidence that a project is a host. The Core variant differs from Framework 4 in these ways:

• An extra hosting-pipeline.md documents the ordered middleware pipeline.
• Route templates are resolved. [controller], [action], and {version:apiVersion} are substituted so every endpoint shows its real URL; minimal-API endpoints are catalogued alongside controller actions.
• Configuration is .NET configuration: appsettings*.json, options binding, IEnvironmentClient / settings.yml, and environment variables.
• The composition root is Microsoft DI, not Autofac. Behavior contributed by a package base class such as CoreAPIStartup is documented from the package documentation and marked † rather than written as an application fact.

A few things this document set records as findings rather than assuming, because they genuinely vary between services: the routing mode (attribute versus convention) and whether versioning exists, the authorization mechanism, the error-handling mechanism, whether Swagger is active, and where the Autofac composition root actually lives. "None found in code" is a legitimate result for several of these — worth knowing during review, because it means the absence was checked rather than skipped.

Portal section: REST APIs.

API client packages

NuGet packages that wrap a SAIF REST API get their own document set under docs/clients/<client-slug>/: overview, architecture, package identity, a full public member reference, a method-to-endpoint map, consumption guidance, contracts, dependencies, and tech debt.

This is a per-library classification rather than a repository type, which matters in practice:

• A repository shipping an API and its client together stays a Rest API repository and documents both in one pass. That is the normal case, not a conflict, and it does not need two runs.
• A repository shipping only client packages classifies as a standalone client package repository.

Both of the following must hold before a .NET Framework library is treated as an API client: a SAIF.Web.API.Clients dependency and JsonHttpClient / ClientInfo usage in its source. A .Client name suffix on its own proves nothing, an AppType: nuget pipeline proves nothing, and consuming someone else's client is not the same as producing one.

ASP.NET Core clients follow the same document set but are detected differently. All of these must hold: an SDK-style project on a modern .NET target; a PackageReference to a SAIF.NetCore client package (SAIF.NetCore.ServiceExtensions, SAIF.Http.ResponseValidator, and similar); an IHttpJsonClient source marker; a single file declaring both the *Client class and its HTTP wrapper; and the project is not an entry point. A Core client must also be packaged to get a document set — packed by the pipeline, a real .nuspec, or a pipeline file named after the client (for example DestinationRedirectorApi_Client.yml). <IsPackable>false</IsPackable> defeats it. A detected but unpackaged client produces a warning, not documents.

For Core clients, package.md describes the SDK project and consumption.md covers the DI registration extension. When the API is documented in the same run, endpoint-map.md gains a ## Route drift section comparing client routes with the API's actual routes. The manifest records each client's framework as net4 or ncore.

Client documentation always lives under docs/clients/, never nested beneath the API it wraps, because clients are released and consumed independently of the service.

Portal section: both. A client is owned by its API, so it is listed on the REST APIs page directly after that API — but it is also a package library, so the portal cross-lists it in an API Clients section on the Package Libraries page. Both entries link to the same document set; nothing is duplicated. Consumers looking for a package to reference find it where they expect, without the client being separated from the service it wraps.

SOAP Service

.NET Framework services exposed over SOAP — classic ASMX web services (.asmx, hosted through Global.asax) and WCF services (.svc, a ServiceHost, or a class carrying [ServiceContract]) alike. Both variants are documented and filed under the same type; the manifest's classification basis records which one a given repository actually is.

Documentation lives under docs/services/<service-slug>/, one set per hosted service, cataloged by a top-level docs/services/index.md: overview, architecture (hosting model, binding and endpoint configuration, message pipeline), a contract catalog with a page per service contract, per-operation pages, dependencies, configuration, business rules, and tech debt. As with Rest API repositories, libraries the service carries are documented alongside under docs/libraries/.

A repository hosting more than one SOAP or WCF endpoint — a common shape for these older services — gets one full document set per host project, not one merged set; each shows up as its own entry under Web Service on the portal.

Portal section: Web Service.

SOAP client proxies

Packages that wrap a consumed SOAP service — whether a generated wsdl.exe / svcutil.exe proxy or a hand-written client — get the same treatment REST API clients do: their own document set under docs/clients/<client-slug>/, listed directly after the service they wrap when that service is documented in the same run, and cross-listed in the API Clients section on the Package Libraries page. A proxy for a service that lives in another repository, or that was not documented in the same run, is still documented but cannot be linked to a specific service entry — it is listed as unattributed instead of being dropped.

Recognized, but not purpose-built

The remaining two types are valid classifications that doc gen will assign and record in the manifest. What they do not have is a dedicated document set.

Type	Recognized by
Desktop App	Top-level project is a Windows Forms or WPF application
Windows Service	Top-level project is a Windows Service (ServiceBase, or a Worker Service targeting Windows)

In practice these repositories are still documented — the cross-cutting analysis (security and authorization, SQL catalog, stored procedures, configuration) runs for every repository type, and the library-level document set is produced for the libraries they contain. What you do not get is an application-level document set written for that specific shape: the application itself is routed through the nearest existing pipeline (WPF and WinForms projects through the Front End pipeline, Windows Services through the Console pipeline), so expect review warnings and sections that fit loosely.

Not supported

These are not recognized as a type at all and have no pipeline. Doc gen is instructed to report them rather than force them through another pipeline:

• ASP.NET Core MVC with Views (AddControllersWithViews, Views\*.cshtml)
• Blazor applications (.razor components)
• JavaScript front ends (Angular, React, and other SPAs)

A Blazor entry point that reaches the web branch would otherwise fall back to BOF WebForms with a warning, which produces misleading documents — treat that warning as a sign the repository is out of scope.

Unmapped types create their own portal section

This portal maps Framework and Component to Package Libraries, Front End to Web, Rest API to REST APIs, Console App to Console, and SOAP Service to Web Service. Any other type publishes into a new top-level section named after itself. If an unexpected tab appears after an import, check the manifest type before assuming the portal is wrong; see Publishing to the portal.

If you have one of the unsupported repository types to document, it is worth raising before you start, so the run can be scoped deliberately rather than discovering the gap during review.

Where the classification is recorded

Every documented repository carries a docgen-manifest.md at its root with a ## Documentation type section:

## Documentation type

**Type:** Framework

**Classification basis:** Repo name contains 'Framework' and all projects are
class libraries with no entry points.

That file is the contract between doc gen and this portal. The import scripts read **Type:** to decide which section the repository belongs in, and a repository without a readable manifest is skipped entirely.

If the type looks wrong

The classification is derived from the source repository, so that is where it gets fixed — never by editing the imported copy in this portal, which is overwritten on the next import.

• Wrong type recorded. Check the classification basis in the manifest first; it usually reveals which piece of evidence was misread. Correcting the underlying signal (a missing pipeline template reference, an entry-point project that should not be one) and re-running doc gen is better than editing the manifest by hand.
• Right type, wrong documents. That is a documentation defect rather than a classification problem. Use the bugfix flow in Bugfix / quick fix.
• Not sure what the output should look like. Compare against Document examples, which are grouped by repository type.