- Prior to this if a 15.8 VS was installed the VSIX creation target would fail due to a bug in the CLI we're currently pinned to (already fixed, we just haven't pulled it). The fix was removing the parallelism flags to msbuild to allow it to run unrestricted in regards to processor utilization.
- Changed the VS restrictions to ensure we don't use unsupported 15.9 bits that have breaking changes in their MSBuild bits (this has proven to be troublesome in the past).
- 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
Step 1: Add HostProject
This is a somewhat complex addition to the ProjectSnapshotManager. Now
that we accept updates from the underlying IDE project system we need to
coordinate those with the Workspace.
This means that ProjectSnapshot itself now also has a version concept.
Step 2: Introduce a new project system based on CPS
We use project capabilities defined by the Razor SDK to determine
whether to rely on MSBuild evaluation to detect the configuration or
whether to fallback to assembly-based detection.
Step 3: Flow RazorConfiguration everywhere
We use now expose the RazorConfiguration to the language service and
editor. This means that we no longer need to detect the project's
configuration asynchronously, it happens much faster now.
- Created a new `TestWorkspace` type to lock on `AdhocWorkspace` construction. This type can't be constructed/changed in parallel.
- Updated test usages of `AdhocWorkspace` to make use of `TestWorkspace`.
- Added a `Microsoft.CodeAnalysis.Razor.Workspaces.Test.Common` project to have the `TestWorkspace` type.
#1913
This is failing on the CI due to an issue with a newer build of the SDK.
I opened https://github.com/dotnet/sdk/issues/1854 to track the SDK bug.
- update korebuild
- upgrade deps
- remove System.Diagnostics.DiagnosticSource from test projects
This PR adds two new tools as well as a tasks project. None of these
projects produce a package and they ship as part of
Microsoft.AspNetCore.Razor.Design. For now this is a 'fat' package that
contains all of the dependencies, but we plan to strip them out in the
future.
The support for compilation at build-time will start as **off** by
default. The immediate goal here is to get this to flow through the
build so that we can test it as part of the inner loop effort. We will
enable this feature by default once we've done more thorough testing.
Since this is mostly a code dump, I plan to address blocking and minor
feedback only. If there are design issues that are non-critical, I will
open follow up items.
The next step will be to start adding more detailed tests.
- 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
- Removed the `Microsoft.VisualStudio.Language.IntelliSense` dependency from `Microsoft.VisualStudio.Editor.Razor` because it isn't supported in VS for mac.
- Replaced `ICompletionBroker` usage in the VS agnostic dll with a new abstract type `VisualStudioCompletionBroker`. This also enables us to implement completion
- Added Mac implementation of new `VisualStudioCompletionBroker`.
#1789
- 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
Pranav K
ASP.NET CI
Ryan Brandenburg
N. Taylor Mullen
Ryan Nowak
Nate McMaster
Ajay Bhargav Baaskaran
Nate McMaster