Deploy to RazorDev instead of RoslynDev

[sharwell]

• Deploy to RazorDev experimental instance instead of RoslynDev to avoid conflicts with Roslyn
• Let the integration test harness deploy the dependencies VSIX on demand, instead of relying on the VS SDK to do it as part of the build
• Always include Roslyn dependencies for integration test deployment

[sharwell]

📝 These were unnecessarily complex. The tooling knows how to derive the values from the referenced assemblies at build time.

[sharwell]

💭 This appears to be a duplicate of line 90 above.

[sharwell]

📝 There is no more need for this to be conditional. Since the integration test harness knows how to deploy the extension on demand, we can control the deployment exclusively from the integration test project that references this.

[sharwell]

📝 We aren't overriding a built-in extension, so this isn't considered an experimental version of an all-users extension.

[sharwell]

📝 I need to verify this is exactly what we want as a general solution, and get this moved over to microsoft/vs-extension-testing.

[sharwell]

📝 This is the part to make conditional if there are cases where we don't want to deploy the dependencies.

[sharwell]

📝 It wasn't clear why we need this flag. I've removed it for now, but maybe we need it for something?

[jjonescz]

FWIW, it was added in #8086

[davidwengier]

Deploy to RazorDev experimental instance instead of RoslynDev to avoid conflicts with Roslyn

What conflicts? I don't run into conflicts, and there are active benefits of the sharing of hives that I take advantage of regularly for local development. Surely the CI machines start clean and don't care what the hive name is?

[sharwell]

What conflicts? I don't run into conflicts, and there are active benefits of the sharing of hives that I take advantage of regularly for local development. Surely the CI machines start clean and don't care what the hive name is?

I was running into strange integration test behaviors due to other Roslyn contents existing in the experimental instance. I'm working on updating this to allow F5 to RoslynDev and run the integration tests by default in RazorDev.

[davidwengier]

That sounds like a recipe for a different type of disaster, where a run of an integration test fails locally, so I press F5 and am now running different code (or at best, have to build and deploy again).

I would rather not make a change to fix an issue unless it is something that regular razor contributors run into. It sounds like you probably could have cleared your RoslynDev hive and be unblocked.

[davidwengier]

Perhaps a separate PR would make sense, and provide a better space for discussion, distinct from the effort to improve integration tests in CI, which I assume the rest of the PR is about.

[sharwell]

That sounds like a recipe for a different type of disaster, where a run of an integration test fails locally, so I press F5 and am now running different code (or at best, have to build and deploy again).

The whole thing is automatic. Instead of F5 being a keystroke, it's a separate command that shows up in Test Explorer and you can select the scenario you want to launch or debug. The necessary components are detected according to the scenario and deployed automatically if necessary as part of launch.

[davidwengier]

Sorry, but when I want to debug my code, I press F5. If any proposed solution doesn't work with that, then its a non-starter, especially given I don't have the problem that it's solving.

[sharwell]

I'll keep that in mind should I ever be interested in moving this out of the draft state.

[sharwell]

/azp run razor-tooling-ci

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).