JetBrains.Platform.BuildEngine

Expands file items by unpacking certain kinds of containers: • NuGet package. • Structured Storage with in it.

Accepts either DLL files AS IS or these kinds of containers: • NuGet package. • Structured Storage with in it. Not expecting nesting of containers. Only top-level files are checked for being containers.

The list of expanded files. For each of the files, also specifies its parent conatiner path, for tracking the file origin in case of any conflicts.

Whether it's known if a part catalog should be attempted for this assembly. Allows skip third-party assemblies, including extarcting them from a nuget, unless it's resolved for.

Where it comes from, e.g. unpacked from a nuget.

The cached part catalog that contains this item, if available.

Accepts log records on any thread, yields them to consumer (e.g. a ListEvents for binding to UI) in the main thread.

Incoming action. Initiates an outgoing action, if created on an STA. Otherwise, just does the outgoing with all the necesary locking.

MUST be run on the home thread, if created on STA. Otherwise, free-threaded. Flushes the messages still in queue, makes them reach the output func immediately.

Exposes some of the context which is available to the running Isolated Build guest (guest means we're in the guest appdomain context, rather than the side which spins up the isolated build). This derived interface adds some of the engine-specific stuff which is not available on the Build Interfaces level.

Gives the assemblies with the build runner engine implementation which is currently running.

The buidl request for the build which is currently running.

Proxy for calling from another appdomain, because the only possible cross-appdomain call is a ctor call.

Invokes the proxy assembly so that it invoked the from the isolated build engine loaded into the isolated appdomain, whichever it is (shipped or from package). The proxy assembly is expected to be already emitted and saved to the basedir of the isolated appdomain, so that it could be loaded on demand. So as the engine assemblies.

Does the run. Should be called already in the guest appdomain.

A part of the responsible of making the build part catalog out of what's given as build script sources and binaries.

Exposes some of the context which is available to the running Isolated Build guest (guest means we're in the guest appdomain context, rather than the side which spins up the isolated build).

Represents a separate appdomain with a codebase in a TEMP location which has all the assemblies

The pointer which is passed AS IS across the appdomains. Previously, it's the raw COM object pointer. Next gen, it's the structure in global memory. NG++, it's the string with path for in global memory.

Worker thread, main appdomain.

Allows to read/write the structured storage which is passed across appdomains, to the isolated build guest.

Build env params, like Nuget connection.

Writes graphs for build storage, build plan, etc when in Guest. Due to nested builds, there might be more than one.

What and how to build, serialized with based on .

Build engine parameters.

Assembly unification, to be used outside and in the appdomain.

The assemblies of the build engine iself. Built-in version, and the proxy assembly. Always defined.

The artifacts in the build storage after the build is run.

Graph with build execution plan.

Graph with build entities in the storage.

MMF for piping the log messages out of the build.

Change whenever format/semantic of this data changes.

Must never change.

Integrity check (points to the valid structure).

Versioning check.

Mostly used for access control.

Handle to the memory-mapped file.

Size of the memory-mapped file.

The number of bytes actually written into the memory-mapped file, what must be returned as stream length or lockbytes stat size. ACHTUNG: this is a mutable field, so it's critical that the stream were opened on exactly the same pointer instance.

Bank size for the bank-switching memory stream.

Opens on the existing memory. Make sure you don't open two accesses at a time.

Lifetime for just this stream. Pointer to the struct. MUST be mutable!

Creates a new MMF and wraps into this structure.

Lifeitme of the MMF validity. Must stay alive while your clients are using this data.

Classic. Create with , pass as a raw COM pointer.

NG. Create an MMF, alloc in global memory and fill, pass that pointer. The memory layout is managed with a DocFile.

NG. Create an MMF, alloc in global memory and fill, pass that pointer. The memory layout is managed with a ZIP SSTG.

NG++. Create a , alloc path folder in global memory and fill, pass that pointer.

NG#. Create an MMF, alloc in global memory and fill, pass that pointer. The memory layout is managed with a special shared-mem SSTG.

Engine assemblies, built-in version. Always available.

Engine assemblies (or packages), custom binaries version. Present only if running in custom engine mode.

A new object with custom binaries replaced.

The , plus an applied choise for either built-in or custom kind.

Knows how to spawn nested builds correctly connected to the currently running build.

Written into a storage for passing into the isolated appdomain. Upon reading, reflects what once was in .

Deserializes the build script binaries list.

Deserializes the build script binaries types in input artifacts list.

Deserializes the build sources list.

Base impl which is not dependent on Shell (and is thus not a component on iself).

Starts a new build async.

Runs the built-in build engine. Can execute build steps in script. Can't execute steps from compiled packages nicely because those are referencing their own instance of the compiled build engine instead of this one.

Runs the build engine retrieved from packages. Suitable for running builds on steps from packages because they would be using the same types.

The compiler output itself.

If there were any errors when building the script, which includes both compilaton errors and reference retrieval errors.

Lists all the DLL references which the compiler had when compiling the build script, including the target framework reference assemblies available to the code. See members for possible kinds. You might differentiate between assembiles by this origin if you only need some of this. NOTE that this is the set as the compiler saw it, i.e. after deduplication among explicit references and refasms.

Uses the built-in CodeDOM C# compiler (which in turn calls some csc.exe and is in its APIs close to what csc.exe expects).

Compilers which call into csc.exe in the result, and have its behavior, incl the CodeDOM and calling it manually.

Assembly paths, plus aliases for disambiguing the use of the same types.

Calls csc.exe manually, should be compatible with the installed toolsets.

We now have Roslyn in our Metadata project, this tries to reuse the existing code instead of loading a separate one from the package.

Original impl, when we had no Roslyn directly referenced from within our solution. Loads from a Nuget.

Where this assembly reference comes from, which also gives the priority for choosing between conflicting DLLs.

The assembly item with the referenced assembly body.

Loads even if originating on disk.

In build script files, there's a Pragma Reference for either a GAC DLL or a Nuget package.

For the part of the build script which has been supplied as binaries, all of its assemblies and their references become available to the source part of the build script as references.

As build script uses some of the build engine types (most notably, attributes), its assemblies must also be available to build script as references.

References to the interface assemblies in Build Engine itself, incl our assemblies and their GAC requirements.

From all the Build Engine assemblies, we only take this (and its transitive references) to be available for use from Build Script Sources and for resolve from build catalog. The Engine itself, which contains implementation details, is NOT available. We only begin from Build Interfaces (which inherently includes Metadata, Component Container, Utils etc).

Does not include transitive references, so we do not materialize ref asms package to calc the identity hash. But does include ALL engine assemblies incl impl details (basically, that's just Engine). Why? (a) it's faster that metadata-load references and traverse them; (b) it's just one small file; (c) engine defines how sources are processed, so kind of affects the identity.

All references for resolve by compiler and catalog: the engine itself, plus RefAsms it uses transitively.

Factory for creating platform entities in assemblies without references to the Platform.


            #pragma reference assembly Microsoft.Build
            #pragma reference package Nuget.Core 2.11.1

The compiler sessions.

Submits to logger, accordingly with severity etc.

If was successful (no errors).

Factored by users via reflection, then used to summon compiler session instances.