- Tied into VS4Macs ProjectExtensions in order to bootstrap our Razor world.
- We currently watch all DotNet projects with the expectation that they're the only ones that can potentially turn into Razor compatible projects.
- Added a fallback Razor project host which is used for pre-Razor SDK Razor versions (< 2.1).
- Added a default Razor project host which consumes all MSBuild data from the users packages and sets up the Razor world accordingly.
- Had to modify some existing contracts to work better with new expectations. one of these was the VS4Mac specific Workspace accessor; essentially we needed to be able to lookup a workspace from a solution.
- Some of our previous expectations about addins were wrong (not being able to directly reference your libraries). To avoid using reflection to bootstrap our types I tried out directly referencing our libraries and all worked fine.
- Refactored the DefaultRazorProjectHost in windows (since we had to in Mac) for testing purposes.
#2081
- Added a LanguageServices Mac test project.
- Added a few tests for the new `DefaultFileChangeTracker`. There's currently an issue with the MonoDevelop.Core binaries we're compiling against which doesn't allow me to unit test other pieces of the class (they depend on instantiating mono develop objects).
- Added IVT from product projects to new mac testing project.
#1789
- Moved the existing error reporter factory temporarily into the windows specific language service assembly so it did not conflict with the Mac specific implementation. The Windows VS API will be exposed later via https://github.com/aspnet/Razor/issues/1795.
- Updated the error reporter factory to specify service layers so the VS for mac implementation took priority.
#1789
N. Taylor Mullen