We could simplify the sidebar menu by merging Project Logs and Container Logs pages under a "Console Logs" page. The dropdown on the page would have a selectable list of projects and containers merged together. Future executable logs feature would also use this page.

There should be an indication of whether the selected item is a project, container, or executable.

When you create a new Aspire project using either the empty or starter template, the projects are created in a nested directory named for the solution under the solution directory:

Here is a snippet from eShop. We could make this scenario clearner with a DataProtection component for Redis

public static void AddApplicationServices(this IServiceCollection services, IConfiguration configuration)
{
    services.Configure<AppSettings>(configuration);

    if (configuration["DPConnectionString"] is string redisConnection)
    {
        var builder = services.AddDataProtection(opts =>
        {
            opts.ApplicationDiscriminator = "eshop.webmvc";
        });

        services.AddOptions<KeyManagementOptions>().Configure((KeyManagementOptions options, IConnectionMultiplexer connectionMultiplexer) =>
        {
            options.XmlRepository = new RedisXmlRepository(() => connectionMultiplexer.GetDatabase(), "DataProtection-Keys");
        });
    }
}

for voluminous logs intended for devs to read, fixed width font is easier to scan quickly and spot anomalies. also if it's a console log, it may be necessary to make stuff line up visually.

I also suggest to remove padding between lines too -- so it's as compact as a typical terminal window.

I want to be able to use the redis image, but run the redis-cli in that container e.g.:

builder.AddContainer("redis-cli", "redis")
    .WithArgs("redis-cli -h redis MONITOR");

@karolz-ms Does DCP support this?

Aspire components currently throw exceptions inline when they're missing expected configuration values (inline with the IHostApplicationBuilder.AddAspireComponentName() method being called). This results in the app immediately crashing and the .NET runtime host printing the exception and stack to the console output and exiting with an error code.

While this is fairly useful and easy to rectify locally, after an application has been deployed to a remote environment (e.g. Azure Container Apps) it can be much harder to observe this message, as the container provisioning will be marked as "failed" and thus shutdown, because its readiness/liveness probe never succeeds. If the container isn't running, you can't remote into it to see its streaming logs.

We should consider changing this pattern so that instead of immediately throwing, the component logs an error via ILoggerFactory, adds a health check fixed in the "Unhealthy" state, doesn't continue performing any other setup (adding services to DI, configuring tracing/metrics, etc.) and allows the app to continue starting. This way, viewing the app logs via remote console streaming will be possible (where the error message will be visible), and the app will report itself as unhealthy until the configuration is fixed and the app restarted.

@eerhardt @davidfowl

If still have time

When creating a new Aspire project using either the aspire or aspire-starter templates using the dotnet CLI, no .sln file is created.

A change caused tests to stop running, and when enabling back on, tests in Aspire.Hosting.Tests are now broken and have been disabled. This issue is tracking the work of re-enabling them.

Test Aspire.Hosting.Tests.DistributedApplicationTests.TestProjectStartsAndStopsCleanly is broken. Console error is:

[xUnit.net 00:01:02.77]     Aspire.Hosting.Tests.DistributedApplicationTests.TestProjectStartsAndStopsCleanly [FAIL]
  Failed Aspire.Hosting.Tests.DistributedApplicationTests.TestProjectStartsAndStopsCleanly [1 m]
  Error Message:
   System.Threading.Tasks.TaskCanceledException : A task was canceled.
  Stack Trace:
     at Aspire.Hosting.Tests.Helpers.AllocatedEndpointAnnotationTestExtensions.HttpGetPidAsync(IDistributedApplicationComponentBuilder`1 builder, String bindingName, CancellationToken cancellationToken) in C:\Users\joperezr\git\astra\tests\Aspire.Hosting.Tests\Helpers\AllocatedEndpointAnnotationTestExtensions.cs:line 34
   at Aspire.Hosting.Tests.DistributedApplicationTests.TestProjectStartsAndStopsCleanly() in C:\Users\joperezr\git\astra\tests\Aspire.Hosting.Tests\DistributedApplicationTests.cs:line 113
   at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_0(Object state)

Test Aspire.Hosting.Tests.DistributedApplicationTests.TestServicesWithMultipleReplicas is broken. Console error is:

[xUnit.net 00:02:02.79]     Aspire.Hosting.Tests.DistributedApplicationTests.TestServicesWithMultipleReplicas [FAIL]
  Failed Aspire.Hosting.Tests.DistributedApplicationTests.TestServicesWithMultipleReplicas [1 m]
  Error Message:
   System.Threading.Tasks.TaskCanceledException : A task was canceled.
  Stack Trace:
     at Aspire.Hosting.Tests.Helpers.AllocatedEndpointAnnotationTestExtensions.HttpGetPidAsync(IDistributedApplicationComponentBuilder`1 builder, String bindingName, CancellationToken cancellationToken) in C:\Users\joperezr\git\astra\tests\Aspire.Hosting.Tests\Helpers\AllocatedEndpointAnnotationTestExtensions.cs:line 34
   at Aspire.Hosting.Tests.DistributedApplicationTests.TestServicesWithMultipleReplicas() in C:\Users\joperezr\git\astra\tests\Aspire.Hosting.Tests\DistributedApplicationTests.cs:line 137
   at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_0(Object state)

Astra already depends on large set of packages (internal and external) and none of them are auto-updated: https://github.com/dotnet/astra/blob/main/eng/Versions.props.

Dependabot would be suitable to update the dependencies. Some of our partner repositories already do that: https://github.com/dotnet/msbuild/blob/main/eng/dependabot/dependabot.csproj

As none of the Astra dependencies are managed by Darc/Maestro, moving the versions from Versions.props into Directory.Packages.props could be sufficient.

cc @mitchdenny

When component packages provide JSON schema, they should ensure they're providing a meaningful description for every node in the configuration schema, so that a good UX is provided to users in the JSON editor. For example, if all Aspire contribute schema under a root "Aspire" node, e.g. "Aspire": { "Caching": { "Redis": ..., they should all be defining the "Aspire" node with the same description. The tooling will simply take the last description it found for a node based on all the schema parts contributed by packages, so ensuring they're all aligned will provide a consistent UX.

INSTALL STEPS

1. Clean machine: Win11 x64 23H2 ENU [zn_release-enterprise_en-us_vl]
2. Install VS 17.8 Preview 3 (build main-34115.278 S, buildId = 8405535 from this Sunday night)
   • Web workload
   • Includes SDK 8.0 RC1 (build 8.0.100-rc.1.23455.8)
   • Unchecked 6.0/7.0 runtime
3. Install SDK 8.0 RC2
   • Build 8.0.100-rc.2.23466.1, installed from dotnet/installer repo
4. Apply feeds
   • https://pkgs.dev.azure.com/dnceng/internal/_packaging/dotnet-tools-internal/nuget/v3/index.json
   • https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet8/nuget/v3/index.json
5. Download and Install DCP
   • Installed from Download the orchestrator from here
6. Open Developer Command Prompt, set VsEnableAspireOrchestrationParameter=1 and run devenv to start VS

REPRO STEPS

1. New project > 8.0 Empty project > 'EmptyWebApp1' > check the Enlist in Aspire Orchestration checkbox > Create
2. Add Aspire component > Aspire.Azure.Security.KeyVault
3. In appSettings.json, add the connection string
4. In Program.cs, try to do this

string? _mySecret = builder.Configuration["myAppSetting"];

ACTUAL
This is not supported yet. We need to do something more verbose, like this:

string? _mySecret = app.Services.GetRequiredService<SecretClient>().GetSecret("myAppSetting").Value.Value;

EXPECTED
We should be able to read myAppSetting through the Configuration API

The Aspire NuGet packages should all share a common icon. The Aspire templates in VS show up with an icon (see below) but I'm not sure where that's coming from. We could use that for now and kickoff a task to get an actual icon figured out for shipping. We could also decide to just use the existing .NET icon.

Enable StyleCop analyzers on the repo and configure .editorconfig.

The Aspire.Hosting OTLP endpoint injection logic should be updated to handle the following:

• Assign a random, unused port each time, rather than a hard-coded port. A port in consistent range outside the typical ranges used for new app projects, e.g. 18900-18999, should be considered.
• Configure the OTLP endpoint to use HTTPS when the dashboard itself is listening on HTTPS. That way, when the user selects HTTPS as the launch profile, all communications in the Aspire app are HTTPS.
• Remove the environment variable definition for DOTNET_DASHBOARD_OTLP_ENDPOINT_URL in the Aspire templates launchSettings.json files, as they shouldn't be required after these changes.

See https://github.com/dotnet/astra/pull/587#discussion_r1336169357 for original context.

Creating a new Aspire app using the starter template results in overview pages being opened for both the ApiService and Web projects. We should likely have an Aspire specific page instead.

They seem to be missing

This is not urgent, but is something to consider in the future for scaling as we'll want to parallelize test runs, particularly as we continue to develop more components.

We want to disambiguate between "aspire components" that are consumed by services and resources declared a part of the application model.

We should expose a way to express dependencies between resources. This won't have any immediate impact on startup order but will come in handy for other things (diagrams and the manifest).

Original

Do we need to implement depends on like relationships between components. Right now, we've just added AddExecutable(...) to support things like running arbitrary executables as part of bringing up the dev host. But it has been pointed out that for things like migrations we might want to hold starting a project until the executable finishes running (kind of like an init container).

For other dependencies (between projects) we might want to express startup dependencies, but because they are long running we would probably need to introduce the concept of health probes.

Need to make sure that all aspects of dashboard pass a11y requirements. Likely Fluent UI lib handles a lot of this but let's make sure we don't wait until last minute

• Run web a11y checker for report
• Use aria-* labels on non-standard controls or where we use images as buttons, etc. (make sure nav menu is appropriate, etc.)
• Any real-time updates announcing changes, etc.
• Use title/labels on actions

We will be using the $schema attribute to specify the version of the manifest format we are using. That means we need a JSON schema which documents the format. We also need to think about where we host it.

When a component is added to a project, we add appsettings.json intellisense for its configuration.

We should also add entries for its logging categories:

When I add the Redis component, I should get intellisense for "Aspire.StackExchange.Redis".

The templates currently have no unit test coverage. We should look at porting some of the template testing infrastructure from dotnet/aspnetcore to enable us to get some template test coverage.

Named endpoints design is ongoing, but one suggestion is to stash the name in the URL. Unfortunately, that makes the URL specified in user's apps rather ugly:

app.AddHttpClient<CatalogServiceClient>(c => c.BaseAddress = new("http://_http1.catalogservice"));
app.AddHttpClient<Greeter.GreetClient>(c => c.Address = new("http://_http2.catalogservice"));

A potential improvement is to add extension methods for HttpClientFactory and GrpcClientFactory that accepts address/name. The new methods would internally call AddHttpClient/AddGrpcClient and builds the ugly URL for the user:

app.AddHttpClient<CatalogServiceClient>(new("http://catalogservice"), name: "http1");
app.AddGrpcClient<Greeter.GreetClient>(new("http://catalogservice"), name: "http2");

As per https://github.com/dotnet/astra/pull/587#discussion_r1335954070

We need to figure out if we're going to have a standalone third-party notices link/file for Aspire and link to that, or if we'll just update the existing ASP.NET Core third-party notices link and use that.https://aka.ms/aspnetcore/8.0-third-party-notices

Right now all packages have "Package description" showing in the NuGet feed UI:

These should have helpful 1 to 2 line descriptions (as trunctation may occur) to be helpful and guide better than the Package ID is providing.

If you leave out line 11 in this screenshot then when the app tries to use the typed client you don't get any error, but it seems like we should be able to detect that case and throw something more meaningful. At least something about not having any service resolvers registered. Today with the blazor app demo we've been doing you end up in a weird state that gives you no feedback about why it isn't working.

This change to make the EF.PostgreSQL component enable the EF developer exception page filter makes the component depend on the ASP.NET Core shared framework (Microsoft.AspNetCore.App). This in turn makes any project that uses the EF.PostgreSQL component depend on the ASP.NET Core shared framework too. This is because the package Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore that was added as a dependency of EF.PostgreSQL is intended only for use in ASP.NET Core projects as it contains not only the developer exception page filter but also the supporting middleware required to make that filter function fully (incidentally that middleware has to be registered separately in the app to add the endpoints via the IApplicationBuilder.UseMigrationsEndPoint() method).

While I definitely like the idea of the EF components enabling the EF developer exception page filter, I'm not sure the layering issues enable that right now.

@adamsitnik @eerhardt

A CLI user can dotnet publish an Astra orchestration project to have all the configured service projects published in an appropriate directory layout, ready for deployment.

Redis component to use when using Azure hosted Redis.

1. database
2. output cache
3. distributed cache

https://github.com/dotnet/arcade/blob/9a7b1d30fd536da1b71d74b184e857ee96c12a76/Documentation/OneLocBuild.md?plain=1#L14

Right now we have tests that only run when DCP is installed. We can verify the output model outside of running the application as well

We come up with some wording in the Component READMEs to inform the user that they can get a Redis server at dev time via var cache = builder.AddRedis("cache");?

Originally posted by @DamianEdwards in https://github.com/dotnet/astra/pull/496#discussion_r1327992806

This currently applies for the Redis components and Npgsql Postgres databases.

Recent update to environments now emits all user (it appears) level environment variables for the machine:

I'm not sure why we have that and what was missing prior that this now solves for the customer in the local dev/dashboard experience. 'Just because' I don't think is good enough to add more potential confusing UX

This now has some unexpected user experience effects:

• The 'view' button for each row is essentially redundant as the button now launches a dialog that shows everything so each button is identical
• LOTS of noise. My first screen of env vars is nonsensical to Aspire or my job-to-be-done. Yes search is there, but your focus/context is lost now you have to know what to search for
• Potential threat model issues?
• Different than Containers env vars view

If we would keep this mode, we should (based on some chat discussions and opinion):

• Remove per-row options and just have one entry point
• AND/OR show the project-specific env vars that matter (prior experience) with a 'show all' mode to then show the complete list
• Groupings (put the 'all' list in a collapsed expando or something

/cc @leslierichardson95

Today the Aspire shared project that gets added to all Aspire solutions and auto-referenced by Aspire service projects depends on ASP.NET Core. This leads to issues for service projects that aren't ASP.NET Core projects, e.g. Blazor WebAssembly projects, JSPS projects (SPA), Worker projects, etc.

We need to figure out what the story is for shared code in service projects that aren't ASP.NET Core projects.

This is https://github.com/dotnet/astra/issues/194, but specific for Service Discovery.

At the moment in the app model we do the following methods to populate environment variables:

WithEnviroment(string, string)
WithEnvironment(string, Func<string>)
WithEnvironment(Action<Dictionary<string, string>)

I think that we'll probably end up having to add:

WithEnvironment(string, string, EnvironmentHandling) // enum EnvironmenHandling { Secret, NotSecret }
WithEnvironment(string, Func<string>, EnvironmentHandling)
WithEnvironment(Action<EnvironmentContext>)

Usage on that last one:

WithEnvironment((env) => {
  env.AddVariable("FOO", "bar");
  env.AddSecret("BAR", "foo");
});

Most orchestrators have this concept of something that is mapped as an environment variable but is otherwise handled as a secret throughout the platform.

We desperately need to improve the nature of our error messages that we produce via exceptions and the way that we present them via logging for the application builder.

At the moment the cloud app model itself is in DI, but individual components/annotations are not. The key thing that we need to log is once the app model is handed over to the publishing target. So the main hosting code and the publishing targets need to get a logger and pass them to things like transformers where appropriate.

The dashboard (DevHost project) does not use the URL that's specified in the "applicationUrl" property of the active launch profile in launchSettings.json when launched via dotnet run. This is likely due to the fact it's expecting the URL to be provided in a new environment variable DOTNET_DASHBOARD_URL rather than the existing ASPNETCORE_URLS environment variable that dotnet run sets.

The dropdown on the Semantic Logs page is driven by services reported in OTLP. Each .NET project maps to a service with a configured service name and service instance id.

That's done here:
https://github.com/dotnet/astra/blob/835e1634a8d36bee67755c611b149711b6d37482/samples/Conventions/Extensions.cs#L43-L50

It's possible to create duplicate resources by running the aspire project multiple times with Ctrl+F5:

The service for the project has a different instance id so shows up as a different item in the dropdown.

For example, Ctrl+F5 launches the dashboard with its set of apps and they report telemetry to the dashboard which it saves. Then Ctrl+F5 is used again to launch apps again. They have new instance ids and data shows up with a duplicate name in the dropdown.

Possible fixes:

1. The instance id is generated in the hosting model and passed to the projects using an env var. Then only known projects are shown in the dropdown. Telemetry from other apps (perhaps they're out of date and running in the background) can't be viewed.
   • Pros: Pretty simple and foolproof. Only telemetry from projects the dashboard knows about is visible. Data from old projects isn't displayed.
   • Cons: Can't display telemetry from other sources, e.g. containers. Is that desirable? Might be able to use the same pattern to support containers/executables.
2. Another option is to merge telemetry from application instances together. That doesn't seem desirable to me, especially if they end up running side-by-side.
3. Some kind of hybrid model where known projects are displayed at the top of the dropdown with an icon and other unknown services are displayed below.
   • Unfortunately, fluent blazor doesn't support optgroups 😢
   • Maybe display older telemetry as MyFrontend (old dotnet/aspire-private-planning#1), MyFrontend (old dotnet/aspire-private-planning#2)
   • Need to consider memory usage. If old telemetry sticks around then it could use up a lot of memory over time.

We need to do a once over on all the APIs in Aspire.Hosting and ensure they have doc comments:

@DamianEdwards @davidfowl @terrajobst What do other folks think about for this one? Repos like dotnet/runtime and dotnet/aspnetcore do have an OSX PR Build to protect against breaks in developer workflow, but it is also true that those repos are more likely to have platform-specific code for OSX. For this repo, we would most likely just be making sure that the repo is still build-able from Macs. Doing this wouldn't be free, as I know that our OSX resources are by far the most limited and they are already operating at over-capacity, so this issue is just to have a conversation whether or not fixing that is something we should pursue.