Resolve WebApplicationsTargetPath to licensed version of VisualStudio build files.

[CZEMacLeod]

Issue

Currently WebApplicationsTargetPath depends on a locally installed version of visual studio - either buildtools or any full version such as community or professional with the appropriate workload installed.

Using tools such as dotnet build or dotnet test are more difficult as they require either resolving the location of VS using VSWhere or passing in an empty targets file.

Solutions

1. Set the default action that if there is no resolved targets file available that a warning is emitted but no failure occurs.
2. Add a mechanism to resolve the file (assuming VS is installed) without external scripts/actions or setting env variables etc.
3. Include the required tasks and targets directly in the SDK.
4. Use a packaged version of the required tasks and targets.

Either of 3 or 4 is preferred as this makes the solution robust and maintainable. It also obviates the need for additional installations.
The best solution would be for Microsoft to release an official package, probably versioned to match VisualStudio in case there are any updates. This would be the lowest impact.

Concerns

The preferred solutions (3 or 4) require that the appropriate files are released in a form separate from VisualStudio and are licensed appropriately.
If we include them directly in the SDK then we have to maintain them here and ensure they are current etc.
If MS release them themselves, then we simply have to ensure that the appropriate overrides for versions are available, and occasionally bump the defaults if any issues arise.

Unfortunately, while this has been raised a few times with MS employees in the past (@twsouthwick) - this is a low priority and has never gone any further.
In the mean time, there are unofficial packages on Nuget that are out of date and may, or may not, contain the official binaries.
I do not endorse the use of these packages, but for reference:

• MSBuild.Microsoft.VisualStudio.Web.targets V14 / Visual Studio 2015
• MSBuild.Microsoft.VisualStudio.Web_WebApplication.Targets V12 / Visual Studio 2013 Update 2
• MSBuild.Microsoft.VisualStudio2005.Web.targets V8 / Visual Studio 2005 Service Pack 1

There may be others out there.

Assuming the existence of a theoretical package Microsoft.VisualStudio.Web.Application.Tasks, we could add the following into the default packages:

    <PackageReference Include="Microsoft.VisualStudio.Web.Application.Tasks" PrivateAssets="All" GeneratePathProperty="true" />

and then update the resolution to try and resolve it using a relative path there.

  <PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">15.0</VisualStudioVersion>
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
    <WebApplicationsTargetPath Condition=" '$(WebApplicationsTargetPath)' == '' and '$(PkgMicrosoft_VisualStudio_Web.Application_Tasks)'!=''">$(PkgMicrosoft_VisualStudio_Web.Application_Tasks)\build\WebApplications\Microsoft.WebApplication.targets</WebApplicationsTargetPath>
    <WebApplicationsTargetPath Condition=" '$(WebApplicationsTargetPath)' == ''">$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets</WebApplicationsTargetPath>
  </PropertyGroup>

Alternatives

Some projects - such as openiddict/openiddict-samples have embedded the files directly in the git repo under their build infrastructure openiddict/openiddict-samples#325 but this is subject both to issues around licensing and keeping them up to date.