Background and motivation
We're trying to bring DCS and friends back to par with .Net 4.8 in this release. One of the capabilities of the DCS library in .Net 4.8 is to generate XSD schemas or import XSD schemas into usable code. This functionality is used to support WCF and svcutil. The code that handles schema importing however, had a dependency on System.CodeDom. After some extended discussion around the goals and motivations, we decided to take a two-pronged approach here. The existing DCS assembly in the runtime will be recieving updates to align with 4.8 and to support this schema work under the covers... but the top-level functionality (and public surface area) of the schema support will live in a separate package in dotnet/runtime that is not part of the runtime. (Like the System.CodeDom package it depends on.) See the PR #71752 and other half of the API review #72243.
Schema support in 4.8 relied heavily on DCS internals, which wasn't a problem since those and CodeDom were all there. To do this schema work in an external package though, we need to expose some API points from the System.Runtime.Serialization namespace. I've tried to keep these to a minimum, and at a somewhat logical and abstract level so they don't look too contrived or out of place for a public API. But the intent here is to support what we need for XSD schema processing - not to open up the internals of DCS anymore than we need to.
Classes being exposed by this proposal are as follows:
- DataContractSet
- DataContract
- XmlDataContract
- DataMember
Additionally, a new interface is being added, and the DataContractJsonSerializer is receiving an extension method that the Xml DCS already had for supplying surrogate providers.
API Proposal
namespaceSystem.Runtime.Serialization{publicsealedclassDataContractSet{[RequiresUnreferencedCode("")]publicDataContractSet(DataContractSetdataContractSet);publicDataContractSet(ISerializationSurrogateProvider?dataContractSurrogate,ICollection<Type>?referencedTypes,ICollection<Type>?referencedCollectionTypes);publicDictionary<XmlQualifiedName,DataContract>Contracts{get;}publicDictionary<XmlQualifiedName,DataContract>?KnownTypesForObject{get;}publicDictionary<DataContract,object>ProcessedContracts{get;}publicHashtableSurrogateData{get;}[RequiresUnreferencedCode("")]publicvoidAdd(Typetype);[RequiresUnreferencedCode("")]publicvoidExportSchemaSet(XmlSchemaSetschemaSet);[RequiresUnreferencedCode("")]publicDataContractGetDataContract(Typetype);[RequiresUnreferencedCode("")]publicDataContract?GetDataContract(XmlQualifiedNamekey);[RequiresUnreferencedCode("")]publicType?GetReferencedType(XmlQualifiedNamestableName,DataContractdataContract,outDataContract?referencedContract,outobject[]?genericParameters,bool?supportGenericTypes=null);[RequiresUnreferencedCode("")]publicvoidImportSchemaSet(XmlSchemaSetschemaSet,ICollection<XmlQualifiedName>?typeNames,boolimportXmlDataType);[RequiresUnreferencedCode("")]publicIList<XmlQualifiedName>ImportSchemaSet(XmlSchemaSetschemaSet,ICollection<XmlSchemaElement>elements,boolimportXmlDataType);}publicabstractclassDataContract{publicvirtualboolIsBuiltInDataContract{get;}[DynamicallyAccessedMembers(*)]publicvirtualTypeUnderlyingType{get;}publicvirtualXmlQualifiedNameStableName{get;}publicvirtualTypeOriginalUnderlyingType{get;}publicvirtualList<DataMember>?Members{get;}publicvirtualDictionary<XmlQualifiedName,DataContract>?KnownDataContracts{get;set;}publicvirtualboolIsValueType{get;}publicvirtualboolIsReference{get;}publicvirtualboolIsISerializable{get;}publicvirtualXmlDictionaryString?TopLevelElementName{get;}publicvirtualXmlDictionaryString?TopLevelElementNamespace{get;}publicvirtualDataContract?BaseContract{get;}publicvirtualstring?ContractType{get;}publicstaticstringEncodeLocalName(stringlocalName);[RequiresUnreferencedCode("")]publicstaticDataContract?GetBuiltInDataContract(stringname,stringns);[RequiresUnreferencedCode("")]publicstaticDataContractGetDataContract(Typetype);[RequiresUnreferencedCode("")]publicstaticXmlQualifiedNameGetStableName(Typetype);[RequiresUnreferencedCode("")]publicstaticTypeGetSurrogateType(ISerializationSurrogateProvidersurrogateProvider,Typetype);[RequiresUnreferencedCode("")]publicstaticboolIsTypeSerializable(Typetype);[RequiresUnreferencedCode("")]publicvirtualXmlQualifiedNameGetArrayTypeName(boolisNullable);publicvirtualboolIsKeyValue(outstring?keyName,outstring?valueName,outstring?itemName);}publicsealedclassXmlDataContract:DataContract{publicboolHasRoot{get;}publicboolIsAnonymous{get;}publicboolIsTopLevelElementNullable{get;}publicboolIsTypeDefinedOnImport{get;set;}publicboolIsValueType{get;set;}publicXmlSchemaType?XsdType{get;}}publicsealedclassDataMember{publicboolEmitDefaultValue{get;}publicboolIsNullable{get;}publicboolIsRequired{get;}publicDataContractMemberTypeContract{get;}publicstringName{get;}publiclongOrder{get;}}publicinterfaceISerializationExtendedSurrogateProvider:ISerializationSurrogateProvider{object?GetCustomDataToExport(MemberInfomemberInfo,TypedataContractType);object?GetCustomDataToExport(TypeclrType,TypedataContractType);voidGetKnownCustomDataTypes(Collection<Type>customDataTypes);Type?GetReferencedTypeOnImport(stringtypeName,stringtypeNamespace,object?customData);}}namespaceSystem.Runtime.Serialization.Json{publicstaticclassDataContractJsonSerializerExtensions{publicstaticSystem.Runtime.Serialization.ISerializationSurrogateProvider?GetSerializationSurrogateProvider(thisDataContractJsonSerializerserializer);publicstaticvoidSetSerializationSurrogateProvider(thisDataContractJsonSerializerserializer,System.Runtime.Serialization.ISerializationSurrogateProvider?provider);}}API Usage
I'm not sure where to begin on this one. The schema support package needs to reason about and manage DataContracts, and these API's allow it to do so without exposing all the internals.
Alternative Designs
No response
Risks
These are largely methods that existed as-is or very close to how they are in 4.8. But they were internal before, not public. I do believe they reasonably support what we need. I expect there will be quite a bit of discussion though as it is a large and publicly un-proven surface we are opening up.
Background and motivation
We're trying to bring DCS and friends back to par with .Net 4.8 in this release. One of the capabilities of the DCS library in .Net 4.8 is to generate XSD schemas or import XSD schemas into usable code. This functionality is used to support WCF and svcutil. The code that handles schema importing however, had a dependency on System.CodeDom. After some extended discussion around the goals and motivations, we decided to take a two-pronged approach here. The existing DCS assembly in the runtime will be recieving updates to align with 4.8 and to support this schema work under the covers... but the top-level functionality (and public surface area) of the schema support will live in a separate package in dotnet/runtime that is not part of the runtime. (Like the System.CodeDom package it depends on.) See the PR #71752 and other half of the API review #72243.
Schema support in 4.8 relied heavily on DCS internals, which wasn't a problem since those and CodeDom were all there. To do this schema work in an external package though, we need to expose some API points from the System.Runtime.Serialization namespace. I've tried to keep these to a minimum, and at a somewhat logical and abstract level so they don't look too contrived or out of place for a public API. But the intent here is to support what we need for XSD schema processing - not to open up the internals of DCS anymore than we need to.
Classes being exposed by this proposal are as follows:
Additionally, a new interface is being added, and the DataContractJsonSerializer is receiving an extension method that the Xml DCS already had for supplying surrogate providers.
API Proposal
API Usage
I'm not sure where to begin on this one. The schema support package needs to reason about and manage DataContracts, and these API's allow it to do so without exposing all the internals.
Alternative Designs
No response
Risks
These are largely methods that existed as-is or very close to how they are in 4.8. But they were internal before, not public. I do believe they reasonably support what we need. I expect there will be quite a bit of discussion though as it is a large and publicly un-proven surface we are opening up.