migrate-static-to-wrapper
Skill9 starsChanged 6 months agoMITView on GitHub
Mechanically replace static dependency call sites with wrapper or built-in abstraction calls across a bounded scope (file, project, or namespace). Performs codemod-style bulk replacement of DateTime.UtcNow to TimeProvider.GetUtcNow(), File.ReadAllText to IFileSystem, and similar transformations. Adds constructor injection parameters and updates DI registration. USE FOR: replace DateTime.UtcNow with TimeProvider, replace DateTime.Now with TimeProvider, migrate static calls to wrapper, bulk replace File.* with IFileSystem, codemod static to injectable, add constructor injection for time provider, mechanical migration of statics, refactor DateTime to TimeProvider, swap static for injected dependency, convert static calls to use abstraction, replace statics in a class, migrate one file to TimeProvider, scoped migration, update call sites. DO NOT USE FOR: detecting statics (use detect-static-dependencies), generating wrappers (use generate-testability-wrappers), migrating between test frameworks.
1 other project uses a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- microsoft/testfxedited, first seen Oct 9, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- microsoft/testfx★ 1.1k22% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository29 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- cli-e2e-testingSkill
- crap-scoreSkill
- detect-static-dependenciesSkill
- dotnet-livecharts2Skill
- dotnet-modern-csharp-editorconfigSkill
- dotnet-test-frameworksSkill
- filter-syntaxSkill
- generate-testability-wrappersSkill
- migrate-static-to-wrapperSkill
- mtp-hot-reloadSkill
- platform-detectionSkill
- run-testsSkill
- test-anti-patternsSkill
- writing-mstest-testsSkill
- cli-e2e-testingSkill
- crap-scoreSkill
- detect-static-dependenciesSkill
- dotnet-livecharts2Skill
- dotnet-modern-csharp-editorconfigSkill
- dotnet-test-frameworksSkill
- filter-syntaxSkill
- generate-testability-wrappersSkill
- mtp-hot-reloadSkill
- platform-detectionSkill
- run-testsSkill
- test-anti-patternsSkill
- writing-mstest-testsSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 6 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 16
After wrappers have been generated (via generate-testability-wrappers) or built-in abstractions identified
- Very specific: line 24
No wrapper or abstraction exists yet (use generate-testability-wrappers first)
- Distinctive: line 42
Before modifying any code:
- Very specific: line 44
Confirm the wrapper/abstraction exists: Check that the interface or built-in abstraction is available in the project.
- Very specific: line 46
Confirm DI registration exists: Check Program.cs or Startup.cs for the service registration.
- Distinctive: line 78
Add the new dependency following the class's existing pattern:
- Very specific: line 81
Traditional constructor: Add private readonly field + constructor parameter, matching the existing field naming convention (_camelCase or …
- Very specific: line 89
Add required using directives if not already present
- Distinctive: line 102
If test files exist for the migrated classes:
- Distinctive: line 112
After all changes in the current scope:
- Distinctive: line 118
If the build fails:
- Very specific: line 119
Missing using: Add the required using directive
- Very specific: line 120
Missing NuGet package: Run dotnet add package <name>
- Distinctive: line 121
Constructor mismatch in tests: Update test instantiation (Step 5)
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Migrate Static to Wrapper
Perform mechanical, codemod-style replacement of static dependency call sites with calls to injected wrapper interfaces or built-in abstractions. Operates on a bounded scope (single file, project, or namespace) so migrations can be done incrementally.
When to Use
- After wrappers have been generated (via
generate-testability-wrappers) or built-in abstractions identified - Migrating
DateTime.UtcNow→TimeProvider.GetUtcNow()across a project - Migrating
File.*→IFileSystem.File.*across a namespace - Adding constructor injection for the new abstraction to affected classes
- Incremental migration: one project or namespace at a time
When Not to Use
- No wrapper or abstraction exists yet (use
generate-testability-wrappersfirst) - The user wants to detect statics, not migrate them (use
detect-static-dependencies) - The code does not use dependency injection and the user hasn't chosen ambient context
- Migrating between test frameworks (use the appropriate migration skill)
Inputs
| Input | Required | Description |
| Static pattern | Yes | What to replace (e.g., DateTime.UtcNow, File.ReadAllText) |
| Replacement abstraction | Yes | What to use instead (e.g., TimeProvider, IFileSystem) |
| Scope | Yes | File path, project (.csproj), namespace, or directory to migrate |
| Injection strategy | No | constructor (default), primary-constructor, or ambient |
Workflow
Step 1: Verify prerequisites
Before modifying any code:
- Confirm the wrapper/abstraction exists: Check that the interface or built-in abstraction is available in the project. For
TimeProvider, verify the target framework is .NET 8+ orMicrosoft.Bcl.TimeProvideris referenced. ForSystem.IO.Abstractions, verify the NuGet package is referenced. - Confirm DI registration exists: Check
Program.csorStartup.csfor the service registration. If missing, add it before proceeding. - Identify all files in scope: List the
.csfiles that will be modified. Exclude test projects,obj/,bin/, and generated code.
Step 2: Plan the migration for each file
For each file containing the static pattern, determine:
- Which class(es) contain the call sites — identify the class declarations
- Whether the class already has the dependency injected — check constructors for existing
TimeProvider,IFileSystem, etc. parameters - The replacement expression for each call site
Replacement mapping
| Category | Original | DI replacement |
| Time | DateTime.Now | _timeProvider.GetLocalNow().DateTime |
| Time | DateTime.UtcNow | _timeProvider.GetUtcNow().DateTime |
| Time | DateTime.Today | _timeProvider.GetLocalNow().Date |
| Time | DateTimeOffset.UtcNow | _timeProvider.GetUtcNow() |
| File | File.ReadAllText(path) | _fileSystem.File.ReadAllText(path) |
| File | File.WriteAllText(path, text) | _fileSystem.File.WriteAllText(path, text) |
| File | File.Exists(path) | _fileSystem.File.Exists(path) |
| File | Directory.Exists(path) | _fileSystem.Directory.Exists(path) |
| Env | Environment.GetEnvironmentVariable(name) | _env.GetEnvironmentVariable(name) |
| Console | Console.WriteLine(msg) | _console.WriteLine(msg) |
| Process | Process.Start(info) | _processRunner.Start(info) |
Apply the same pattern for other members in each category.
Step 3: Add constructor injection
Add the new dependency following the class's existing pattern:
- Primary constructor (C# 12+): Add parameter to primary constructor:
public class OrderProcessor(ILogger<OrderProcessor> logger, TimeProvider timeProvider) - Traditional constructor: Add
private readonlyfield + constructor parameter, matching the existing field naming convention (_camelCaseorm_camelCase)
Step 4: Replace call sites
Perform each replacement mechanically. For each call site:
- Replace the static call with the wrapper call
- Preserve the surrounding code structure (whitespace, comments, chaining)
- Add required
usingdirectives if not already present
Adding using directives
| Abstraction | Using directive |
TimeProvider | None (in System namespace) |
IFileSystem | using System.IO.Abstractions; |
IHttpClientFactory | using System.Net.Http; (usually already present) |
| Custom wrappers | using <wrapper namespace>; |
Step 5: Update affected test files
If test files exist for the migrated classes:
- Update constructor calls — add the new parameter to test class instantiation
- Use test doubles:
TimeProvider→new FakeTimeProvider()fromMicrosoft.Extensions.TimeProvider.TestingIFileSystem→new MockFileSystem()fromSystem.IO.Abstractions.TestingHelpers- Custom wrappers →
new Mock<IWrapperName>()or hand-rolled fake
Step 6: Build verification
After all changes in the current scope:
dotnet build <project.csproj>If the build fails:
- Missing using: Add the required
usingdirective - Missing NuGet package: Run
dotnet add package <name> - Constructor mismatch in tests: Update test instantiation (Step 5)
- Ambiguous call: Fully qualify the wrapper call
Step 7: Report changes
Summarize what was done:
## Migration Summary
**Pattern**: DateTime.UtcNow → TimeProvider.GetUtcNow()
**Scope**: MyProject/Services/
### Files Modified (production)
| File | Call Sites Replaced | Injection Added |
|------|--------------------:|:----------------|
| OrderProcessor.cs | 3 | Yes (constructor) |
| NotificationService.cs | 1 | Yes (primary ctor) |
### Files Modified (tests)
| File | Change |
|------|--------|
| OrderProcessorTests.cs | Added FakeTimeProvider parameter |
### Remaining (out of scope)
- MyProject/Legacy/ — 8 call sites not migrated (different namespace)Validation
- All call sites in scope were replaced (none missed)
- Constructor injection added to all affected classes
- Field naming follows existing class conventions
- Required
usingdirectives added - Required NuGet packages referenced
- Build succeeds after migration
- Test files updated with appropriate test doubles
- No behavioral changes introduced (wrapper delegates directly to the static)
Common Pitfalls
| Pitfall | Solution |
| Replacing statics in test code | Only replace in production code; tests should use fakes/mocks |
| Breaking static classes | Static classes can't have constructors — use ambient context for these |
Missing FakeTimeProvider NuGet | Add Microsoft.Extensions.TimeProvider.Testing to test project |
| Replacing in expression-bodied members without updating return type | DateTime → DateTimeOffset when using TimeProvider.GetUtcNow() — verify type compatibility |
| Migrating too much at once | Stick to the defined scope — one project or namespace per run |
| Forgetting DI registration | Always verify Program.cs/Startup.cs has the registration before replacing call sites |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

