Updated MongoDB.Driver version from 3.8.1 to 3.9.0 and removed pinned versions for SharpCompress and Snappier.

Co-authored-by: Benjamin Krämer <[email protected]>

… codegen binding (#18160)

Polyglot (TypeScript/Python/Java/Go/Rust) AppHost code generation silently fails
("No code generator found for language: ...") when the installed CLI and the
AppHost's SDK skew in version. The CLI's bundled apphost server force-shares
Aspire.TypeSystem from its default ALC, but the SDK-side codegen assemblies carry a
strong-named reference to a different Aspire.TypeSystem version. The CLR only
satisfies a strong-named reference when the loaded copy's AssemblyVersion is >= the
requested version, so a floating per-build AssemblyVersion makes the bind fail,
Assembly.GetTypes() throws ReflectionTypeLoadException, and every generator is
dropped.

Freeze the strong-name AssemblyVersion at the fixed constant 13.4.5.0, decoupled from
the build and carried forward to all later releases so every later stable and servicing
release bundles the same value. 13.4.5.0 is chosen because it matches the AssemblyVersion
of the latest already-shipped stable (13.4.5, whose AssemblyVersion floated to 13.4.5.0),
so the already-released 13.4.5 CLI and every post-freeze CLI/SDK carry the identical
constant and never skew. Only AssemblyVersion is frozen;
FileVersion/InformationalVersion/PackageVersion stay build-derived so diagnostics keep
real identities. Document the now-intentional shared-from-bundle binding in
IntegrationLoadContext and the version-ordered warning in AssemblyLoader.

Binary-incompatible changes to the shared contract are caught by the repository's
standard public API compatibility tracking (the checked-in api/Aspire.TypeSystem.cs
reference surface and package baseline validation), which forces a deliberate
AssemblyVersion bump instead of silently reintroducing the binding failure.

Co-authored-by: Copilot <[email protected]>

…#18341)

* Add CLI E2E test for two isolated instances with distinct otel logs

* Fix port conflicts in --isolated mode by clearing fixed port env vars

When running multiple instances with --isolated, the AppHost's dashboard,
resource service, and OTLP endpoints all tried to bind to the same fixed
ports from the launch profile/user secrets. Fix by clearing port-bearing
env vars (ASPNETCORE_URLS, ASPIRE_RESOURCE_SERVICE_ENDPOINT_URL, and
ASPIRE_DASHBOARD_OTLP_*_ENDPOINT_URL) in ConfigureIsolatedModeAsync so
the AppHost falls back to OS-assigned random ports.

Also suppress the launch profile in the dotnet-run fallback path when
isolated, so the fixed ports from the profile don't leak through.

* Revert "Fix port conflicts in --isolated mode by clearing fixed port env vars"

This reverts commit 4dc855d.

* Use dynamic port for resource service endpoint when RandomizePorts is true

When DcpPublisher:RandomizePorts is enabled (e.g. --isolated mode), the
DashboardServiceHost now ignores the fixed port from
ASPIRE_RESOURCE_SERVICE_ENDPOINT_URL and binds to port 0 instead. This
allows multiple isolated instances of the same project to run concurrently
without port conflicts on the resource service endpoint.

* Shell-quote apphost parameter in AspireStartAsync/StopAsync

* Use DnsSafeHost for IPv6 parsing; use sentinel markers in E2E assertions

* Extract ResolveEndpoint helper for unit testability

---------

Co-authored-by: James Newton-King <[email protected]>