Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Common Task for Creating and Modifying URIs (BuildUri) #8613

Open
jrdodds opened this issue Mar 29, 2023 · 1 comment
Open

Comments

@jrdodds
Copy link
Contributor

jrdodds commented Mar 29, 2023

Summary

A common task that can create and modify collections of URIs.

This issue is replacing the "Proposed 'BuildUri' Common Task" discussion.

A PR will be added to this issue with a proposed implementation. [Update: PR is #8614]

Background and Motivation

There is an existing FormatUrl task that can accept and output a string. FormatUrl is a specialized task that was written for a specific use case. It canonicalizes a URL and will replace 'localhost' with the current machine name. Replacing 'localhost' can easily be counter-productive for many scenarios including creating a test configuration that is meant to be distributed to multiple hosts and run locally.

FormatUrl doesn't support general construction and modification of URIs and there isn't other support currently provided in MSBuild.

A project that needs to generate or manipulate a URI may use string functions, a custom task, or an external script or tool. All three of these approaches can be flawed if the code used doesn't correctly understand URIs.

Proposed Feature

The BuildUri task wraps the UriBuilder class and operates on Item collections. Providing useful access to the UriBuilder class is new1. Providing for Item collections makes the task very flexible.

BuildUri has an optional input parameter for an ItemGroup of URIs (InputUri), a set of optional input parameters that map to the properties of UriBuilder, and an output parameter for an ItemGroup of URIs (OutputUri).

For an empty set of InputUri, the other input parameters are used to create a new URI.

For a set of 1 or more InputUri, the other input parameters are applied to each member of the set, e.g. a set of http URIs can be changed to used https.

For the OutputUri, each item is set with custom metadata that reflects the properties of the UriBuilder class. A set of URIs could be passed through the BuildUri task to add the metadata and the results could then be task or target batched by the added metadata, e.g. the collection could be batched by UriScheme.

Creating a URI might look like the following:

    <BuildUri UriScheme="https" UriHost="example.com" UriPath="test">
      <Output TaskParameter="OutputUri" PropertyName="ExampleUri" />
    </BuildUri>

Creating URIs for a set of hosts might look like the following:

    <ItemGroup>
      <template Include="http://example.com/" />
      <template Include="http://example.com/api" />
      <template Include="http://example.com/config" />
      <host Include="dev01-01;dev01-02;dev02-01;dev02-02" />
    </ItemGroup>
    <BuildUri InputUri="@(template)" UriScheme="https" UriHost="%(host.Identity)">
      <Output TaskParameter="OutputUri" ItemName="node" />
    </BuildUri>

Alternative Designs

No response

Footnotes

  1. System.UriBuilder is a supported type for static property functions but doesn't have any public static members.

@Forgind Forgind added the needs-triage Have yet to determine what bucket this goes in. label Apr 3, 2023
@AR-May
Copy link
Member

AR-May commented Apr 4, 2023

Team triage: Let's keep this issue open and see if there is community interest in it.

@AR-May AR-May added backlog and removed needs-triage Have yet to determine what bucket this goes in. labels Apr 4, 2023
Forgind pushed a commit that referenced this issue May 1, 2023
Context
Minor code cleanup in Microsoft.Common.tasks.

Changes Made
Removed duplicate UsingTask for the ResolveSDKReference task. The redundant ResolveSDKReference doesn't seem to create harm but is not useful.

Alphabetized the UsingTask elements. Retained the separate grouping of Roslyn tasks. Retained the blank lines around tasks that have different Runtimes and/or Conditions (i.e. GenerateResource, RegisterAssembly, and UnregisterAssembly). Ordering the UsingTask elements is intended to aid inspection and maintenance of tasks.

Testing
Tested on Windows 11 and macOS 12. Tested by running unit tests and by having this change in several development branches where msbuild has been run on project files.

Notes
This change is included in the implementation for #8613, which is PR #8614.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants