Support VS "15" specific features #10812
Conversation
| @@ -17,6 +17,7 @@ | |||
| </config> | |||
| <packageSources> | |||
| <clear /> | |||
| <add key="local" value="C:\Code\Packages" /> | |||
There was a problem hiding this comment.
Obviously not correct - we'll need to push a real package.
|
Adding the rest of @dotnet/roslyn-ide to take a look. |
Pilchie
changed the title
| <StartAction>Program</StartAction> | ||
| <StartProgram>$(DevEnvDir)devenv.exe</StartProgram> | ||
| <StartArguments>/rootsuffix RoslynDev /log</StartArguments> | ||
| </PropertyGroup> |
There was a problem hiding this comment.
What happens if you F5 the Dev14 project from Dev15? What's supposed to happen?
There was a problem hiding this comment.
It will build and deploy the Dev14 stuff to Dev15 and run it without the lightup.
Pilchie
force-pushed
the
Dev15Build
branch
2 times, most recently
from
75e9871
to
5cb30d4
Compare
|
test vsi please |
|
retest vsi please |
Pilchie
changed the title
|
Ping @CyrusNajmabadi @davkean @jasonmalinowski @heejaechang @dotnet/roslyn-ide Can people start reviewing this "for real" now. I think it's ready to go. It doesn't make 100% of tests pass on Dev15 yet, but it unblocks development, and keeps Dev14 green. |
| @@ -15,7 +15,8 @@ | |||
| <AllowUnsafeBlocks>true</AllowUnsafeBlocks> | |||
| <SolutionDir Condition="'$(SolutionDir)' == '' OR '$(SolutionDir)' == '*Undefined*'">..\..\..\..\</SolutionDir> | |||
| <RestorePackages>true</RestorePackages> | |||
| <TargetFrameworkVersion>v4.5</TargetFrameworkVersion> | |||
| <TargetFrameworkVersion>v4.6</TargetFrameworkVersion> | |||
There was a problem hiding this comment.
Overall, are we moving to 4.6?
There was a problem hiding this comment.
Yes for future (in fact, I think @agocke already did it there). We can't for master for shipping projects, but since this is non-shipping, I felt comfortable updating it.
|
Looks mostly good to me. I think there's a cleaner dev approach that avoids needing |
|
Don't gate yourself on this feedback though |
|
retest vsi please |
|
retest vsi p2 please |
| Condition="'$(ForceGenerationOfBindingRedirects)' == 'true'"> | ||
|
|
||
| <PropertyGroup> | ||
| <!-- Needs to be set in a target because it has to be set after the initial evaluation in the common targets --> |
There was a problem hiding this comment.
Do we have a bug tracking this on the MSBuild side?
| @@ -44,7 +45,8 @@ class Q | |||
| var typeQ = assembly.GetType("Q"); | |||
|
|
|||
| string defaultDebuggeeSideVisualizerTypeName = "Microsoft.VisualStudio.DebuggerVisualizers.VisualizerObjectSource"; | |||
| string defaultDebuggeeSideVisualizerAssemblyName = "Microsoft.VisualStudio.DebuggerVisualizers, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"; | |||
| var vsVersion = Environment.GetEnvironmentVariable("VisualStudioVersion") ?? "14.0"; | |||
There was a problem hiding this comment.
Share in a test helper somewhere?
|
👍, modulo various nitpicks. Only clear functional problem I saw was the use of types from Roslyn.VisualStudio.Setup.dll which we don't ship, and thus might break various things at runtime. |
1. Reference a bunch of stuff from Nuget packages instead of VS. 2. Move to Update 2 versions of packages. 3. Now that we are using the packages, we're referencing Microsoft.VisualStudio.Shell.14.dll instead of .15 again. This means that types that moved to Shell.Immutable.15 are not type forwarders. Luckily we didn't need anything from Shell.Immutable.15 in the project where it was a problem.
More cleanup to do between RoslynCompletionSet and FilteredRoslynCompletionSet.
|
retest vsi please |
Changing to NuGet packages meant that we were referencing some older
versions of things causing us problems:
can use the v14 assembly since it in turn references other things we
normally get from NuGet.
Microsoft.VisualStudio.Shell.14.dll instead of .15 again. This means
that types that moved to Shell.Immutable.15 are not type forwarders.
Luckily we didn't need anything from Shell.Immutable.15 in the project
where it was a problem.