Add profile generators for Visual Studio #7774

trippwill · 2020-09-29T11:22:21Z

This commit adds dynamic profile generators for Visual Studio Developer
Command Prompt (VS2017+) and Visual Studio Developer PowerShell
(VS2019.2+)

Tested manually by deploying locally. My local environment has four
instances of VS installed, one VS2017 and multiple channels of VS2019.

We're wrapping the COM Visual Studio Setup Configuration API to query
for VS instances and retrieve the relevant properties. Two different
namespaces are used so the end-user can turn off one or the other. For
instance, end user may prefer to always use Developer PowerShell.

Validation Steps Performed

Build locally using Visual Studio 2019
Deploy CascadiaPackage
Verify entries exist in profiles menu
Verify entries exist in settings.json
Open each profile
Validate start-in directory
Validate environment variables are as expected
Uninstall Windows Terminal - Dev package
Repeat.

Closes #3821

github-actions · 2020-09-29T11:25:57Z

New misspellings found, please review:

Dyanmic
ISetup
LPSAFEARRAY
rgsabound
ULONGLONG
vsdevshell

To accept these changes, run the following commands

perl -e '
my @expect_files=qw('".github/actions/spell-check/expect/alphabet.txt
.github/actions/spell-check/expect/expect.txt
.github/actions/spell-check/expect/web.txt"');
@ARGV=@expect_files;
my @stale=qw('"akb appdata Autogenerated debian debugbreak decf DECLL DECSMBV esa guidgenerator Inplace keith keybound notypeopt openlogo restrictederrorinfo richturn Scs Switchto winver Wlk wslhome "');
my $re=join "|", @stale;
my $suffix=".".time();
my $previous="";
sub maybe_unlink { unlink($_[0]) if $_[0]; }
while (<>) {
  if ($ARGV ne $old_argv) { maybe_unlink($previous); $previous="$ARGV$suffix"; rename($ARGV, $previous); open(ARGV_OUT, ">$ARGV"); select(ARGV_OUT); $old_argv = $ARGV; }
  next if /^($re)(?:$| .*)/; print;
}; maybe_unlink($previous);'
perl -e '
my $new_expect_file=".github/actions/spell-check/expect/e9e91c5d0476f3a2aa7bf307e993dff2961c6bc2.txt";
open FILE, q{<}, $new_expect_file; chomp(my @words = <FILE>); close FILE;
my @add=qw('"autogenerated Debian Dyanmic inplace ISetup LPSAFEARRAY rgsabound ULONGLONG vsdevshell WINVER "');
my %items; @items{@words} = @words x (1); @items{@add} = @add x (1);
@words = sort {lc($a) cmp lc($b)} keys %items;
open FILE, q{>}, $new_expect_file; for my $word (@words) { print FILE "$word\n" if $word =~ /\w/; };
close FILE;'
git add .github/actions/spell-check/expect || echo '... you want to ensure .github/actions/spell-check/expect/e9e91c5d0476f3a2aa7bf307e993dff2961c6bc2.txt is added to your repository...'

✏️ Contributor please read this

By default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.

⚠️ The command is written for posix shells. You can copy the contents of each perl command excluding the outer ' marks and dropping any '"/"' quotation mark pairs into a file and then run perl file.pl from the root of the repository to run the code. Alternatively, you can manually insert the items...

If the listed items are:

... misspelled, then please correct them instead of using the command.
... names, please add them to .github/actions/spell-check/dictionary/names.txt.
... APIs, you can add them to a file in .github/actions/spell-check/dictionary/.
... just things you're using, please add them to an appropriate file in .github/actions/spell-check/expect/.
... tokens you only need in one place and shouldn't generally be used, you can add an item in an appropriate file in .github/actions/spell-check/patterns/.

See the README.md in each directory for more information.

🔬 You can test your commits without appending to a PR by creating a new branch with that extra change and pushing it to your fork. The :check-spelling action will run in response to your push -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. 😉

⚠️ Reviewers

At present, the action that triggered this message will not show its ❌ in this PR unless the branch is within this repository.
Thus, you should make sure that this comment has been addressed before encouraging the merge bot to merge this PR.

zadjii-msft · 2020-09-29T12:40:39Z

Okay, this is pretty neat:

Though, off the top of my head, this took a good bit of time on launch to be able to populate these entries. I'm worried that if we enable these for every user by default, we'll get a bunch of complaints about how long this takes to load.

I suppose these could be added to defaults.json's disabledProfileSources, and users who wanted to enable them could add "disabledProfileSources": [] to their settings, though that does seem un-intuitive.

WSLUser · 2020-09-29T12:51:47Z

Eh I think the profiles should be minimal. I already don't want the Azure by default and now we want to add Visual Studio, which we all know has huge performance issues. Maybe we could do more perf optimization on this end but most of it needs to come from VS. IMO this is better as an extension (same with Azure). If we want to add this now, it definitely should be disabled by default. I think it should also check if VS is even installed prior to attempting to create these profiles. Maybe it is and I can't tell (My C++ experience is very limited). Maybe add some more comments to clarify everything a bit more.

zadjii-msft · 2020-09-29T13:39:25Z

Ideally, yes, this and the azure cloud shell would both be extensions. This looks like it's the right way to detect VS versions. I bet that there's not a faster way of doing it either, we're probably at the mercy of the perf of Microsoft.VisualStudio.Setup.Configuration code itself.

Maybe we'll want to do this as a proto-extension like @PankajBhojwani is working on over in #7584/#7632. In this case, we'd have VS ship code that would synthesize these profiles themselves, and then leave them for the Terminal to detect at a later time. If this is the path we want to pursue, we'd want to make sure to work with the VS team directly to get them to incorporate this code into VS on their end.

IMO, (after reviewing the code closer of course), I'm okay with this going in for now as a disabled-by-default dynamic source, and then moving it to an extension (when those are officially supported).

WSLUser · 2020-09-29T13:49:42Z

we're probably at the mercy of the perf of Microsoft.VisualStudio.Setup.Configuration code itself.

This is what I was thinking. Maybe you can internally file a perf bug for them while engaging in discussions as serving as a proto-extension. I think that would be a fantastic idea.

trippwill · 2020-09-29T14:56:03Z

I'm happy to add more comments, especially around the VS Setup Configuration code.

While the generators always run, the CoCreateInstance in VsSetupConfiguration::QueryInstances will return null if VS is not installed, so that method will return an empty vector. Then the actual generators would have nothing to iterate over.
The EnumInstances in QueryInstances is also probably a hot-spot. Currently, it runs twice, once each for Developer PowerShell and DeveloperCommandPrompt. The instances could be cached, so that EnumInstances only has to run once. We could even cache the result of any of the COM calls so that they only happen once as well.
I'm normally a C# dev, so there's likely some opportunities for improvement I haven't seen :-) More use of std::string_view maybe?
FYI - ISetupConfiguration et al are the same mechanism used by vswhere and the VsSetup PowerShell module. So one way or another, those interop calls are getting made.
One of the advantages to this approach is that it will work for any supported version of Visual Studio. Currently hard-coded as VS 2017 for Developer Command Prompt. If VS needs to ship an update that installs the profiles into an extension directory, it would only support new versions of VS going forward, and also might never happen.
Full disclosure, I work on the VS team, and authored much of the Developer PowerShell module. I wrote this generators change in my spare time over a weekend, but @zadjii-msft feel free to ping me if you want to start an internal discussion.

WSLUser · 2020-09-29T15:36:43Z

Bullet 1: Probably could get some minor optimization by preventing the generators from running in first place. Since this is to be disabled by default, you could add something that ties to the default setting and attempt to run if a user explicitly chooses to enable the profile source.

Bullet 2: You should be able to write something up that consolidates both in one go instead of iterating over it twice. This project does tend towards code re-use where possible. Beyond that, not sure if there's anything within the TIL libraries or deps such as FMT that could help but might be worth a look.

zadjii-msft · 2020-09-29T15:49:57Z

. Beyond that, not sure if there's anything within the TIL libraries or deps such as FMT that could help but might be worth a look.

Frankly, I don't think those are going to be of that much help. From what I remember, when we added vswhere support to the razzle script, it seemed to slow down razzle by just about the same amount that I'm seeing in this PR during the Terminal startup. That's why I'm thinking it's something that either needs to be fixed upstream (probably unlikely tbh), or needs to be moved to some sort of external source, so it doesn't run on every Terminal launch.

The proto-extension solution isn't a bad solution here, because we'll be able to pass the "enumerate VS installs" cost on to VS, who will be able to leave the profile(s) behind after it runs it's startup.

/cc @PankajBhojwani for discussion of proto extensions

trippwill · 2020-09-29T16:16:36Z

With the proto extensions approach, it wouldn't even need to be VS itself. A third party powershell script or small command line tool could do it, and be developed in the open using the same ISetupConfiguration approach used here. A distinct tool would also have the same advantage of being able to generate profiles for any supported VS version.

All that said, I have no strong objection to the generators being default disabled. As an avid VS user, the sooner I can stop trying to manually craft the complex complex command-line for Developer PowerShell, the better. (There's a lot of quote escaping!).

How about I take a crack at caching the VsSetupInstances and making the generators off by default?

trippwill · 2020-09-30T19:22:38Z

This one should feel a bit snappier

zadjii-msft · 2020-09-30T19:25:11Z

oh my gosh I know exactly what I did wrong.

This PR was the first time I built & ran the Terminal since coming back from paternity leave. We didn't have the jumplist added when I left. So I mistakenly attributed the longer startup time to this PR, when in actuality, the slowdown was probably primarily from the jumplist. That's my bad 🤦‍♂️

github-actions · 2020-09-30T19:26:03Z

New misspellings found, please review:

Dyanmic
ISetup
ULONGLONG
vsdevshell

To accept these changes, run the following commands

perl -e '
my @expect_files=qw('".github/actions/spell-check/expect/alphabet.txt
.github/actions/spell-check/expect/expect.txt
.github/actions/spell-check/expect/web.txt"');
@ARGV=@expect_files;
my @stale=qw('"akb appdata Autogenerated debian debugbreak decf DECLL DECSMBV esa guidgenerator Inplace keith keybound notypeopt openlogo restrictederrorinfo richturn Scs Switchto winver Wlk wslhome "');
my $re=join "|", @stale;
my $suffix=".".time();
my $previous="";
sub maybe_unlink { unlink($_[0]) if $_[0]; }
while (<>) {
  if ($ARGV ne $old_argv) { maybe_unlink($previous); $previous="$ARGV$suffix"; rename($ARGV, $previous); open(ARGV_OUT, ">$ARGV"); select(ARGV_OUT); $old_argv = $ARGV; }
  next if /^($re)(?:$| .*)/; print;
}; maybe_unlink($previous);'
perl -e '
my $new_expect_file=".github/actions/spell-check/expect/14cc46d76d8c8d85595fe66eac5f4045eb69e269.txt";
open FILE, q{<}, $new_expect_file; chomp(my @words = <FILE>); close FILE;
my @add=qw('"autogenerated Debian Dyanmic inplace ISetup ULONGLONG vsdevshell WINVER "');
my %items; @items{@words} = @words x (1); @items{@add} = @add x (1);
@words = sort {lc($a) cmp lc($b)} keys %items;
open FILE, q{>}, $new_expect_file; for my $word (@words) { print FILE "$word\n" if $word =~ /\w/; };
close FILE;'
git add .github/actions/spell-check/expect || echo '... you want to ensure .github/actions/spell-check/expect/14cc46d76d8c8d85595fe66eac5f4045eb69e269.txt is added to your repository...'

✏️ Contributor please read this

By default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.

⚠️ The command is written for posix shells. You can copy the contents of each perl command excluding the outer ' marks and dropping any '"/"' quotation mark pairs into a file and then run perl file.pl from the root of the repository to run the code. Alternatively, you can manually insert the items...

If the listed items are:

... misspelled, then please correct them instead of using the command.
... names, please add them to .github/actions/spell-check/dictionary/names.txt.
... APIs, you can add them to a file in .github/actions/spell-check/dictionary/.
... just things you're using, please add them to an appropriate file in .github/actions/spell-check/expect/.
... tokens you only need in one place and shouldn't generally be used, you can add an item in an appropriate file in .github/actions/spell-check/patterns/.

See the README.md in each directory for more information.

🔬 You can test your commits without appending to a PR by creating a new branch with that extra change and pushing it to your fork. The :check-spelling action will run in response to your push -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. 😉

⚠️ Reviewers

At present, the action that triggered this message will not show its ❌ in this PR unless the branch is within this repository.
Thus, you should make sure that this comment has been addressed before encouraging the merge bot to merge this PR.

trippwill · 2020-09-30T19:33:08Z

I saw JumpList on the hot path when I did some profiling. Especially CShellLink::SetPath

trippwill · 2020-10-01T10:47:54Z

The caching is implemented, comments added. What are my next steps for review?

zadjii-msft · 2020-10-01T10:56:42Z

Probably nothing more at this point - just wait till we get some time to review in depth 😜 I'd want to make sure the @DHowett gets a chance to sign off on this one as well, but he's got a full week of meetings unfortunately, so it might be a little while before we can get you two reviews

@msftbot make sure @DHowett signs off on this

github-actions · 2020-10-01T11:26:48Z

New misspellings found, please review:

automatially

To accept these changes, run the following commands

perl -e '
my @expect_files=qw('".github/actions/spell-check/expect/alphabet.txt
.github/actions/spell-check/expect/expect.txt
.github/actions/spell-check/expect/web.txt"');
@ARGV=@expect_files;
my @stale=qw('"akb appdata Autogenerated debian debugbreak decf DECLL DECSMBV esa guidgenerator Inplace keith keybound notypeopt openlogo restrictederrorinfo richturn Scs Switchto winver Wlk wslhome "');
my $re=join "|", @stale;
my $suffix=".".time();
my $previous="";
sub maybe_unlink { unlink($_[0]) if $_[0]; }
while (<>) {
  if ($ARGV ne $old_argv) { maybe_unlink($previous); $previous="$ARGV$suffix"; rename($ARGV, $previous); open(ARGV_OUT, ">$ARGV"); select(ARGV_OUT); $old_argv = $ARGV; }
  next if /^($re)(?:$| .*)/; print;
}; maybe_unlink($previous);'
perl -e '
my $new_expect_file=".github/actions/spell-check/expect/932e818e1503b362d6e8b02bc319947f1ed75911.txt";
open FILE, q{<}, $new_expect_file; chomp(my @words = <FILE>); close FILE;
my @add=qw('"autogenerated automatially Debian inplace WINVER "');
my %items; @items{@words} = @words x (1); @items{@add} = @add x (1);
@words = sort {lc($a) cmp lc($b)} keys %items;
open FILE, q{>}, $new_expect_file; for my $word (@words) { print FILE "$word\n" if $word =~ /\w/; };
close FILE;'
git add .github/actions/spell-check/expect || echo '... you want to ensure .github/actions/spell-check/expect/932e818e1503b362d6e8b02bc319947f1ed75911.txt is added to your repository...'

✏️ Contributor please read this

By default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.

⚠️ The command is written for posix shells. You can copy the contents of each perl command excluding the outer ' marks and dropping any '"/"' quotation mark pairs into a file and then run perl file.pl from the root of the repository to run the code. Alternatively, you can manually insert the items...

If the listed items are:

... misspelled, then please correct them instead of using the command.
... names, please add them to .github/actions/spell-check/dictionary/names.txt.
... APIs, you can add them to a file in .github/actions/spell-check/dictionary/.
... just things you're using, please add them to an appropriate file in .github/actions/spell-check/expect/.
... tokens you only need in one place and shouldn't generally be used, you can add an item in an appropriate file in .github/actions/spell-check/patterns/.

See the README.md in each directory for more information.

🔬 You can test your commits without appending to a PR by creating a new branch with that extra change and pushing it to your fork. The :check-spelling action will run in response to your push -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. 😉

⚠️ Reviewers

At present, the action that triggered this message will not show its ❌ in this PR unless the branch is within this repository.
Thus, you should make sure that this comment has been addressed before encouraging the merge bot to merge this PR.

PankajBhojwani · 2020-10-01T16:06:18Z

If we go the proto-extensions route we incur a cost on start-up time by needing to query for the json files - if that cost is much smaller than querying for VS installations then that might be the better way to go (I am not sure how vswhere works so I cannot say for sure).

I do want to say that this does seem like quite a perfect use case for proto extensions though, and if we want to encourage the use of that instead of adding more dynamic profile generators to our codebase then that is something we should talk about too. As said above, would definitely want @DHowett's opinion on this.

ghost · 2021-09-13T15:46:24Z

Hello @zadjii-msft!

Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:

I'll only merge this pull request if it's approved by @DHowett

If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you".

lhecker

The code looks correct to me.

To be honest I'm not entirely happy about the verbosity of the code. I believe it would've been easier to understand if it wasn't split into two sub-classes.
Additionally I see that VsSetupConfiguration::QueryInstances() is cached (because it's a slow call I assume?), but due to it being two sub-classes the function is still called twice during launch, defeating the purpose of the cache. Ah I didn't realize that you store it in a static member. I'm sorry for that. Although that's not quite thread-safe. 😅 (I'm mentioning this because I've been thinking about running generators concurrently.)

I'd like to merge it regardless of my opinion though, as it can still be improved upon later on.

DHowett · 2021-09-13T17:12:02Z

Thanks so much for doing this!

I pushed Microsoft.VisualStudio.Setup.Configuration.Native 2.3.2262 to TerminalDependencies!

DHowett

I really like this. Well done! Thank you.

We're in the home stretch for this nearly one-year-old PR. Good lord. Thanks for bearing with us.

DHowett · 2021-09-13T17:14:50Z

NuGet.Config

 <configuration>
    <packageSources>
        <clear />
        <!-- Dependencies that we can turn on to force override for testing purposes before uploading. -->
        <!--<add key="Static Package Dependencies" value="dep\packages" />-->
        <add key="TerminalDependencies" value="https://pkgs.dev.azure.com/ms/terminal/_packaging/TerminalDependencies/nuget/v3/index.json" />
+        <!-- !!! THIS NEEDS TO BE REMOVED BEFORE MERGE. The Microsoft.VisualStudio.Setup.Configuration.Native package needs to be added to the upstream source !!! -->
+    	<add key="nuget.org" value="https://api.nuget.org/v3/index.json"/>


During conflict resolution, you can finally back this one on out 😄

DHowett · 2021-09-13T17:19:51Z

src/cascadia/TerminalSettingsModel/VsSetupConfiguration.cpp

+/// <summary>
+/// Takes a relative path under a Visual Studio installation and returns the absolute path.
+/// </summary>
+std::wstring VsSetupConfiguration::ResolvePath(ComPtrSetupInstance pInst, std::wstring_view relativePath)


minor nit about these -- since the ComPtr argument is taken by copy, each of these causes an AddRef/Release (presumably, unless the compiler is smart?) on its argument for every call. It may not be necessary if the caller is holding an owning reference.

I believe the idiomatic way to take non-owning parameters is via raw pointer arguments (ala xxxSetupInstance*).

A less-idiomatic way, which requires the holder to have a wil::com_ptr themselves, is to slap a const & on it. 😁

DHowett · 2021-09-13T17:20:39Z

src/cascadia/TerminalSettingsModel/VsSetupConfiguration.cpp

+
+    unsigned long long minVersion{ 0 };
+    unsigned long long maxVersion{ 0 };
+    THROW_IF_FAILED(helper->ParseVersionRange(range.data(), &minVersion, &maxVersion));


FWIW: In our specific case, the string views we are passing are null-terminated. That's a side effect of them being compiled-in; there's no general guarantee that a string_view is null-terminated. This will work fine, but we'll want to be careful if we ever allow people to specify their own version ranges!

ghost · 2021-09-15T20:07:16Z

Hello @DHowett!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

DHowett · 2021-09-15T22:20:14Z

Thanks so much for this!

kasper93 · 2021-09-22T20:17:45Z

Sorry to bring back closed PR to life, but is there a way to setup it to run x64 prompt by default? I still have my custom profile which calls vcvars64.bat. It is nice addition, but well unless you want to build 32-bit binaries it is kind of useless :)

lhecker · 2021-09-22T20:38:33Z

@kasper93 That's a good point! VS features 6 items in the start menu:

miniksa · 2021-09-22T20:40:11Z

Sorry to bring back closed PR to life, but is there a way to setup it to run x64 prompt by default? I still have my custom profile which calls vcvars64.bat. It is nice addition, but well unless you want to build 32-bit binaries it is kind of useless :)

Let's file a new issue at this point to represent adding preferences to the profile generator like which architecture is prioritized. Thanks!

DHowett · 2021-09-22T20:40:46Z

So, the way I found to do it is to edit the profile generated by this generator and add -DevCmdArguments "-arch=x64 -host_arch=x64" or something to the Enter-VsDevShell arguments, or add -arch ... directly to the vsdevcmd.cmd arguments.

## Summary of the Pull Request Similar to `vswhere -latest`, show only the latest Visual Studio command prompts / developer PowerShell. This was tested by deleting the local package state and testing against fresh state with both VS2019 and VS2022 Preview installed, and indeed VS2022 Preview (both cmd and powershell) show. The other profiles were generated but hidden by default. ## References Modification of PR #7774 ## PR Checklist * [x] Closes #11307 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema updated. * [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx ## Detailed Description of the Pull Request / Additional comments The sort algorithm is the same basic algorithm I used in https://github.com/microsoft/vswhere. It sorts first by installation version with a secondary sort based on the install date in case the installation versions are the same. ## Validation Steps Performed With both VS2019 and VS2022 Preview installed, I made sure the initial state was expected, and tried different combinations of hiding and unhiding generated entries, and restarted Terminal to make sure my settings "stuck".

ghost · 2021-10-20T17:07:43Z

🎉Windows Terminal Preview v1.12.2922.0 has been released which incorporates this pull request.:tada:

Handy links:

This is a fever dream I had in response to the GDK PR we just got. I had to write it down immediately. I'm in no rush to get this in. References: * #1571 * #11326 * #7774

Doc updated in response to some discussion in [#11326] and [#7774]. In those PRs, it became clear that there needs to be a simple way of collecting up a whole group of profiles automatically for sorting in these menus. Although discussion centered on how hard it would be for extensions to provide that customization themselves, the `match` statement was added as a way to allow the user to easily filter those profiles themselves. This was something we had originally considered as a "future consideration", but ultimately deemed it to be out of scope for the initial spec review. References: * #1571 * #11326 * #7774

The PowerShell equivalent was added in the initial pull request, #7774.

The PowerShell equivalent was added in the initial pull request, #7774. Closes #13721

The PowerShell equivalent was added in the initial pull request, #7774. Closes #13721 (cherry picked from commit f06cd17) Service-Card-Id: 88719282 Service-Version: 1.17

Add profile generators for Visual Studio

e9e91c5

trippwill marked this pull request as ready for review September 29, 2020 11:22

Fix Code Formatting

a70adbd

Cache QueryInstances results

14cc46d

This comment has been minimized.

Sign in to view

zadjii-msft mentioned this pull request Oct 1, 2020

Optimize the creation of the jumplist entries #7791

Closed

Use smart pointers during VS Setup enumeration

932e818

zadjii-msft assigned DHowett Oct 1, 2020

lhecker approved these changes Sep 13, 2021

View reviewed changes

DHowett approved these changes Sep 13, 2021

View reviewed changes

DHowett removed the AutoMerge Marked for automatic merge by the bot when requirements are met label Sep 13, 2021

DHowett added 3 commits September 15, 2021 15:03

Merge remote-tracking branch 'origin/main' into HEAD

e7b2b43

Fix code format

a0d01b8

Remove <MUST BE REMOVED> lines from nuget.config

f33b486

DHowett added the AutoMerge Marked for automatic merge by the bot when requirements are met label Sep 15, 2021

Remove the BOM from NuGet.Config (reduce diff)

c750e07

DHowett merged commit f84da18 into microsoft:main Sep 15, 2021

zadjii-msft mentioned this pull request Sep 22, 2021

Visual Studio Generator should probably prefer x64 tools when available #11307

Closed

heaths mentioned this pull request Sep 24, 2021

Show only latest VS, VC prompts by default #11326

Merged

6 tasks

ghost mentioned this pull request Oct 20, 2021

Add Developer PowerShell and Developer Command Prompt Generator #3821

Closed

zadjii-msft mentioned this pull request Feb 25, 2022

Spec for "matching" profiles in "New Tab Customization" #12584

Merged

zadjii-msft mentioned this pull request Apr 18, 2022

App Crash - Try using VS2022 developer command prompt #12918

Closed

DHowett added a commit that referenced this pull request Mar 23, 2023

VsDevCmdGenerator: respect the user's startingDirectory

a5b06b4

The PowerShell equivalent was added in the initial pull request, #7774.

DHowett mentioned this pull request Mar 23, 2023

VsDevCmdGenerator: respect the user's startingDirectory #15035

Merged

DHowett added a commit that referenced this pull request Mar 23, 2023

VsDevCmdGenerator: respect the user's startingDirectory (#15035)

f06cd17

The PowerShell equivalent was added in the initial pull request, #7774. Closes #13721

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add profile generators for Visual Studio #7774

Add profile generators for Visual Studio #7774

trippwill commented Sep 29, 2020 •

edited by DHowett

Loading

github-actions bot commented Sep 29, 2020

zadjii-msft commented Sep 29, 2020

WSLUser commented Sep 29, 2020

zadjii-msft commented Sep 29, 2020

WSLUser commented Sep 29, 2020

trippwill commented Sep 29, 2020

WSLUser commented Sep 29, 2020 •

edited

Loading

zadjii-msft commented Sep 29, 2020

trippwill commented Sep 29, 2020

trippwill commented Sep 30, 2020

zadjii-msft commented Sep 30, 2020

github-actions bot commented Sep 30, 2020

trippwill commented Sep 30, 2020

This comment has been minimized.

This comment has been minimized.

trippwill commented Oct 1, 2020

zadjii-msft commented Oct 1, 2020

github-actions bot commented Oct 1, 2020

PankajBhojwani commented Oct 1, 2020 •

edited

Loading

ghost commented Sep 13, 2021

lhecker left a comment •

edited

Loading

DHowett commented Sep 13, 2021

DHowett left a comment

DHowett Sep 13, 2021

DHowett Sep 13, 2021

DHowett Sep 13, 2021

ghost commented Sep 15, 2021

DHowett commented Sep 15, 2021

kasper93 commented Sep 22, 2021

lhecker commented Sep 22, 2021

miniksa commented Sep 22, 2021

DHowett commented Sep 22, 2021

ghost commented Oct 20, 2021

Add profile generators for Visual Studio #7774

Add profile generators for Visual Studio #7774

Conversation

trippwill commented Sep 29, 2020 • edited by DHowett Loading

Validation Steps Performed

github-actions bot commented Sep 29, 2020

New misspellings found, please review:

⚠️ Reviewers

zadjii-msft commented Sep 29, 2020

WSLUser commented Sep 29, 2020

zadjii-msft commented Sep 29, 2020

WSLUser commented Sep 29, 2020

trippwill commented Sep 29, 2020

WSLUser commented Sep 29, 2020 • edited Loading

zadjii-msft commented Sep 29, 2020

trippwill commented Sep 29, 2020

trippwill commented Sep 30, 2020

zadjii-msft commented Sep 30, 2020

github-actions bot commented Sep 30, 2020

New misspellings found, please review:

⚠️ Reviewers

trippwill commented Sep 30, 2020

This comment has been minimized.

This comment has been minimized.

trippwill commented Oct 1, 2020

zadjii-msft commented Oct 1, 2020

github-actions bot commented Oct 1, 2020

New misspellings found, please review:

⚠️ Reviewers

PankajBhojwani commented Oct 1, 2020 • edited Loading

ghost commented Sep 13, 2021

lhecker left a comment • edited Loading

Choose a reason for hiding this comment

DHowett commented Sep 13, 2021

DHowett left a comment

Choose a reason for hiding this comment

DHowett Sep 13, 2021

Choose a reason for hiding this comment

DHowett Sep 13, 2021

Choose a reason for hiding this comment

DHowett Sep 13, 2021

Choose a reason for hiding this comment

ghost commented Sep 15, 2021

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

DHowett commented Sep 15, 2021

kasper93 commented Sep 22, 2021

lhecker commented Sep 22, 2021

miniksa commented Sep 22, 2021

DHowett commented Sep 22, 2021

ghost commented Oct 20, 2021

trippwill commented Sep 29, 2020 •

edited by DHowett

Loading

WSLUser commented Sep 29, 2020 •

edited

Loading

PankajBhojwani commented Oct 1, 2020 •

edited

Loading

lhecker left a comment •

edited

Loading

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.