- Desktop requests would require that the tool be booted in desktop, therefore we can't resolve TagHelpers without dispatching in some form. If a packages entire graph is package based then we can ensure that a call to `AssemblyLoadContext.Load` returns loaded bits from the .nuget/packages folder on the current box.
- Can't easily automate tests due to lack of end-to-end infrastructure dictated by #62.
#70
- Prior to this change we'd only ever pack the x64 variation of `dotnet-razor-tooling.exe`.
- Left the lib directory in touch for unit testing purposes.
#72
- Previous to this any net451 projects that Razor-tooling would attempt to load would explode.
- We now dispatch to ourselves within a users output to ensure that all dependencies are matched up correctly.
- Added framework/configuration options to enable dispatching to properly find where our counterpart exists in a projects output.
- Renamed bin directory option to build base path. With dispatching logic VisualStudio can't easily determine the users RID which is required for an output path to dotnet.
- Replaced `AssemblyLoadContext` logic with `Assembly.Load` since we now always invoke ourselves in an environment where `Assembly.Load` is accurate. This way logic in the desktop process and non-desktop processes are identical.
- Broke the `ResolveTagHelpersCommand` into 3 pieces so we can determine dispatching logic at the Program.Main level. This was required to use pieces of the `DotnetToolDispatcher`.
- We utilize DotnetToolDispatcher for dispatch logic, this also ensures that we never have mismatched references for dotnet-razor-tooling in tools/dependencies sections.
- Worked around an issue in `ProjectDependenciesCommandFactory` where configuration isn't properly flowed from constructor to `Create` method: https://github.com/dotnet/cli/issues/2512
- Worked around an issue where binding redirects were not being created for executable desktop packages. This involved upping Newtonsoft.Json to 8.0.3: https://github.com/dotnet/cli/issues/2505#55