Set DeployExtension=false in BuildAndTest.proj...

[KevinH-MS]

BuildAndTest.cmd already sets this property. We should have the same
behavior if you're performing the analogous operation in the "Open"
submodule. Since we never run IDE tests as a part of BuildAndTest, it
shouldn't matter that we don't deploy the extensions. Without this,
"msbuild BuildAndTest.proj" doesn't work on clean VS install.

[KevinH-MS]

FYI @dotnet/roslyn-infrastructure
/cc @TyOverby

[KevinH-MS]

I think it's best to just handle this in the "BuildAndTest" scripts for now (rather than pushing the logic deeper into our build .targets, because that would involve checking to see if the VS extensions folder contained Roslyn...presumably that logic would all have to change or go away once VsSdk starts preferring user local extensions over the ones installed in the VS extensions folder).

[TyOverby]

👍

[jaredpar]

CC @jasonmalinowski

Does setting the property in this way override properties that are explicitly set in the csproj / vbproj files? The previous solution of specifying on the command line does, but I'm unsure if this method will. If it doesn't then we need to modify the use of <DeployExtension>true</DeployExtension> in our code base.

[jasonmalinowski]

So there are two answers here:

1. This will override how you think it will.
2. This isn't what you want to do. I would expect as a end user calling BuildAndTest that it deploys my extensions to the hive. I 100% agree that we don't want to deploy on cibuild, but I would suspect you do want to isolate that decision into the cibuild scripts.

[jasonmalinowski]

And I guess following up to #2: I can totally imagine if you're turning this off real quick until we get Update 1 out and then we'll fix this all up. But this isn't what we want, Eventually™.

[KevinH-MS]

Bottom line is that, today, if you just install VS and don't uninstall the Roslyn msi, then "msbuild BuildAndTest.proj" generates errors. These errors are not at all informative to the uninitiated developer.

I would propose that we do this until we're able to fix this up on top of Update 1 (unless anyone is really relying on "msbuild BuildAndTest.proj" deploying their extensions...which I doubt...).

I assert that "everyone" is using "msbuild Roslyn.sln" to deploy extensions for testing.

[KevinH-MS]

Any strong objections? Going once...going twice...