docs/coding-guidelines/updating-ref-source.md
This document provides the steps you need to take to update the reference assembly when adding new public APIs to an implementation assembly (post API Review).
TypeMustExist error. The deadlock can be worked around by disabling ApiCompat's assembly validation: dotnet build /p:ApiCompatValidateAssemblies=false.dotnet msbuild /t:GenerateReferenceAssemblySource to run the GenAPI tool**.** Note: If you already added the new API to the reference source, re-generating it (after building the source assembly) will update it to be fully qualified and placed in the correct order. This can be done by running the GenerateReferenceAssemblySource command from the ref directory.
These steps can also be applied to some unique assemblies which depend on changes in System.Private.Corelib. (partial facades like System.Memory, for example).
dotnet build --no-incremental /t:GenerateReferenceAssemblySource from the System.Runtime/src directory.For implementation assemblies that are "full facades" over another assembly but define types in the reference assembly (ex. System.Runtime.Serialization.Json or System.Xml.XDocument), use the following command to generate the reference source code instead:
dotnet msbuild /t:GenerateReferenceAssemblySource /p:GenAPIFollowTypeForwards=true
Some assemblies define types in .NETStandard and .NETCore but require facades on .NETFramework to forward types to their existing location in .NETFramework. In these cases we need to add type forwards manually to the .NETFramework build of the reference assembly. TypeForwards must be added for every type in the compatible .NETStandard reference assembly that exists in the .NETFramework, types which are defined in the .NETFramework reference should be factored into a shared source file.