Skip to content

Build a query string: retarget net10.0, safe UriBuilder helper, CS8620 fix - #2170

Open
vladimir-pecanac-main wants to merge 1 commit into
CodeMazeBlog:mainfrom
vladimir-pecanac-main:seo/96416-query-string
Open

Build a query string: retarget net10.0, safe UriBuilder helper, CS8620 fix#2170
vladimir-pecanac-main wants to merge 1 commit into
CodeMazeBlog:mainfrom
vladimir-pecanac-main:seo/96416-query-string

Conversation

@vladimir-pecanac-main

Copy link
Copy Markdown
Collaborator

Updates the dotnet-querystrings/BuildQueryString sample for the republish of How to Build a Query String for a URL in C#.

Retarget

net7.0 -> net10.0 on all three projects (BuildQueryString, BuildQueryStringTests, BooksAPI). Package versions taken from the NuGet flat-container index on 2026-08-30, not from memory:

Package Was Now
Microsoft.Extensions.DependencyInjection 7.0.0 10.0.11
Microsoft.NET.Test.Sdk 17.5.0 18.9.0
MSTest.TestAdapter / MSTest.TestFramework 2.2.10 4.3.3
Moq 4.20.69 4.20.72
coverlet.collector 3.2.0 10.0.1
Swashbuckle.AspNetCore 6.2.3 10.2.3

The MSTest 2.x -> 4.x jump needed no source changes: the classic Assert.AreEqual / TestClass / TestMethod API compiles as-is and no MSTEST analyzer diagnostic fires in this folder.

Safe UriBuilder composition (new helper + test)

The article's central claim about UriBuilder was wrong: it escapes characters that are illegal anywhere in a URI, but it does not escape the query delimiters &, = and # inside a value. Assigning author=Tom & Jerry to Query yields ?author=Tom%20&%20Jerry, which a receiver parses as two parameters, the second named Jerry.

BuildUrlWithQueryStringUsingUriBuilderSafely is the one-line composition that does encode: build the query with QueryString.Create and hand the finished string to UriBuilder. The new test asserts the full round trip over Tom & Jerry and C#:

https://localhost:7220/api/Books?author=Tom%20%26%20Jerry&tag=C%23

parsed back to author = Tom & Jerry and tag = C#.

CS8620

BuildUrlWithQueryStringUsingAddQueryStringMethod and BuildUrlWithQueryStringUsingCreateMethod take Dictionary<string, string?>, and every caller declared Dictionary<string, string>, which warns:

warning CS8620: Argument of type 'Dictionary<string, string>' cannot be used for parameter 'queryParams'
of type 'Dictionary<string, string?>' ... due to differences in the nullability of reference types

Fixed at all four call sites (two in BooksApiService, two in QueryStringHelperUnitTests). The build is now warning-clean apart from NU1510 on the DI package, which the article tells the reader to install explicitly.

Idiom

BuildQueryString/Program.cs lifted to top-level statements. BooksAPI/Program.cs was read and already uses minimal WebApplication hosting with no Startup.cs, so it is untouched.

Build and tests

dotnet build BuildQueryString.sln -c Release   ->  Build succeeded, 0 errors
dotnet test  BuildQueryString.sln -c Release   ->  Passed! - Failed: 0, Passed: 14, Skipped: 0, Total: 14

13 pre-existing tests plus the one added. Every comparison-table cell in the article was re-produced by running the retargeted solution itself on .NET 10.0.10, not by reading reference pages.

…0 fix

- net7.0 -> net10.0 across BuildQueryString, BuildQueryStringTests and BooksAPI
- Package moves: Microsoft.Extensions.DependencyInjection 10.0.11, Microsoft.NET.Test.Sdk 18.9.0,
  MSTest.TestAdapter/TestFramework 4.3.3, Moq 4.20.72, coverlet.collector 10.0.1,
  Swashbuckle.AspNetCore 10.2.3
- Add BuildUrlWithQueryStringUsingUriBuilderSafely: UriBuilder composed with
  QueryString.Create, plus a round-trip test over 'Tom & Jerry' and 'C#'
- Fix CS8620: declare the caller dictionaries as Dictionary<string, string?> where the
  helper takes nullable values (BooksApiService and the matching tests)
- Program.cs: top-level statements
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant