Our library should now support .NET 4.6.1 and upwards. See: https://docs.microsoft.com/en-us/dotnet/standard/net-standard#net-implementation-support
Also now we support ConfigurationManager and loading user assembly configurations in all our targets :)
This moved to the tool, we dont need it when running programmatic, as the user can load their configurations on their own...
Upgrading to latest stylecop. This has new rules for catching some stuff like `.` in end of comments, etc. This will hopefully reduce my pedantic comments in PRs since it will catch this automatically :P
I also fixed the stuff stylecop catched that had escaped us :)
Add app insights to coyote.exe. In order to minimize the impact of the telemetry latency it runs a separate "coyote telemetry server" process that does the Azure stuff. This server times out after 60 seconds and goes away.
A customer can opt out by setting an environment variable COYOTE_CLI_TELEMETRY_OPTOUT to the value "1" or "true, so they can easily configure a PC to never send any telemetry. This is consistent with the dotnet variable called DOTNET_CLI_TELEMETRY_OPTOUT. There is also a heartbeat to keep the server alive until a long running test finishes. This ensures a 70 second test can to terminate quickly (with no need to wait to spin up another telemetry server).
coyote.exe also prints an extra message on first time usage based on the presence of a file named `C:\Users\Chris\AppData\Local\Microsoft\Coyote\CoyoteMachineId.txt`. This file contains a GUID for the machine which is used as the telemetry device context, which gives us a vague idea of # coyote users. The initial extra message is:
```
Welcome to Microsoft Coyote 1.0.7.0
---------------------------------
Telemetry is enabled
--------------------
Microsoft Coyote tools collect usage data in order to help us improve your experience.
The data is anonymous. It is collected by Microsoft and shared with the community.
You can opt-out of telemetry by setting the COYOTE_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true'.
Read more about Microsoft Coyote Telemetry at http://aka.ms/coyote-telemetry
Use 'coyote --help' to see the full command line options.
--------------------------------------------------------------------------------------------
```
![image.png](https://dev.azure.com/foundry99/975dff7e-f59d-4848-acf6-64bb21376650/_apis/git/repositories/dea8a739-31a5-40f5-aa4c-e44213d8791f/pullRequests/1994/attachments/image.png)
The info is available in F99-Coyote subscription under the dashboard:
![image (2).png](https://dev.azure.com/foundry99/975dff7e-f59d-4848-acf6-64bb21376650/_apis/git/repositories/dea8a739-31a5-40f5-aa4c-e44213d8791f/pullRequests/1994/attachments/image%20(2).png)
Related work items: #3493
Make Coyote build pick up the .NET frameworks that are installed so the
build does not fail if you are missing some .net 4.6, 4.7, or 4.8.
The solution is to have each .csproj specify one of the following:
```xml
<CoyoteTargetType>Library</CoyoteTargetType>
<CoyoteTargetType>Application</CoyoteTargetType>
<CoyoteTargetType>StandardLibrary</CoyoteTargetType>
```
Which is then interpreted in build.props with logic that checks for the install of .NET 4.6, 4.7 and 4.8 to build the final <TargetFrameworks> property, taking care of Linux where only dotnetcoreapp3.1 **exists.**
Related work items: #3145
add metadata for dotnet tool and update documentation and tutorials to use this version of the tool, which makes things simpler. The tool can be built using:
```
nuget pack .\Scripts\NuGet\Coyote.CLI.nuspec -OutputDirectory .\bin\nuget -Version 1.0.5
```
This results in a new nuget package named "Microsoft.CoyoteTool.1.0.3.nupkg", which can be installed using:
```
dotnet tool install --global --add-source ./bin/nuget Microsoft.Coyote.CLI
```
and now you can type "coyote" on the command line.
It is installed here: `C:\Users\Chris\.dotnet\tools\coyote.exe`.
and can be uninstalled with:
```
dotnet tool uninstall --global Microsoft.Coyote.CLI
```
Related work items: #2732
Finish CloudMessaging tutorials.
Fix coverage report involving Actors.
Add "category" to distinguish Actor, Monitor and StateMachine on the DGML diagrams.
Fix bugs related to having Actors in a state machine diagram. Specifically the "senderState" on events is null and so we need to handle that properly, both in the DGML generation and the SVG animations. Added animation to CoffeeMachine tutorial to test it out, since CoffeeMachine MockSensors is an Actor.
replace ILogger with TextWriter and move the implementation to ActorRuntimeLogTextFormatter to unify all logging done inside LogWriter and prepare the way for xml and json versions of this thing.
Related work items: #2125
Graph is consolidating events from one state to another so it shows up as one link, but if those are actually different event types it was forgetting that. This fix changes the Graph data structure so it can remember multiple event id's on a single link. The coverage report then uses that to produce the right result. The handling of Monitors was also slightly wrong where the [hot], [cold] state labels were not matching with the coverage report MachineStates info, so this has been changed to a graph label only, rather than being part of the node id.
Also changed things so that you can now do this on the coyote test command line:
```
--explore --coverage activity
```
and you get the combined coverage of all explorations, regardless of whether any bugs were found.
Related work items: #2037
Fix bug in handling of raised events so the links show up correctly. The problem was OnHandleRaisedEvent was trying to create a link immediately, but we don't yet know the impact of this raised event. For example, it might result in a OnEventGotoState transition, in which case we want the link on the diagram to reflect that. Fortunately the fix was very simple since I had a concept of dequeued events already.
Also added animating raft demo under http://127.0.0.1:4000/coyote/learn/core/demo.
Also added the beginnings of some tutorial content - more of a template really...
This PR renamed the command line tool from `Coyote` to `coyote` to make it much easier to write, and also follow the standard practice for the rest of the .NET ecosystem (e.g. similar to the `dotnet`, `nuget`, `msbuild` tools). Also renamed the appropriate bits in the documentation (hopefully did not miss any).
Related work items: #1107
Remove "colons" from command line options. Merge Tester and replay tool into new "coyote" tool. Also added Positional argument support to CommandLineParser.
```
d:\git\foundry99\Coyote>coyote test ..\CoyoteSamples\MachineExamples\bin\net46\FailureDetector.exe -i 100 -ms 10
. Testing ..\CoyoteSamples\MachineExamples\bin\net46\FailureDetector.exe
Starting TestingProcessScheduler in process 11348
... Created '1' testing task.
... Task 0 is using 'Random' strategy (seed:766).
..... Iteration #1
... Task 0 found a bug.
... Emitting task 0 traces:
..... Writing ..\CoyoteSamples\MachineExamples\bin\net46\Output\FailureDetector.exe\CoyoteTesterOutput\FailureDetector_0_10.txt
..... Writing ..\CoyoteSamples\MachineExamples\bin\net46\Output\FailureDetector.exe\CoyoteTesterOutput\FailureDetector_0_10.pstrace
..... Writing ..\CoyoteSamples\MachineExamples\bin\net46\Output\FailureDetector.exe\CoyoteTesterOutput\FailureDetector_0_10.schedule
... Elapsed 0.1360933 sec.
... Testing statistics:
..... Found 1 bug.
... Scheduling statistics:
..... Explored 1 schedule: 1 fair and 0 unfair.
..... Found 100.00% buggy schedules.
..... Number of scheduling points in fair terminating schedules: 54 (min), 54 (avg), 54 (max).
..... Exceeded the max-steps bound of '10' in 100.00% of the fair schedules.
... Elapsed 0.2428933 sec.
. Done
d:\git\foundry99\Coyote>coyote replay ..\CoyoteSamples\MachineExamples\bin\net46\FailureDetector.exe \git\foundry99\CoyoteSamples\MachineExamples\bin\net46\Output\FailureDetector.exe\CoyoteTesterOutput\FailureDetector_0_10.schedule
. Reproducing trace in ..\CoyoteSamples\MachineExamples\bin\net46\FailureDetector.exe
... Reproduced 1 bug.
... Elapsed 0.1342201 sec.
```
Related work items: #649, #713