Another example for "Execute a command Multiple Times" when we have an existing collection. The existing example (which still remains) I found to be a little bit confusing when I had an existing collection. So hopefully this 2nd example will help a tiny bit.
Simplifying and improve build speed.
- Decreases builds from 8-13 minutes down to ~2 minutes (while running more tests)
- Moves to SQL Server 2019 on AppVeyor
- Moves the 2 longest running tests with params to `[FactLongRunning]`
- Bumps tests up to `netcoreapp3.1`
- Also fixes .Contrib tests
- Moves to `Build.csproj`
- Simplifies `build.ps1`
- Removed defunct `build.sh`
- Nukes `IsAppveyor` (moves to environmental variable overloads)
- Builds now work in Linux/macOS
This is prepping a run we can drop into the README easily. And more info on allocations and such along with it. It's finishing off the benchmark port getting it into a good output state (something we can copy/paste). It removes Simple.Data because the package was debug and causes a lot of issues.
This doesn't output 100% like we want yet (fastest to slowest). BenchmarkDotNet joins summary results after ordering...we need to post-order that. I'm asking the maintainers how to do so.
Also note Belgrade was not parameterizing before, giving it a huge unfair advantage. This has been fixed to be apples:apples.
Under the `List Support` section, the sentence opens with `Dapper allow you`, which should instead be `Dapper allows you`. This PR will correct this mistake, restoring balance to the universe.
After originally spotting this, the most minor of mistakes, I decided to leave it and move on with my life, since it likely effected nobody. Four hours passed and the thought that it existed unchecked had fully manifested itself within my subconscious and I was no longer able to continue with my existence knowing that I had seen this mistake and not exercised my power to correct it.
Thank you, and sorry.
Due to the way VS test works (by injecting an executable entry point), the performance tests needed to be factored out. I also organized all of our existing tests better along the way.
Actual code changes to Dapper itself are very minor, only formatting and documentation fixes (which we need many more of).
The build.ps1 script is upated to work, but note that <frameworkAssemblies> is not working in .nuspec inside the packages in the new .csproj system. I consider this to be a blocker. Issue is here: https://github.com/NuGet/Home/issues/4853
Pure Krome