coyote/Tests/Tests.Rewriting/Configurations/test1.coyote.json

{
  "AssembliesPath": "Input",
  "OutputPath": "Input/Output",
  "Assemblies": [
    "Test.dll"
  ]
}
Merged PR 2211: initial prototype for task binary rewriting How to run: ``` ..\coyote\bin\netcoreapp3.1\coyote.exe rewrite .\bin\netcoreapp3.1\example.coyote.json ``` Basically the `rewrite` tool option uses `PATH` to declare a JSON configuration file. Add `-d` to get some useful debugging info. Then just do regular `coyote test` on the rewritten binary. JSON: ```json { "AssembliesPath": "../../bin/netcoreapp3.1", "OutputPath": "../../bin/netcoreapp3.1/RewrittenBinaries", "Assemblies": [ "Example.dll" ], "Dependencies": [ "Microsoft.Coyote.dll", "Microsoft.Coyote.Test.dll", "Library.dll", "Example.runtimeconfig.json" ] } ``` If `OutputPath` is the same as `AssembliesPath`, then the original assemblies get overwritten. Discussion: The main components are an `AssemblyRewriter` that takes a JSON configuration file and uses that info to rewrite a set of assemblies (and their dependencies) and put them in some location (or overwrite original ones). That happens via "coyote rewrite". Once that is done, someone can just run "coyote test" and it should work as if someone wrote controlled tasks manually (ofc we need to push corner cases now, some APIs still I need to do, and support for build in mocks like TCS). We also have CI now, our existing run-test.ps1 script first rewrites the xUnit test project, that is only native tasks, and then it runs it (works only for .NET Core 3.1 via xUnit right now for some reason). The cool thing is that we do not use a custom `Coyote.Task` type anymore. The reason we needed a custom task type was purely to make the manual approach usable. A custom type gives us an awaitable object (because we cannot take control of `GetAwaiter` from native Task, when someone calls await on it), as well as allows you to have it as return type of an async method (for the state machine to be generated). Instead now we focus instrumentation on two aspects: (1) every generated async state machine is replaced with a custom `AsyncStateMachineBuilder` (this is similar to what we had before, but this time we can just replace it automatically as the state machine is already there in the IL , we don't need a custom type to do that for us), and (2) replace some Task methods with custom ones (e.g. `Task.Run` with `ControlledTask.Run`, `Delay`, `Yield`, and importantly `Task.GetAwaiter` with `ControlledTask.GetAwaiter`, to get a callback on an await point). You can think of `ControlledTask` as an "extension" method, not a custom type method (its a purely static class) so its much easier to replace (we don't need to replace `Task` with `Coyote.Task` in every single IL instruction ... as `ControlledTask` APIs just return native tasks, they are just a way to get hooks). Known issues: - Figure out how to make xUnit recognize rewritten assemblies with .NET Framework (.NET Core works fine). Related work items: #3911, #4378 2020-07-07 01:48:04 +03:00			`{`
			`"AssembliesPath": "Input",`
			`"OutputPath": "Input/Output",`
			`"Assemblies": [`
			`"Test.dll"`
			`]`
			`}`