Added a duality test launcher for use in unit tests/benchmarks etc

[Barsonax]

After making debugging benchmarks a bit easier and more strict I found out that we actually get a exception in the cleanup of the serialization benchmark.

Changes

• Adds a DualityTestLauncher which purpose is to launch duality in such a way that it works well with unit tests, benchmarks etc. I used this in the SerializerBenchmarks so that it uses the same environment that the unit tests are using.
• Added a warning that when a benchmark is run and a debugger is attached that DebugInProcessConfig is used since this might affect benchmarks results.
• Added ExecutionValidator.FailOnError to the benchmark runner when debugger is attached to make it easier to find errors. What this does is run each benchmark only 1 itteration just to verify if its working or not before doing the actual benchmark.

We might want to consider putting the DualityTestLauncher class in core or putting it in a separate nuget package as users might wanna use this class for their own unit tests.

EDIT: seems changing the working directory was to fix something nunit specific so having a separate DualityTestLauncher is not needed

[Barsonax]

Hmm just noticed that the working directory only changes to C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE when running the unit tests.

In the benchmarks its already correct so no need actually to switch the working directory.

Actually it seems to be nunit specific. With xunit the working directory is correctly set already. Nunit does not do this, they do however provide a TestContext.CurrentContext.TestDirectory to easily get the directory where the test is in so we could change the current code to be like this:

            this.oldEnvDir = Environment.CurrentDirectory;
            Console.WriteLine("Testing Core Assembly: {0}", TestContext.CurrentContext.TestDirectory);
            Environment.CurrentDirectory = TestContext.CurrentContext.TestDirectory;

EDIT: on a side note why does LoadPlugin(Assembly pluginAssembly, string pluginFilePath) take a path? Wouldnt typeof(DualityTestsPlugin).Assembly.Location already have the path you need? Also currently in the InitDualityAttribute its using the path of Duality.dll and not DualityTests.dll. I think you could just do this:

            // Manually register pseudo-plugin for the Unit Testing Assembly
            this.unitTestPlugin = DualityApp.PluginManager.LoadPlugin(
                typeof(DualityTestsPlugin).Assembly,
                typeof(DualityTestsPlugin).Assembly.Location);

Or modify LoadPlugin to do this for you. @ilexp

[ilexp]

Or modify LoadPlugin to do this for you. @ilexp

Actually, I don't think Assembly.Location is defined for assemblies that were anonymously loaded from a byte[], as is done for all plugins to avoid various issues. And since the overload you mentioned is used by both the regular load and reload methods, the path needs to be passed. It's just the one special case for unit test classes that's different.

            // Manually register pseudo-plugin for the Unit Testing Assembly
            this.unitTestPlugin = DualityApp.PluginManager.LoadPlugin(
                typeof(DualityTestsPlugin).Assembly,
                typeof(DualityTestsPlugin).Assembly.Location);

This should be fine though 👍

[Barsonax]

Or modify LoadPlugin to do this for you. @ilexp

Actually, I don't think Assembly.Location is defined for assemblies that were anonymously loaded from a byte[], as is done for all plugins to avoid various issues. And since the overload you mentioned is used by both the regular load and reload methods, the path needs to be passed. It's just the one special case for unit test classes that's different.

Correct. Location is null I think or throws a error when the assembly is loaded from a byte array.

          // Manually register pseudo-plugin for the Unit Testing Assembly
          this.unitTestPlugin = DualityApp.PluginManager.LoadPlugin(
              typeof(DualityTestsPlugin).Assembly,
              typeof(DualityTestsPlugin).Assembly.Location);

This should be fine though 👍

Will make a PR to cleanup that part later.