[cdac] break up cdacreader into 4 separate assemblies by lambdageek · Pull Request #108156 · dotnet/runtime

lambdageek · 2024-09-23T20:10:16Z

Break up the monolithic cdacreader assembly into four parts:

Microsoft.Diagnostics.DataContractReader.Abstractions just the API surface for contract implementations and clients note everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet
Microsoft.Diagnostics.DataContractReader.Contracts: the concrete implementations of the contracts and data
Microsoft.Diagnostics.DataContractReader: a concrete Target that ties everything together
cdacreader just the unmanaged entrypoints and the legacy DAC API surface SOSDacImpl

To untangle things I had to add a new IContractFactory<TContract> interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts.

Goals:

Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers.
Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation
Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces

Break up the monolithic cdacreader assembly into three parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients **note** everything is `internal` for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataCotnractReader`: a concrete `Target` that ties everything together 4. `cdacreader` just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TProduct>` interface - this is what the target's `Registry` uses to instantiate specific versions of contracts. Goals: 1. Make it possible to mock a `ITarget` and its `IRegistry` so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. 2. Eventually make it possible to inject additional contract implementations into a `Registry` implementations 3. Make it possible to consume just the `Target` and `Contracts` without the unmanaged entrypoints or the legacy interfaces

dotnet-policy-service · 2024-09-23T20:14:43Z

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Allows the TypeNameBuidler and SigFormat to depend on the abstract target

…egistry -> ContractRegistry

lambdageek · 2024-09-26T14:09:18Z

I believe I've addressed the outstanding feedback (except the record struct change which I'd like to do in a follow-up). Could I get one more look

Break up the monolithic cdacreader assembly into four parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients. **Note**: everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataContractReader`: a concrete Target that ties everything together 4. `cdacreader`: just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TContract>` interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts. Goals: * Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. * Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces Changes: * [cdac] break up cdacreader into 4 separate assemblies * rename the contract factories using libraries naming convention * removed unused usings * document all abstract Target members * rename Target -> ContractDescriptorTarget * Add ReadTargetPointerFromSpan to abstract Target Allows the TypeNameBuidler and SigFormat to depend on the abstract target * change SOSDacImpl to depend on the abstract Target * fixup filenames and namespaces

lambdageek · 2024-09-23T20:10:16Z

Break up the monolithic cdacreader assembly into four parts:

Microsoft.Diagnostics.DataContractReader.Abstractions just the API surface for contract implementations and clients note everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet
Microsoft.Diagnostics.DataContractReader.Contracts: the concrete implementations of the contracts and data
Microsoft.Diagnostics.DataContractReader: a concrete Target that ties everything together
cdacreader just the unmanaged entrypoints and the legacy DAC API surface SOSDacImpl

To untangle things I had to add a new IContractFactory<TContract> interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts.

Goals:

Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers.
Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation
Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces

Break up the monolithic cdacreader assembly into three parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients **note** everything is `internal` for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataCotnractReader`: a concrete `Target` that ties everything together 4. `cdacreader` just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TProduct>` interface - this is what the target's `Registry` uses to instantiate specific versions of contracts. Goals: 1. Make it possible to mock a `ITarget` and its `IRegistry` so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. 2. Eventually make it possible to inject additional contract implementations into a `Registry` implementations 3. Make it possible to consume just the `Target` and `Contracts` without the unmanaged entrypoints or the legacy interfaces

dotnet-policy-service · 2024-09-23T20:14:43Z

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Allows the TypeNameBuidler and SigFormat to depend on the abstract target

…egistry -> ContractRegistry

lambdageek · 2024-09-26T14:09:18Z

I believe I've addressed the outstanding feedback (except the record struct change which I'd like to do in a follow-up). Could I get one more look

Break up the monolithic cdacreader assembly into four parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients. **Note**: everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataContractReader`: a concrete Target that ties everything together 4. `cdacreader`: just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TContract>` interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts. Goals: * Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. * Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces Changes: * [cdac] break up cdacreader into 4 separate assemblies * rename the contract factories using libraries naming convention * removed unused usings * document all abstract Target members * rename Target -> ContractDescriptorTarget * Add ReadTargetPointerFromSpan to abstract Target Allows the TypeNameBuidler and SigFormat to depend on the abstract target * change SOSDacImpl to depend on the abstract Target * fixup filenames and namespaces

lambdageek · 2024-09-23T20:10:16Z

Break up the monolithic cdacreader assembly into four parts:

Microsoft.Diagnostics.DataContractReader.Abstractions just the API surface for contract implementations and clients note everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet
Microsoft.Diagnostics.DataContractReader.Contracts: the concrete implementations of the contracts and data
Microsoft.Diagnostics.DataContractReader: a concrete Target that ties everything together
cdacreader just the unmanaged entrypoints and the legacy DAC API surface SOSDacImpl

To untangle things I had to add a new IContractFactory<TContract> interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts.

Goals:

Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers.
Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation
Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces

Break up the monolithic cdacreader assembly into three parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients **note** everything is `internal` for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataCotnractReader`: a concrete `Target` that ties everything together 4. `cdacreader` just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TProduct>` interface - this is what the target's `Registry` uses to instantiate specific versions of contracts. Goals: 1. Make it possible to mock a `ITarget` and its `IRegistry` so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. 2. Eventually make it possible to inject additional contract implementations into a `Registry` implementations 3. Make it possible to consume just the `Target` and `Contracts` without the unmanaged entrypoints or the legacy interfaces

dotnet-policy-service · 2024-09-23T20:14:43Z

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Allows the TypeNameBuidler and SigFormat to depend on the abstract target

…egistry -> ContractRegistry

lambdageek · 2024-09-26T14:09:18Z

I believe I've addressed the outstanding feedback (except the record struct change which I'd like to do in a follow-up). Could I get one more look

Break up the monolithic cdacreader assembly into four parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients. **Note**: everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataContractReader`: a concrete Target that ties everything together 4. `cdacreader`: just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TContract>` interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts. Goals: * Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. * Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces Changes: * [cdac] break up cdacreader into 4 separate assemblies * rename the contract factories using libraries naming convention * removed unused usings * document all abstract Target members * rename Target -> ContractDescriptorTarget * Add ReadTargetPointerFromSpan to abstract Target Allows the TypeNameBuidler and SigFormat to depend on the abstract target * change SOSDacImpl to depend on the abstract Target * fixup filenames and namespaces

lambdageek · 2024-09-23T20:10:16Z

Break up the monolithic cdacreader assembly into four parts:

Microsoft.Diagnostics.DataContractReader.Abstractions just the API surface for contract implementations and clients note everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet
Microsoft.Diagnostics.DataContractReader.Contracts: the concrete implementations of the contracts and data
Microsoft.Diagnostics.DataContractReader: a concrete Target that ties everything together
cdacreader just the unmanaged entrypoints and the legacy DAC API surface SOSDacImpl

To untangle things I had to add a new IContractFactory<TContract> interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts.

Goals:

Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers.
Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation
Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces

Break up the monolithic cdacreader assembly into three parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients **note** everything is `internal` for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataCotnractReader`: a concrete `Target` that ties everything together 4. `cdacreader` just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TProduct>` interface - this is what the target's `Registry` uses to instantiate specific versions of contracts. Goals: 1. Make it possible to mock a `ITarget` and its `IRegistry` so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. 2. Eventually make it possible to inject additional contract implementations into a `Registry` implementations 3. Make it possible to consume just the `Target` and `Contracts` without the unmanaged entrypoints or the legacy interfaces

dotnet-policy-service · 2024-09-23T20:14:43Z

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Allows the TypeNameBuidler and SigFormat to depend on the abstract target

…egistry -> ContractRegistry

lambdageek · 2024-09-26T14:09:18Z

I believe I've addressed the outstanding feedback (except the record struct change which I'd like to do in a follow-up). Could I get one more look

Break up the monolithic cdacreader assembly into four parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients. **Note**: everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataContractReader`: a concrete Target that ties everything together 4. `cdacreader`: just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TContract>` interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts. Goals: * Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. * Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces Changes: * [cdac] break up cdacreader into 4 separate assemblies * rename the contract factories using libraries naming convention * removed unused usings * document all abstract Target members * rename Target -> ContractDescriptorTarget * Add ReadTargetPointerFromSpan to abstract Target Allows the TypeNameBuidler and SigFormat to depend on the abstract target * change SOSDacImpl to depend on the abstract Target * fixup filenames and namespaces

lambdageek · 2024-09-23T20:10:16Z

Break up the monolithic cdacreader assembly into four parts:

Microsoft.Diagnostics.DataContractReader.Abstractions just the API surface for contract implementations and clients note everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet
Microsoft.Diagnostics.DataContractReader.Contracts: the concrete implementations of the contracts and data
Microsoft.Diagnostics.DataContractReader: a concrete Target that ties everything together
cdacreader just the unmanaged entrypoints and the legacy DAC API surface SOSDacImpl

To untangle things I had to add a new IContractFactory<TContract> interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts.

Goals:

Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers.
Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation
Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces

Break up the monolithic cdacreader assembly into three parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients **note** everything is `internal` for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataCotnractReader`: a concrete `Target` that ties everything together 4. `cdacreader` just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TProduct>` interface - this is what the target's `Registry` uses to instantiate specific versions of contracts. Goals: 1. Make it possible to mock a `ITarget` and its `IRegistry` so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. 2. Eventually make it possible to inject additional contract implementations into a `Registry` implementations 3. Make it possible to consume just the `Target` and `Contracts` without the unmanaged entrypoints or the legacy interfaces

dotnet-policy-service · 2024-09-23T20:14:43Z

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Allows the TypeNameBuidler and SigFormat to depend on the abstract target

…egistry -> ContractRegistry

lambdageek · 2024-09-26T14:09:18Z

I believe I've addressed the outstanding feedback (except the record struct change which I'd like to do in a follow-up). Could I get one more look

Break up the monolithic cdacreader assembly into four parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients. **Note**: everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataContractReader`: a concrete Target that ties everything together 4. `cdacreader`: just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TContract>` interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts. Goals: * Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. * Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces Changes: * [cdac] break up cdacreader into 4 separate assemblies * rename the contract factories using libraries naming convention * removed unused usings * document all abstract Target members * rename Target -> ContractDescriptorTarget * Add ReadTargetPointerFromSpan to abstract Target Allows the TypeNameBuidler and SigFormat to depend on the abstract target * change SOSDacImpl to depend on the abstract Target * fixup filenames and namespaces

lambdageek · 2024-09-23T20:10:16Z

Break up the monolithic cdacreader assembly into four parts:

Microsoft.Diagnostics.DataContractReader.Abstractions just the API surface for contract implementations and clients note everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet
Microsoft.Diagnostics.DataContractReader.Contracts: the concrete implementations of the contracts and data
Microsoft.Diagnostics.DataContractReader: a concrete Target that ties everything together
cdacreader just the unmanaged entrypoints and the legacy DAC API surface SOSDacImpl

To untangle things I had to add a new IContractFactory<TContract> interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts.

Goals:

Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers.
Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation
Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces

Break up the monolithic cdacreader assembly into three parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients **note** everything is `internal` for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataCotnractReader`: a concrete `Target` that ties everything together 4. `cdacreader` just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TProduct>` interface - this is what the target's `Registry` uses to instantiate specific versions of contracts. Goals: 1. Make it possible to mock a `ITarget` and its `IRegistry` so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. 2. Eventually make it possible to inject additional contract implementations into a `Registry` implementations 3. Make it possible to consume just the `Target` and `Contracts` without the unmanaged entrypoints or the legacy interfaces

dotnet-policy-service · 2024-09-23T20:14:43Z

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Allows the TypeNameBuidler and SigFormat to depend on the abstract target

…egistry -> ContractRegistry

lambdageek · 2024-09-26T14:09:18Z

I believe I've addressed the outstanding feedback (except the record struct change which I'd like to do in a follow-up). Could I get one more look

Break up the monolithic cdacreader assembly into four parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients. **Note**: everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataContractReader`: a concrete Target that ties everything together 4. `cdacreader`: just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TContract>` interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts. Goals: * Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. * Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces Changes: * [cdac] break up cdacreader into 4 separate assemblies * rename the contract factories using libraries naming convention * removed unused usings * document all abstract Target members * rename Target -> ContractDescriptorTarget * Add ReadTargetPointerFromSpan to abstract Target Allows the TypeNameBuidler and SigFormat to depend on the abstract target * change SOSDacImpl to depend on the abstract Target * fixup filenames and namespaces

lambdageek · 2024-09-23T20:10:16Z

Break up the monolithic cdacreader assembly into four parts:

Microsoft.Diagnostics.DataContractReader.Abstractions just the API surface for contract implementations and clients note everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet
Microsoft.Diagnostics.DataContractReader.Contracts: the concrete implementations of the contracts and data
Microsoft.Diagnostics.DataContractReader: a concrete Target that ties everything together
cdacreader just the unmanaged entrypoints and the legacy DAC API surface SOSDacImpl

To untangle things I had to add a new IContractFactory<TContract> interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts.

Goals:

Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers.
Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation
Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces

Break up the monolithic cdacreader assembly into three parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients **note** everything is `internal` for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataCotnractReader`: a concrete `Target` that ties everything together 4. `cdacreader` just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TProduct>` interface - this is what the target's `Registry` uses to instantiate specific versions of contracts. Goals: 1. Make it possible to mock a `ITarget` and its `IRegistry` so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. 2. Eventually make it possible to inject additional contract implementations into a `Registry` implementations 3. Make it possible to consume just the `Target` and `Contracts` without the unmanaged entrypoints or the legacy interfaces

dotnet-policy-service · 2024-09-23T20:14:43Z

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Allows the TypeNameBuidler and SigFormat to depend on the abstract target

…egistry -> ContractRegistry

lambdageek · 2024-09-26T14:09:18Z

I believe I've addressed the outstanding feedback (except the record struct change which I'd like to do in a follow-up). Could I get one more look

Break up the monolithic cdacreader assembly into four parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients. **Note**: everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataContractReader`: a concrete Target that ties everything together 4. `cdacreader`: just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TContract>` interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts. Goals: * Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. * Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces Changes: * [cdac] break up cdacreader into 4 separate assemblies * rename the contract factories using libraries naming convention * removed unused usings * document all abstract Target members * rename Target -> ContractDescriptorTarget * Add ReadTargetPointerFromSpan to abstract Target Allows the TypeNameBuidler and SigFormat to depend on the abstract target * change SOSDacImpl to depend on the abstract Target * fixup filenames and namespaces

lambdageek · 2024-09-23T20:10:16Z

Break up the monolithic cdacreader assembly into four parts:

Microsoft.Diagnostics.DataContractReader.Abstractions just the API surface for contract implementations and clients note everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet
Microsoft.Diagnostics.DataContractReader.Contracts: the concrete implementations of the contracts and data
Microsoft.Diagnostics.DataContractReader: a concrete Target that ties everything together
cdacreader just the unmanaged entrypoints and the legacy DAC API surface SOSDacImpl

To untangle things I had to add a new IContractFactory<TContract> interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts.

Goals:

Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers.
Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation
Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces

Break up the monolithic cdacreader assembly into three parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients **note** everything is `internal` for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataCotnractReader`: a concrete `Target` that ties everything together 4. `cdacreader` just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TProduct>` interface - this is what the target's `Registry` uses to instantiate specific versions of contracts. Goals: 1. Make it possible to mock a `ITarget` and its `IRegistry` so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. 2. Eventually make it possible to inject additional contract implementations into a `Registry` implementations 3. Make it possible to consume just the `Target` and `Contracts` without the unmanaged entrypoints or the legacy interfaces

dotnet-policy-service · 2024-09-23T20:14:43Z

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Allows the TypeNameBuidler and SigFormat to depend on the abstract target

…egistry -> ContractRegistry

lambdageek · 2024-09-26T14:09:18Z

I believe I've addressed the outstanding feedback (except the record struct change which I'd like to do in a follow-up). Could I get one more look

Break up the monolithic cdacreader assembly into four parts: 1. `Microsoft.Diagnostics.DataContractReader.Abstractions` just the API surface for contract implementations and clients. **Note**: everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet 2. `Microsoft.Diagnostics.DataContractReader.Contracts`: the concrete implementations of the contracts and data 3. `Microsoft.Diagnostics.DataContractReader`: a concrete Target that ties everything together 4. `cdacreader`: just the unmanaged entrypoints and the legacy DAC API surface `SOSDacImpl` To untangle things I had to add a new `IContractFactory<TContract>` interface - this is what the target's ContractRegistry uses to instantiate specific versions of contracts. Goals: * Make it possible to mock a Target and its ContractRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers. * Eventually make it possible to inject additional contract implementations into a ContractRegistry implementation Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces Changes: * [cdac] break up cdacreader into 4 separate assemblies * rename the contract factories using libraries naming convention * removed unused usings * document all abstract Target members * rename Target -> ContractDescriptorTarget * Add ReadTargetPointerFromSpan to abstract Target Allows the TypeNameBuidler and SigFormat to depend on the abstract target * change SOSDacImpl to depend on the abstract Target * fixup filenames and namespaces

ghost added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Sep 23, 2024

lambdageek mentioned this pull request Sep 23, 2024
[cdac] break up cdacreader into 4 separate assemblies #107709
Closed

lambdageek requested review from AaronRobinsonMSFT, davidwrighton and elinor-fung September 23, 2024 20:10

lambdageek added the area-Diagnostics-coreclr label Sep 23, 2024

dotnet-policy-serviceBot assigned lambdageek Sep 23, 2024

lambdageek removed the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Sep 23, 2024

This was referenced Sep 23, 2024
restarted. Azure DevOps can't recover from restarts. dotnet/dnceng#3879
Closed
System.IO.Pipelines.Tests.PipeWriterTests.CompleteWithLargeWriteThrows fails in CI #103586
Open
GetAsync_ServerNeedsAuthAndNoCredential_StatusCodeUnauthorized got cancelled #108019
Open

AaronRobinsonMSFT reviewed Sep 24, 2024
View reviewed changes

am11 reviewed Sep 24, 2024
View reviewed changes

Comment thread...ed/cdacreader/Microsoft.Diagnostics.DataContractReader.Abstractions/Contracts/IDacStreams.cs

lambdageek added 14 commits September 24, 2024 09:28

rename the contract factories using libraries naming convention
c283b13

removed unused usings
cc3a4f1

fixup mock
4a5cd7a

document all ITarget members
18e9d00

rename Registry -> ContractRegistry
ba9d83a

change ITarget -> AbstractTarget
87d026a

change IContractRegistry -> AbstractContractRegistry
0f2130d

rename Target -> ContractDescriptorTarget; AbstractTarget -> Target
9b937bc

fixup: rename the .cs file too
fd83148

Add ReadTargetPointerFromSpan to abstract Target
6a45fba
Allows the TypeNameBuidler and SigFormat to depend on the abstract target

change SOSDacImpl to depend on the abstract Target
bd64632

Remove a few move concrete Target dependencies
ff762e0

rename ContractRegistry -> CachingContractRegistry; AbstractContractR…
75dfc46
…egistry -> ContractRegistry

revert unnecesasry change
15ef960

am11 reviewed Sep 25, 2024
View reviewed changes

Comment thread...anaged/cdacreader/Microsoft.Diagnostics.DataContractReader.Abstractions/Contracts/IThread.cs

build-analysisBot mentioned this pull request Sep 25, 2024
System.Data.OleDb.Tests timeout in net48 x86 Release leg #87783
Closed

fixup filenames and namespaces
1ad195b

lambdageekand others added 2 commits September 26, 2024 18:13

Merge remote-tracking branch 'origin/main' into cdac-abstractions2
f0700c2

Merge remote-tracking branch 'origin/main' into cdac-abstractions2
32d956b

lambdageek requested a review from max-charlamb September 27, 2024 17:35

lambdageek mentioned this pull request Sep 30, 2024
[cdac] Implement NibbleMap lookup and tests #108403
Merged

AaronRobinsonMSFT approved these changes Sep 30, 2024
View reviewed changes

lambdageek merged commit a7e5426 into dotnet:mainSep 30, 2024

lambdageek deleted the cdac-abstractions2 branch October 18, 2024 19:33

github-actionsBot locked and limited conversation to collaborators Nov 18, 2024