|
| 1 | +# Reference assemblies |
| 2 | + |
| 3 | +Reference assemblies are metadata-only assemblies with the minimum amount of metadata to preserve the compile-time behavior of consumers (diagnostics may be affected, though). |
| 4 | +The compiler may choose to remove more metadata in later versions, if it is determined to be safe (ie. respects the principle above). |
| 5 | + |
| 6 | +## Scenarios |
| 7 | +There are 4 scenarios: |
| 8 | + |
| 9 | +1. The traditional one, where an assembly is emitted as the primary output (`/out` command-line parameter, or `peStream` parameter in `Compilation.Emit` APIs). |
| 10 | +2. The IDE scenario, where the metadata-only assembly is emitted (via `Emit` API), still as the primary output. Later on, the IDE is interested to get metadata-only assemblies even when there are errors in the compilation. |
| 11 | +3. The CoreFX scenario, where only the ref assembly is emitted, still as the primary output (`/refonly` command-line parameter) |
| 12 | +4. The MSBuild scenario, which is the new scenario, where both a real assembly is emitted as the primary output, and a ref assembly is emitted as the secondary output (`/refout` command-line parameter, or `metadataPeStream` parameter in `Emit`). |
| 13 | + |
| 14 | + |
| 15 | +## Definition of ref assemblies |
| 16 | +Metadata-only assembly have their method bodies replaced with a single `throw null` body, but include all members except anonymous types. The reason for using `throw null` bodies (as opposed to no bodies) is so that PEVerify could run and pass (thus validating the completeness of the metadata). |
| 17 | +Ref assemblies will include an assembly-level `ReferenceAssembly` attribute. This attribute may be specified in source (then we won't need to synthesize it). Because of this attribute, runtimes will refuse to load ref assemblies for execution (but they can still be loaded Reflection-only mode). |
| 18 | +Ref assemblies further remove metadata (private members) from metadata-only assemblies: |
| 19 | + |
| 20 | +- A ref assembly will only have references for what it needs in the API surface. The real assembly may have additional references related to specific implementations. For instance, the ref assembly for `class C { private void M() { dynamic d = 1; ... } }` will not reference any types required for `dynamic`. |
| 21 | +- Private function-members (methods, properties and events) will be removed. If there are no `InternalsVisibleTo` attributes, do the same for internal function-members |
| 22 | +- But all types (including private or nested types) must be kept in ref assemblies. All attributes must be kept (even internal ones). |
| 23 | +- All virtual methods will be kept. Explicit interface implementations will be kept. |
| 24 | +- All fields of a struct will be kept. (This is a candidate for post-C#-7.1 refinement) |
| 25 | + |
| 26 | +## API changes |
| 27 | + |
| 28 | +### Command-line |
| 29 | +Two mutually exclusive command-line parameters will be added to `csc.exe` and `vbc.exe`: |
| 30 | +- `/refout` |
| 31 | +- `/refonly` |
| 32 | + |
| 33 | +The `/refout` parameter specifies a file path where the ref assembly should be output. This translates to `metadataPeStream` in the `Emit` API (see details below). The filename for the ref assembly should generally match that of the primary assembly (we will warn when they don't match). The recommended convention (used by MSBuild) is to place the ref assembly in a "ref/" sub-folder relative to the primary assembly. |
| 34 | + |
| 35 | +The `/refonly` parameter is a flag that indicates that a ref assembly should be output instead of an implementation assembly, as the primary output. |
| 36 | +The `/refonly` parameter is not allowed together with the `/refout` parameter, as it doesn't make sense to have both the primary and secondary outputs be ref assemblies. Also, the `/refonly` parameter silently disables outputting PDBs, as ref assemblies cannot be executed. |
| 37 | +The `/refonly` parameter translates to `EmitMetadataOnly` being `true`, and `IncludePrivateMembers` being `false` in the `Emit` API (see details below). |
| 38 | +Neither `/refonly` nor `/refout` are permitted with net modules (`/target:module`, `/addmodule` options). |
| 39 | + |
| 40 | +The compilation from the command-line will either produce both assemblies (implementation and ref) or neither. There is no "partial success" scenario. |
| 41 | +When the compiler produces documentation, it is un-affected by either the `/refonly` or `/refout` parameters. This may change in the future. |
| 42 | +The main purpose of the `/refout` option is to speed up incremental build scenarios. The current implementation for this flag can produce a ref assembly with more metadata than `/refonly` (for instance, anonymous types). This is a candidate for post-C#-7.1 refinement. |
| 43 | + |
| 44 | +### CscTask/CoreCompile |
| 45 | +The `CoreCompile` target will support a new output, called `IntermediateRefAssembly`, which parallels the existing `IntermediateAssembly`. |
| 46 | +The `Csc` task will support a new output, called `OutputRefAssembly`, which parallels the existing `OutputAssembly`. |
| 47 | +Both of those basically map to the `/refout` command-line parameter. |
| 48 | + |
| 49 | +An additional task, called `CopyRefAssembly`, will be provided along with the existing `Csc` task. It takes a `SourcePath` and a `DestinationPath` and generally copies the file from the source over to the destination. But if it can determine that the contents of those two files match (by comparing their MVIDs, see details below), then the destination file is left untouched. |
| 50 | + |
| 51 | +As a side-note, `CopyRefAssembly` uses the same assembly resolution/redirection trick as `Csc` and `Vbc`, to avoid type loading problems with `System.IO.FileSystem`. |
| 52 | + |
| 53 | +### CodeAnalysis APIs |
| 54 | +It is already possible to produce metadata-only assemblies by using `EmitOptions.EmitMetadataOnly`, which is used in IDE scenarios with cross-language dependencies. |
| 55 | +The compiler will be updated to honour the `EmitOptions.IncludePrivateMembers` flag as well. When combined with `EmitMetadataOnly` or a `metadataPeStream` in `Emit`, a ref assembly will be produced. |
| 56 | +The diagnostic check for emitting methods lacking a body (`void M();`) will be filtered from declaration diagnostics, so that code will successfully emit with `EmitMetadataOnly`. |
| 57 | +Later on, the `EmitOptions.TolerateErrors` flag will allow emitting error types as well. |
| 58 | +`Emit` is also modified to produce a new PE section called ".mvid" containing a copy of the MVID, when producing ref assemblies. This makes it easy for `CopyRefAssembly` to extract and compare MVIDs from ref assemblies. |
| 59 | + |
| 60 | +Going back to the 4 driving scenarios: |
| 61 | +1. For a regular compilation, `EmitMetadataOnly` is left to `false` and no `metadataPeStream` is passed into `Emit`. |
| 62 | +2. For the IDE scenario, `EmitMetadataOnly` is set to `true`, but `IncludePrivateMembers` is left to `true`. |
| 63 | +3. For the CoreFX scenario, ref assembly source code is used as input, `EmitMetadataOnly` is set to `true`, and `IncludePrivateMembers` is set to `false`. |
| 64 | +4. For the MSBuild scenario, `EmitMetadataOnly` is left to `false`, a `metadataPeStream` is passed in and `IncludePrivateMembers` is set to `false`. |
| 65 | + |
| 66 | +## Future |
| 67 | +As mentioned above, there may be further refinements after C# 7.1: |
| 68 | +- Further reduce the metadata in ref assemblies produced by `/refout`, to match those produced by `/refonly`. |
| 69 | +- Controlling internals (producing public ref assemblies) |
| 70 | +- Produce ref assemblies even when there are errors outside method bodies (emitting error types when `EmitOptions.TolerateErrors` is set) |
| 71 | +- When the compiler produces documentation, the contents produced could be filtered down to match the APIs that go into the primary output. In other words, the documentation could be filtered down when using the `/refonly` parameter. |
| 72 | + |
| 73 | +## Open questions |
| 74 | + |
| 75 | +## Related issues |
| 76 | +- Produce ref assemblies from command-line and msbuild (https://github.com/dotnet/roslyn/issues/2184) |
| 77 | +- Refine what is in reference assemblies and what diagnostics prevent generating one (https://github.com/dotnet/roslyn/issues/17612) |
| 78 | +- [Are private members part of the API surface?](http://blog.paranoidcoding.com/2016/02/15/are-private-members-api-surface.html) |
0 commit comments