CloudBlazor

CloudBlazor is the foundation of the Angry Monkey Cloud Blazor ecosystem, providing reusable UI, browser behaviors, website infrastructure, Blazor WebAssembly application features, and .NET MAUI Blazor Hybrid integrations.

Overview

Four NuGet packages, each depending only on the one above it, so an application takes exactly what it needs:

AngryMonkey.CloudBlazor
├── AngryMonkey.CloudBlazor.Web
└── AngryMonkey.CloudBlazor.App
    └── AngryMonkey.CloudBlazor.App.Maui

Packages

Package	Latest Version	Downloads	Depends On	Purpose
AngryMonkey.CloudBlazor			—	Core Razor Class Library containing reusable components, browser behaviors, JavaScript initializers, and shared Blazor functionality.
AngryMonkey.CloudBlazor.Web			CloudBlazor	Server-side website package focused on HTML structure, layouts, SEO, metadata, routing, and website infrastructure.
AngryMonkey.CloudBlazor.App			CloudBlazor	Client-side framework for Blazor WebAssembly applications, including reusable application services and application-level UI.
AngryMonkey.CloudBlazor.App.Maui			CloudBlazor.App	Native .NET MAUI and Blazor Hybrid integrations built on CloudBlazor.App.

Installation

Website (Blazor Web App / SSR)

dotnet add package AngryMonkey.CloudBlazor.Web

Blazor WebAssembly

dotnet add package AngryMonkey.CloudBlazor.App

.NET MAUI Blazor Hybrid

dotnet add package AngryMonkey.CloudBlazor.App.Maui

Component Library

dotnet add package AngryMonkey.CloudBlazor

Migrating from the previous packages

CloudBlazor merges the former CloudWeb and CloudApp repositories. Their packages are no longer updated; each has a direct replacement.

Namespaces move with the package identity:

Type and method names are unchanged. Per-package migration notes, including the behaviour changes that came with the merge, are in each package readme: CloudBlazor.Web · CloudBlazor.App · CloudBlazor.App.Maui

Because all four are new package identities shipping as a matched set, versioning restarts at 1.0.0. The version histories of the previous packages do not carry over.

Package Responsibilities

AngryMonkey.CloudBlazor

• Reusable Razor components
• Browser behaviors
• JavaScript initializers
• Shared utilities
• Foundation for all packages

AngryMonkey.CloudBlazor.Web

• HTML document generation
• Layout infrastructure
• Page metadata, canonical URLs and hreflang alternates
• Open Graph, Twitter cards and JSON-LD structured data
• sitemap.xml and robots.txt endpoints
• Robots directives and crawler detection
• Asset bundles with cache-busting
• Server-side website features

AngryMonkey.CloudBlazor.App

• Blazor WebAssembly application shell
• Client-side services
• Authentication helpers
• Navigation services
• Shared application components
• Application framework

AngryMonkey.CloudBlazor.App.Maui

• Android
• iOS
• macOS / Mac Catalyst
• Windows
• Blazor Hybrid integrations

Supported Platforms

Repository Structure

CloudBlazor/
├── CloudBlazor/              # AngryMonkey.CloudBlazor
├── CloudBlazor.Web/          # AngryMonkey.CloudBlazor.Web
├── CloudBlazor.App/          # AngryMonkey.CloudBlazor.App
├── CloudBlazor.App.Maui/     # AngryMonkey.CloudBlazor.App.Maui
├── CloudBlazor.Demo/         # Unified demo covering every package
├── CloudBlazor.Tests/        # xUnit test project
├── CloudBlazor.Package/      # CloudMate packaging entry point
├── Directory.Build.props     # Shared build configuration
├── Directory.Build.targets   # Shared packaging configuration
└── README.md

Initialization

CloudBlazor's browser behaviors start in one of two ways, and which applies depends only on whether the host loads a Blazor script.

• Blazor hosts — nothing to configure. The runtime discovers the package's JS initializer from its static web assets. This works through a chain of references too: an application that references only CloudBlazor.Web or CloudBlazor.App still receives it, because both are Razor Class Libraries that forward CloudBlazor's static web assets.
• Hosts without a Blazor script (MVC, Razor Pages, static pages with no Blazor runtime) have no initializer pipeline at all. Render <CloudBlazorScript />, or let CloudBlazor.Web emit it as part of the managed head — which it does by default.

Both paths are guarded, so running both is safe. CloudBlazor.Tests asserts the whole asset chain, including the {PackageId}.lib.module.js naming rule the SDK depends on, because nothing fails at build time when it drifts.

Adding a reference and seeing no behaviors usually means a stale incremental build. Static web assets are resolved during the build; rebuild rather than build.

Design Guidelines

• Generic Razor components → CloudBlazor
• Browser behaviors → CloudBlazor
• HTML, SEO, layouts and website infrastructure → CloudBlazor.Web
• Blazor WebAssembly application features → CloudBlazor.App
• Native MAUI functionality → CloudBlazor.App.Maui

Static assets follow the shared Angry Monkey convention: author .less under src/, and let CloudMate compile it into wwwroot. Never edit a generated .css file.

Development

git clone https://github.com/angrymonkeycloud/CloudBlazor.git
cd CloudBlazor
dotnet restore
dotnet build

Run the tests:

dotnet test CloudBlazor.Tests/CloudBlazor.Tests.csproj

Run the demo:

dotnet run --project CloudBlazor.Demo/CloudBlazor.Demo.csproj

The demo is one Blazor Web App covering all three web-capable packages: CloudBlazor's browser behaviors, CloudBlazor.Web's metadata, canonical and social tags, sitemap and robots.txt, bundles, robots directives and crawler detection, and CloudBlazor.App's navigation service — each on its own page with live state. It serves a real /sitemap.xml and /robots.txt.

Continuous integration

.github/workflows/tests.yml runs on every push and pull request to main:

• Build and test — restores, builds the solution in Release, and runs the test suite with coverage collection.
• Validate packages — packs all four libraries and checks each one carries its readme and icon and stays inside a size budget. Both are regressions this repository has actually shipped before: every library once failed dotnet pack outright, and CloudBlazor.Web once shipped 23 MB of unrelated content files.

Releasing

CloudBlazor.Package is the single packaging entry point. It uses AngryMonkey.CloudMate's CloudPack to version, build, pack and publish all four packages in one run, in dependency order.

1. Bump <Version> in CloudBlazor.Package/CloudBlazor.Package.csproj. CloudPack propagates it, along with the shared metadata, into every library — so the individual project files are not edited by hand.
2. Store the NuGet API key in user secrets:

dotnet user-secrets --project CloudBlazor.Package set "NuGetApiKey" "<your-key>"

3. Run it. CloudPack shows the target version and each package's currently published version for confirmation before anything is changed:

dotnet run --project CloudBlazor.Package/CloudBlazor.Package.csproj

Packages are also written to NugetPackages/.

License

MIT License © Angry Monkey Cloud

Angry Monkey Cloud

This project follows the shared AI development instructions.

Theme integration

CloudBlazor hosting remains independent of theme models. Its demo uses CloudThemeDocument from CloudCommon.Theming.Blazor; the existing mode switch also updates data-amc-theme. See the common theme contract.