How to Base64UrlEncode in Blazor WebAssembly client now that Microsoft.AspNetCore.WebUtilities has been deprecated?

[Bellarmine-Head]

I just spotted that NuGet in Visual Studio is saying that package Microsoft.AspNetCore.WebUtilities at 2.2.0 is deprecated.

I have this package installed into my Blazor WebAssembly Client project because I need to call method WebEncoders.Base64UrlEncode.

If I should remove Microsoft.AspNetCore.WebUtilities, how should my Client project perform base64 URL encoding?

(I note that my Server project is still able to call WebEncoders methods, and doesn't have the deprecated package installed anyway.)

This resource says that WebEncoders.Base64UrlEncode lives in package Microsoft.AspNetCore.App.Ref but NuGet tells me that I shouldn't install that package as it's an internal thing.

[mkArtakMSFT]

@wtgodbe what would it take to publish this as a package? It's part of our API set in main, so we do still have the API, it has just moved to Shared Framework some time ago, and we stopped publishing a package.

[wtgodbe]

It's intentional that we removed the package and added it to the Shared Framework - @Bellarmine-Head what TargetFramework is your project using? If it's anything newer than 2.2, then you just need to have asp.net installed on your machine & you'll get Microsoft.AspNetCore.WebUtilities for free without needing the PackageReference.

[mkArtakMSFT]

@wtgodbe this is Blazor WebAssembly scenario, so they don't have access to Shared Framework.

[wtgodbe]

I see - are we not going have this need for other such packages needed in the Blazor Wasm scenario? Do we think lots of people were still using those 2.2 era packages for this purpose?

If we do need to ship this package again, we just need to flip this bit, but I want to make sure we understand the scenario fully first:

aspnetcore/src/Http/WebUtilities/src/Microsoft.AspNetCore.WebUtilities.csproj

Line 11 in 2860263

<IsPackable>false</IsPackable>

[Bellarmine-Head]

@wtgodbe

then you just need to have asp.net installed on your machine & you'll get Microsoft.AspNetCore.WebUtilities for free without needing the PackageReference

Sure. This is the deal with my Server project in my Blazor WebAssembly solution, but as @mkArtakMSFT has pointed out, the Client project doesn't access the shared framework.

@mkArtakMSFT

It's part of our API set in main, so we do still have the API, it has just moved to Shared Framework some time ago, and we stopped publishing a package.

This suggests that this and other packages were deprecated without sufficient consideration being given to the needs of Blazor WebAssembly client projects.

Thanks for getting the ball rolling on a possible remedy.

[Bellarmine-Head]

@wtgodbe

what TargetFramework is your project using?

net7.0

are we not going have this need for other such packages needed in the Blazor Wasm scenario

This seems likely, especially for packages that are mainly collections of useful utility functions like Base64UrlEncode.

OTOH, maybe Microsoft.AspNetCore.WebUtilities is the only one...?

[Bellarmine-Head]

@wtgodbe

Maybe an explicit Blazor WebAssembly Client Utilities package could be put together - culled from the original Microsoft.AspNetCore.WebUtilities (and maybe a few other likely, deprecated packages that have useful utility functions)...?

This would encourage devs to add the package to the Client project, and discourage them from adding it to the Server project.

[Bellarmine-Head]

... or, include the utility methods in a near-term future version of https://www.nuget.org/packages/Microsoft.AspNetCore.Components.WebAssembly (for .NET 6 and .NET 7 and later). This package gets included in every Blazor WebAssembly Client project.

[Peymanpn]

In my opinion, keeping this package separate would help, at least in my case.

I just wanted a few methods, in this case, Base64UrlEncode, and I really don't want to install all of it just because of these few ones.

Thanks