MSDeploy task: source-only verbs are not available (dump, getXxxx)

[nonbob]

Functional impact

No major functional impact in my case
It's easy for me to work around

Minimal repro steps

1. Create a Visual Studio project that uses the VSMSDeploy task (an ASP.NET Core Angular site, in our case)
2. At the end of the .csproj file, just before the closing Project tag, add a target that gets run after CorePublish (e.g. Target Name="DoAfterPublish" AfterTargets="CorePublish")
3. Inside the target add an ItemGroup to define a dummy source, say, MsDeployDummyProviderSetting - it doesn't have to be fully-specified source, because the code only gets as far as checking to see if it exists
4. Also inside the target, add an MSDeploy task with verb="getSystemInfo" Source="@(MsDeployDummyProviderSetting)"
5. Near the top of the project file add <UsingTask TaskName="MSDeploy" AssemblyFile="$(_PublishTaskAssemblyFullPath)"/>
6. Unload and reload the project
7. Try a non-Azure publish using web deploy

Expected result

I'd expect msdeploy to execute the source-only verb
which is being executed only for side effects, in my case.

Actual result

Invalid verb(getSystemInfo) for supplied source (contentPath) and destination ()

Further technical details

possibly due to a missing else at line 1088 of MSDeploy.cs
It looks like the validVerbs list for the no-destination case is always overwritten by the validVerbs list for the with-destination case.

miniFAQ:

1. Is there any good reason I'm doing this? No. The bad reasons relate to snowflake servers, limited resources, and resistance to containerization
2. If you know the exact line where 5 characters need to be added, why don't you just do a PR? Not a horrible idea. I'll check with my boss first. I don't think anybody from this division has ever done a PR. It may or may not be frowned upon.
3. How hard was this to figure out? No too hard, really. The hard part, for me, was realizing that the msbuild extension mechanism I'd used for more than a decade no longer worked (although I heartily agree that the replacement is better). It would be nice, as mentioned elsewhere, if the comments at the BeforeXxxxx and AfterXxxxxx extension targets were updated to reflect the new reality.
4. Is there are cleaner way to do what I was trying to do? Having msdeploy.exe's XML available as an MSDeploy task output (when -xml is specified) would be a nicer, cleaner approach. But see question 1 as to why I'm in this situation.

[vijayrkn]

Thank you for reporting this issue. I will take a look.