- 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 the runtime package dependency to allow for proper assembly building.
- Added a new external package source for the MonoDevelop.Sdk.
- Had to change the MPack version to be compliant with VS for mac versioning support.
#1789
- As part of this work I also added `Microsoft.VisualStudio.Mac.LanguageServices.Razor` to be the Visual Studio for Mac specific Razor code.
- Added MSBuild infrastructure to automate creation of MonoDevelop addins (MPacks). This work enables us to not have a dependency on a specific version of monodevelop and does not require us to have tool-prerequisites on the box. Every build outputs the mpacks into the artifacts/build directory.
- Built in build-level metadata pieces to workaround how addins are typically developed. They are usually authored C# first and then config files are generated after the fact; with this changeset we auto-generate the addin.info and its corresponding assembly attributes. Both of these take information directly from the build system.
#1696
N. Taylor Mullen
Nate McMaster