We would like to eliminate IVT, at least as much as possible in MTP and extensions.
Step 1: MTP and extension versioning
First step would be to address #7708.
The version should be embedded in each individual extension assembly, either as a const or as a static readonly field (we have to decide on that). The version will be in a class marked Embedded.
Step 2: IVTs for system abstractions
Very often, we use IFileSystem/IEnvironment which are just abstractions for stuff in BCL.
We should avoid doing that and act as if we are a third-party extension authors. What we can then do is link the IFileSystem/IEnvironment/SystemFileSystem/SystemEnvironment types (internal and marked as Embedded). Then, instead of retrieving them via IServiceProvider, we will just hardcode the SystemFileSystem and SystemEnvironment implementation, but still allowing unit tests to pass a mock if needed. Or, in areas where we think mocking won't be needed, we can just stick to the BCL APIs right away.
Step 3: Specific extension analysis
- AzureDevOpsReport: it will be fully addressed by the previous two steps.
- AzureFoundry: it will be fully addressed by step 2 (for IEnvironment)
- CrashDump: it will be fully addressed by step 1
- HangDump: it will be fully addressed by the previous two steps, but for more interfaces (e.g,
IProcess, ITask, IClock, IProcessHandler)
- HotReload: More challenging, it uses
TestHostTestFrameworkInvoker.
- MSBuild: More challenging, it uses
TestRequestExecutionTimeInfo.
- OpenTelemetry: More challenging, it needs ICounter/IHistogram, et.c
- Retry: Can be fixed once we get rid of RetryExecutionFilterFactory
- Telemetry: more challenging, needs ITelemetryInformation and ITelemetryCollector
- TRX: Might be challenging. Needs
ITestApplicationModuleInfo, but it should be relatively straightforward to get rid of that.
We would like to eliminate IVT, at least as much as possible in MTP and extensions.
Step 1: MTP and extension versioning
First step would be to address #7708.
The version should be embedded in each individual extension assembly, either as a const or as a static readonly field (we have to decide on that). The version will be in a class marked Embedded.
Step 2: IVTs for system abstractions
Very often, we use
IFileSystem/IEnvironmentwhich are just abstractions for stuff in BCL.We should avoid doing that and act as if we are a third-party extension authors. What we can then do is link the
IFileSystem/IEnvironment/SystemFileSystem/SystemEnvironmenttypes (internal and marked as Embedded). Then, instead of retrieving them via IServiceProvider, we will just hardcode theSystemFileSystemandSystemEnvironmentimplementation, but still allowing unit tests to pass a mock if needed. Or, in areas where we think mocking won't be needed, we can just stick to the BCL APIs right away.Step 3: Specific extension analysis
IProcess,ITask,IClock,IProcessHandler)TestHostTestFrameworkInvoker.TestRequestExecutionTimeInfo.ITestApplicationModuleInfo, but it should be relatively straightforward to get rid of that.