diff --git a/content/1.posts/64.manage-dotnet-versions.md b/content/1.posts/64.manage-dotnet-versions.md index aa185d3..e314225 100644 --- a/content/1.posts/64.manage-dotnet-versions.md +++ b/content/1.posts/64.manage-dotnet-versions.md @@ -43,7 +43,7 @@ You can then uninstall .NET versions using the `dotnet-core-uninstall remove` co If you are using Visual Studio, updating it to the latest version will automatically update the .NET versions too. You can also use the installer to add specific .NET versions in the individual components section. -![The image shows the Visual Studio Installer interface, focusing on the "Individual components" tab. Several .NET runtimes and SDKs are listed with checkboxes. Among them, .NET 6.0 Runtime (Long Term Support), .NET 7.0 Runtime, .NET 8.0 Runtime (Long Term Support), .NET 9.0 Runtime, and .NET Aspire SDK are checked. Some runtimes are marked as "Out of support."](/posts/images/64.dotnet-versions-3.png){.rounded-lg.mx-auto } +![The image shows the Visual Studio Installer interface, focusing on the "Individual components" tab. Several .NET runtimes and SDKs are listed with checkboxes. Among them, .NET 6.0 Runtime (Long Term Support), .NET 7.0 Runtime, .NET 8.0 Runtime (Long Term Support), .NET 9.0 Runtime, and Aspire SDK are checked. Some runtimes are marked as "Out of support."](/posts/images/64.dotnet-versions-3.png){.rounded-lg.mx-auto } ## 4 - Use a package manager like winget diff --git a/content/1.posts/66.developer-experience-thoughts.md b/content/1.posts/66.developer-experience-thoughts.md index e3e9c15..62bac54 100644 --- a/content/1.posts/66.developer-experience-thoughts.md +++ b/content/1.posts/66.developer-experience-thoughts.md @@ -56,4 +56,4 @@ With [Pulumi](https://www.pulumi.com/product/infrastructure-as-code/) you can au I’m not saying you should use these technologies, it depends on your context and preferences. These are just 2 examples of technologies that I love, partly due to their developer experience and why it matters. -So, what’s next ? I want to start a new series of articles “.NET Aspirations” talking about [.NET Aspire](https://learn.microsoft.com/en-us/dotnet/aspire/get-started/aspire-overview?wt.mc_id=MVP_430820). .NET Aspire primarily aims at improving the local development experience when developing modern .NET applications (distributed or not). That seems an interesting topic to keep talking about developer experience. See you in the next article, and keep learning. +So, what’s next? I want to start a new series of articles “Aspirations” talking about [Aspire](https://learn.microsoft.com/en-us/dotnet/aspire/get-started/aspire-overview?wt.mc_id=MVP_430820). Aspire primarily aims at improving the local development experience when developing modern .NET applications (distributed or not). That seems an interesting topic to keep talking about developer experience. See you in the next article, and keep learning. diff --git a/content/1.posts/67.aspnetcore-with-nuxt.md b/content/1.posts/67.aspnetcore-with-nuxt.md index ca78bfd..171e74f 100644 --- a/content/1.posts/67.aspnetcore-with-nuxt.md +++ b/content/1.posts/67.aspnetcore-with-nuxt.md @@ -165,6 +165,6 @@ Here are the weather forecasts retrieved from the API and displayed in the Front ![A table showing dates with weather summaries and temperatures in Celsius and Fahrenheit.](/posts/images/67.temperatures.png){.rounded-lg.mx-auto} -Nothing fancy, but I hope this gives you a good understanding of how we can integrate an ASP.NET Core API with a Nuxt front end. Not everything is perfect, we have the URL of the API hardcoded in the Nuxt configuration, and we have to launch the API and the front end separately. In an upcoming article, we will explore how to use .NET Aspire to improve the developer experience. +Nothing fancy, but I hope this gives you a good understanding of how we can integrate an ASP.NET Core API with a Nuxt front end. Not everything is perfect, we have the URL of the API hardcoded in the Nuxt configuration, and we have to launch the API and the front end separately. In an upcoming article, we will explore how to use Aspire to improve the developer experience. You can find the complete source code used for this article in this [GitHub repository](https://github.com/TechWatching/AspnetWithNuxt/tree/initial-without-aspire). diff --git a/content/1.posts/69.aspire-tailor-to-your-stack.md b/content/1.posts/69.aspire-tailor-to-your-stack.md index ecfc68e..6752d39 100644 --- a/content/1.posts/69.aspire-tailor-to-your-stack.md +++ b/content/1.posts/69.aspire-tailor-to-your-stack.md @@ -1,6 +1,6 @@ --- -title: ".NET Aspirations - Tailor It To Your Stack" -description: "Using .NET Aspire with a Nuxt front end" +title: "Aspirations - Tailor It To Your Stack" +description: "Using Aspire with a Nuxt front end" date: 2025-03-02 image: src: /images/aspire_1.webp @@ -12,15 +12,15 @@ tags: - Nuxt - .NET --- -You might have already seen blog posts and videos showing how .NET Aspire can enhance our local development environment, using an example with a Blazor SPA and an ASP.NET Core API. However, not everyone uses Blazor; many prefer a JavaScript framework for front-end development. +You might have already seen blog posts and videos showing how Aspire can enhance our local development environment, using an example with a Blazor SPA and an ASP.NET Core API. However, not everyone uses Blazor; many prefer a JavaScript framework for front-end development. -Fortunately, we can still benefit from .NET Aspire regardless of our stack. In this article, we will explore how to use .NET Aspire to develop an application composed of an ASP.NET Core back end and a Nuxt front end. +Fortunately, we can still benefit from Aspire regardless of our stack. In this article, we will explore how to use Aspire to develop an application composed of an ASP.NET Core back end and a Nuxt front end. ## The context The context is very basic: developing a web application with an ASP.NET Core API for the back end and a Nuxt application for the front end. The Nuxt application calls the ASP.NET Core API to get data to show on the website. -The goal is to easily run the back end and front end together locally. While using .NET Aspire is not necessary for this, .NET Aspire orchestration can simplify the process and help address some common issues. +The goal is to easily run the back end and front end together locally. While using Aspire is not necessary for this, Aspire orchestration can simplify the process and help address some common issues. ## What problems are we trying to solve? @@ -37,9 +37,9 @@ We can use this [application](https://github.com/TechWatching/AspnetWithNuxt/tre ![A table showing dates with weather summaries and temperatures in Celsius and Fahrenheit.](/posts/images/69.temperatures.png){.rounded-lg.mx-auto width="400"} -## Add .NET Aspire to our existing project +## Add Aspire to our existing project -Since .NET 9, we no longer need to install a specific workload for .NET Aspire. We only need to install the .NET Aspire templates, as they make it easier to add .NET Aspire to our application. +Since .NET 9, we no longer need to install a specific workload for Aspire. We only need to install the Aspire templates, as they make it easier to add Aspire to our application. ```powershell dotnet new install Aspire.ProjectTemplates @@ -91,7 +91,7 @@ Thanks to the source generated `WebApi` class in the `Projects` namespace, we do ### For the `WebApp` -We can use an integration from the [Aspire Community toolkit](https://learn.microsoft.com/en-us/dotnet/aspire/community-toolkit/overview?wt.mc_id=MVP_430820) which contains community-driven integrations for .NET Aspire, including one for Vite applications like my Nuxt project. +We can use an integration from the [Aspire Community toolkit](https://learn.microsoft.com/en-us/dotnet/aspire/community-toolkit/overview?wt.mc_id=MVP_430820) which contains community-driven integrations for Aspire, including one for Vite applications like my Nuxt project. ```bash dotnet add AppHost\AppHost.csproj package CommunityToolkit.Aspire.Hosting.NodeJS.Extensions @@ -111,7 +111,7 @@ var webApp= builder.AddViteApp("WebApp", "../WebApp", "pnpm") * `WaitFor` ensures the `WebApi` is running before starting the `WebApp` -The only downside of using `AddViteApp` is that it doesn't currently support exposing the HTTPS endpoint. So, even though the `WebApp` will be launched by the `AppHost` and will work correctly with HTTPS, its URL in the .NET Aspire dashboard will be in HTTP. This isn't a major issue; you could just replace the `http` in the URL by `https`. But let’s fix that anyway to use another method `AddPnpmApp` (there are other methods like `AddNpmApp` for other package manager) of the Aspire Community toolkit instead: +The only downside of using `AddViteApp` is that it doesn't currently support exposing the HTTPS endpoint. So, even though the `WebApp` will be launched by the `AppHost` and will work correctly with HTTPS, its URL in the Aspire dashboard will be in HTTP. This isn't a major issue; you could just replace the `http` in the URL by `https`. But let’s fix that anyway to use another method `AddPnpmApp` (there are other methods like `AddNpmApp` for other package managers) of the Aspire Community toolkit instead: ```csharp [AppHost/Program.cs] var webApp= builder.AddPnpmApp("WebApp", "../WebApp", "dev") @@ -124,7 +124,7 @@ var webApp= builder.AddPnpmApp("WebApp", "../WebApp", "dev") You don’t need to know exactly what `AddPnpmApp` does behind the scenes, but it might be helpful to check out (use your IDE to access the decompiled code with F12). I’ve heard people like Scott Hanselman and Mark Russinovich say that we should try to “understand how things work one level below the level we are operating on”, and I find this very true. In the end, the `PnpmAdd` resource is just an executable resource called with specific commands and parameters. :: -## Running the `AppHost` with the .NET Aspire dashboard +## Running the `AppHost` with the Aspire dashboard If we run the `AppHost` now, it will start the `WebApp` and `WebApi`. @@ -132,9 +132,9 @@ If we run the `AppHost` now, it will start the `WebApp` and `WebApi`. dotnet run --project AppHost/AppHost.csproj ``` -The `AppHost` also launches the .NET Aspire dashboard where we can see the resources (here the `WebApp` and the `WebApi`) with their status and details about them like the endpoints and the environment variables. +The `AppHost` also launches the Aspire dashboard where we can see the resources (here the `WebApp` and the `WebApi`) with their status and details about them like the endpoints and the environment variables. -![Screenshot of the resources tab on the .NET Aspire dashboard.](/posts/images/69.dashboard_1.png){.rounded-lg.mx-auto} +![Screenshot of the resources tab on the Aspire dashboard.](/posts/images/69.dashboard_1.png){.rounded-lg.mx-auto} There is also a `console` tab in the dashboard to visualize the console logs of the different resources. @@ -153,9 +153,9 @@ var webApp= builder.AddPnpmApp("WebApp", "../WebApp", "dev") .WaitFor(webApi); ``` -.NET Aspire includes built-in support for service discovery, which automatically set the correct environment variables and connection strings when referencing resources properly. +Aspire includes built-in support for service discovery, which automatically set the correct environment variables and connection strings when referencing resources properly. -![Screenshot of the environment variables in .NET Aspire dashboard for the WebApp resource.](/posts/images/69.dashboard_3.png){.rounded-lg.mx-auto} +![Screenshot of the environment variables in Aspire dashboard for the WebApp resource.](/posts/images/69.dashboard_3.png){.rounded-lg.mx-auto} Here, we can see that the endpoints of the `WebApi` have been automatically injected in the environment variables of the `WebApp`. @@ -195,12 +195,12 @@ The route rules configuration in the `nuxt.config.ts` files becomes the followin And everything keep working fine. -![Screenshot of the .NET Aspire dashboard showing the environment variable ApiUrl on the WebApp resource.](/posts/images/69.dashboard_4.png){.rounded-lg.mx-auto} +![Screenshot of the Aspire dashboard showing the environment variable ApiUrl on the WebApp resource.](/posts/images/69.dashboard_4.png){.rounded-lg.mx-auto} ## Final thoughts -We have seen how adding .NET Aspire to our project helped us solve the three problems we had: the lack of a unified start process, the need for a centralized place to view logs, and the possibility to remove the hard-coded API URL of our Nuxt configuration. The code for this article is available [here](https://github.com/TechWatching/AspnetWithNuxt/tree/71d2da1a2a1237a63e9a124c9d1b6b9bba508a42). +We have seen how adding Aspire to our project helped us solve the three problems we had: the lack of a unified start process, the need for a centralized place to view logs, and the possibility to remove the hard-coded API URL of our Nuxt configuration. The code for this article is available [here](https://github.com/TechWatching/AspnetWithNuxt/tree/71d2da1a2a1237a63e9a124c9d1b6b9bba508a42). -Since .NET Aspire is highly customizable, it's easy to adjust it to fit our stack and needs. We focused on orchestrating the two resources we had but did not configure open telemetry. We'll discuss that in a future blog post. +Since Aspire is highly customizable, it's easy to adjust it to fit our stack and needs. We focused on orchestrating the two resources we had but did not configure open telemetry. We'll discuss that in a future blog post. In the meantime, keep learning! diff --git a/content/1.posts/71.aspire-open-telemetry.md b/content/1.posts/71.aspire-open-telemetry.md index cb062dc..fd8a572 100644 --- a/content/1.posts/71.aspire-open-telemetry.md +++ b/content/1.posts/71.aspire-open-telemetry.md @@ -1,6 +1,6 @@ --- -title: ".NET Aspirations - Embracing OpenTelemetry" -description: "Integrating OpenTelemetry with .NET Aspire" +title: "Aspirations - Embracing OpenTelemetry" +description: "Integrating OpenTelemetry with Aspire" date: 2025-03-12 image: src: /images/aspire-otel.png @@ -13,21 +13,21 @@ tags: - .NET --- -In my previous [.NET Aspire blog post](https://techwatching.dev/posts/aspire-tailor-to-your-stack), we talked about using .NET Aspire to orchestrate the different parts of our web application. However, the .NET Aspire dashboard did not show any telemetry (traces, metrics, or structured logging) because we did not instrument the API or front-end code. We are going to change that in this article, and see how we can easily integrate [OpenTelemetry](https://opentelemetry.io/) into our [application](https://github.com/TechWatching/AspnetWithNuxt). +In my previous [Aspire blog post](https://techwatching.dev/posts/aspire-tailor-to-your-stack), we talked about using Aspire to orchestrate the different parts of our web application. However, the Aspire dashboard did not show any telemetry (traces, metrics, or structured logging) because we did not instrument the API or front-end code. We are going to change that in this article, and see how we can easily integrate [OpenTelemetry](https://opentelemetry.io/) into our [application](https://github.com/TechWatching/AspnetWithNuxt). -## Observability with the .NET Aspire Dashboard +## Observability with the Aspire Dashboard -When your application is deployed in a production environment, you are likely using observability platforms like Jaeger, Prometheus, New Relic, Honeycomb, Datadog, Azure Monitor, or other vendors that support OpenTelemetry. But you probably don’t have any of these tools in your local development environment. The .NET Aspire dashboard is designed to provide built-in support for observability when debugging your application locally. This allows you to better understand how your application behaves in your development environment, detect potential performance issues, and investigate any problems. +When your application is deployed in a production environment, you are likely using observability platforms like Jaeger, Prometheus, New Relic, Honeycomb, Datadog, Azure Monitor, or other vendors that support OpenTelemetry. But you probably don’t have any of these tools in your local development environment. The Aspire dashboard is designed to provide built-in support for observability when debugging your application locally. This allows you to better understand how your application behaves in your development environment, detect potential performance issues, and investigate any problems. -To achieve that, the [.NET Aspire dashboard implements an OpenTelemetry Protocol (OTLP) server](https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/telemetry#net-aspire-local-development?wt.mc_id=MVP_430820). It provides OTLP endpoints for applications to send telemetry data, and includes pages to visualize the received data. +To achieve that, the [Aspire dashboard implements an OpenTelemetry Protocol (OTLP) server](https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/telemetry#net-aspire-local-development?wt.mc_id=MVP_430820). It provides OTLP endpoints for applications to send telemetry data, and includes pages to visualize the received data. That's great, but if we want to see telemetry from our web application, we first need to set up the instrumentation. To demonstrate this, we will use our [existing web application](https://github.com/TechWatching/AspnetWithNuxt/tree/f13278296bf3989af53d8560a5c4eae4862a1bea), which consists of a Nuxt.js front end called `WebApp` and an ASP.NET Core API called `WebApi`, and instrument both parts. ## Add the instrumentation code to the `WebApi` -The [OpenTelemetry SDK for .NET](https://github.com/open-telemetry/opentelemetry-dotnet) includes everything we need to collect the telemetry data (logs, traces, metrics). So we could directly install the nuget packages in the `WebApi` project, and implement the code to configure the instrumentation and use the the .NET Aspire dashboard OTLP endpoint.It would work, and if you already have an app using OpenTelemetry, you likely only need to make a few configuration changes to make it compatible with the .NET Aspire dashboard. +The [OpenTelemetry SDK for .NET](https://github.com/open-telemetry/opentelemetry-dotnet) includes everything we need to collect the telemetry data (logs, traces, metrics). So we could directly install the nuget packages in the `WebApi` project, and implement the code to configure the instrumentation and use the Aspire dashboard OTLP endpoint. It would work, and if you already have an app using OpenTelemetry, you likely only need to make a few configuration changes to make it compatible with the Aspire dashboard. -In our case, we will use instead a [.NET Aspire service defaults project](https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/service-defaults?wt.mc_id=MVP_430820) to set everything up easily. The purpose of using this Aspire Shared project is to offer predefined extension methods that help configure things like OpenTelemetry, health check endpoints, retry policies, and more across the various services and resources that make up the application. Let’s create this project using the `aspire-servicedefaults` template (from the [.NET Aspire template](https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/aspire-sdk-templates?pivots=dotnet-cli&wt.mc_id=MVP_430820)) and reference it in the `WebApi` project. +In our case, we will use instead an [Aspire service defaults project](https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/service-defaults?wt.mc_id=MVP_430820) to set everything up easily. The purpose of using this Aspire Shared project is to offer predefined extension methods that help configure things like OpenTelemetry, health check endpoints, retry policies, and more across the various services and resources that make up the application. Let’s create this project using the `aspire-servicedefaults` template (from the [Aspire template](https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/aspire-sdk-templates?pivots=dotnet-cli&wt.mc_id=MVP_430820)) and reference it in the `WebApi` project. ```bash dotnet new aspire-servicedefaults -o ServiceDefaults @@ -105,15 +105,15 @@ builder.ConfigureOpenTelemetry(); Please note that this method only configures OpenTelemetry. To benefit from service discovery, resilience, and health checks, there are other methods you should call. However, the simplest way is to call `builder.AddServiceDefaults`, which configures everything directly. :: -![OpenTelemetry environment variables in the .NET Aspire dashboard.](/posts/images/71.aspire-otel_1.png){.rounded-lg.mx-auto } +![OpenTelemetry environment variables in the Aspire dashboard.](/posts/images/71.aspire-otel_1.png){.rounded-lg.mx-auto } -Since .NET Aspire automatically provides the needed OpenTelemetry environment variables to the various resources it manages, the code we added in the `WebApi` will correctly export the traces, metrics, and logs to the dashboard, where they will be displayed. +Since Aspire automatically provides the needed OpenTelemetry environment variables to the various resources it manages, the code we added in the `WebApi` will correctly export the traces, metrics, and logs to the dashboard, where they will be displayed. -![Logs of the WebApi in the .NET Aspire dashboard.](/posts/images/71.aspire-otel_2.png){.rounded-lg.mx-auto } +![Logs of the WebApi in the Aspire dashboard.](/posts/images/71.aspire-otel_2.png){.rounded-lg.mx-auto } -![Traces of the WebApi in the .NET Aspire dashboard.](/posts/images/71.aspire-otel_3.png){.rounded-lg.mx-auto } +![Traces of the WebApi in the Aspire dashboard.](/posts/images/71.aspire-otel_3.png){.rounded-lg.mx-auto } -![Metrics of the WebApi in the .NET Aspire dashboard.](/posts/images/71.aspire-otel_4.png){.rounded-lg.mx-auto } +![Metrics of the WebApi in the Aspire dashboard.](/posts/images/71.aspire-otel_4.png){.rounded-lg.mx-auto } If we had other .NET resources (such as other APIs, services, or a Blazor front end), we could configure them just as easily by calling the same methods from `ServiceDefaults`. However, for a browser application, it's not as straightforward. @@ -134,7 +134,7 @@ The first point can be handled easily by replacing the environment variable `DOT "DOTNET_DASHBOARD_OTLP_HTTP_ENDPOINT_URL": "https://localhost:16175", ``` -![HTTP OTEL endpoint environment variable in the .NET Aspire dashboard.](/posts/images/71.aspire-otel_5.png){.rounded-lg.mx-auto } +![HTTP OTEL endpoint environment variable in the Aspire dashboard.](/posts/images/71.aspire-otel_5.png){.rounded-lg.mx-auto } For the second point, there isn't much we can do. However, even though client instrumentation in the browser is still experimental, the OpenTelemetry JavaScript SDK works well and there are resources to help you set it up: @@ -151,7 +151,7 @@ Anyway, for the moment we won’t be able to see in the dashboard structured log I won’t explain everything we need to do to add the instrumentation code to our Nuxt.js application `WebApp` because I already did it in this [blog post](https://techwatching.dev/posts/aspire-otel). What I did is I implemented an OpenTelemetry plugin for Nuxt.js that export the application traces to an OTEL backend. You can grab the code [here](https://github.com/TechWatching/AspnetWithNuxt/blob/f13278296bf3989af53d8560a5c4eae4862a1bea/WebApp/app/plugins/instrumentation.ts) but I suggest you to read the [article](https://techwatching.dev/posts/aspire-otel) to understand how this code is using the OpenTelemetry SDKs. -Starting from this code, we now just have to make it work with the .NET Aspire dashboard as the OTEL backend. That’s the third, to provide the OTEL environment variables that the browser application will use. +Starting from this code, we now just have to make it work with the Aspire dashboard as the OTEL backend. That’s the third, to provide the OTEL environment variables that the browser application will use. In the `WebApp`, we have some OpenTelemetry configuration that the plugin uses to process and export the telemetry data: @@ -173,7 +173,7 @@ To override this configuration at runtime ([you don’t want to set them in your * `NUXT_PUBLIC_OTEL_EXPORTER_OTLP_HEADERS` * `NUXT_PUBLIC_OTEL_SERVICE_NAME` -Those are the same environment variables that .NET Aspire provides to the `WebApp` but prefixed with `NUXT_PUBLIC`. Fortunately, someone with the same problem but for Vite created [an issue on the Aspire repository](https://github.com/dotnet/aspire/issues/1898) and David Fowler suggested the following code to automatically add a prefix: +Those are the same environment variables that Aspire provides to the `WebApp` but prefixed with `NUXT_PUBLIC`. Fortunately, someone with the same problem but for Vite created [an issue on the Aspire repository](https://github.com/dotnet/aspire/issues/1898) and David Fowler suggested the following code to automatically add a prefix: ```csharp [AppHost/EnvironmentExtensions.cs] namespace AppHost; @@ -210,15 +210,15 @@ var webApp= builder.AddPnpmApp("WebApp", "../WebApp", "dev") .WithEnvironmentPrefix("NUXT_PUBLIC_"); ``` -We can check that we now have the environment variables twice (with prefix and without) so that .NET Aspire correctly provides the OTEL configuration in the `WebApp`. +We can check that we now have the environment variables twice (with prefix and without) so that Aspire correctly provides the OTEL configuration in the `WebApp`. -![Environment variables twice in .NET Aspire dashboard.](/posts/images/71.aspire-otel_6.png){.rounded-lg.mx-auto } +![Environment variables twice in Aspire dashboard.](/posts/images/71.aspire-otel_6.png){.rounded-lg.mx-auto } And with just that, we can now see both the traces from the `WebApi` and the `WebApp` in the dashboard. -![Traces of the WebApi and WebApp in the .NET Aspire dashboard.](/posts/images/71.aspire-otel_7.png){.rounded-lg.mx-auto} +![Traces of the WebApi and WebApp in the Aspire dashboard.](/posts/images/71.aspire-otel_7.png){.rounded-lg.mx-auto} -![Details of a traces in the .NET Aspire dashboard.](/posts/images/71.aspire-otel_8.png){.rounded-lg.mx-auto} +![Details of a trace in the Aspire dashboard.](/posts/images/71.aspire-otel_8.png){.rounded-lg.mx-auto} ::callout{icon="i-heroicons-light-bulb"} Please note that traces are correlated when using client side rendering (like on the screenshot above), but not when using server side rendering. There is probably an additional thing to configure in the Nuxt instrumentation. @@ -226,8 +226,8 @@ Please note that traces are correlated when using client side rendering (like on ## Final thoughts -Thanks to the .NET Aspire dashboard, we can easily view telemetry data from different parts of the application locally. Additionally, with the `ServiceDefaults` project, integrating OpenTelemetry with .NET applications is straightforward. Although adding instrumentation to browser applications can be challenging and requires some extra work, it is still possible and improves the overall observability of the application. +Thanks to the Aspire dashboard, we can easily view telemetry data from different parts of the application locally. Additionally, with the `ServiceDefaults` project, integrating OpenTelemetry with .NET applications is straightforward. Although adding instrumentation to browser applications can be challenging and requires some extra work, it is still possible and improves the overall observability of the application. -Not only does .NET Aspire improve the local development experience by bringing observability to where you code, but it also encourages you to implement things correctly by default. Without .NET Aspire, I probably wouldn't have delved into the subject of OpenTelemetry and kept using vendor specific SDKs. +Not only does Aspire improve the local development experience by bringing observability to where you code, but it also encourages you to implement things correctly by default. Without Aspire, I probably wouldn't have delved into the subject of OpenTelemetry and kept using vendor specific SDKs. You can find the complete code [here](https://github.com/TechWatching/AspnetWithNuxt/tree/254a27e60849f9ecfb759bf4f29c8b9307cbfb2e). Keep learning. diff --git a/content/1.posts/72.w11-2025-tips-learned-this-week.md b/content/1.posts/72.w11-2025-tips-learned-this-week.md index 39d4ee7..3089031 100644 --- a/content/1.posts/72.w11-2025-tips-learned-this-week.md +++ b/content/1.posts/72.w11-2025-tips-learned-this-week.md @@ -39,7 +39,7 @@ Sometimes, we don’t want to clone an entire git repository but just to have a I find it particularly useful when you want to browse open source code samples. -![Screenshot of the vscode Remote Repositories view with the editor opened on README of .NET Aspire samples.](/posts/images/72.w112025tips-4.png){.rounded-lg.mx-auto} +![Screenshot of the vscode Remote Repositories view with the editor opened on README of Aspire samples.](/posts/images/72.w112025tips-4.png){.rounded-lg.mx-auto} ## Troubleshoot your HTTP requests using devtunnels echo diff --git a/content/1.posts/73.aspire-devcert.md b/content/1.posts/73.aspire-devcert.md index e75172d..935f6cf 100644 --- a/content/1.posts/73.aspire-devcert.md +++ b/content/1.posts/73.aspire-devcert.md @@ -1,5 +1,5 @@ --- -title: ".NET Aspirations - Use ASP.NET Core HTTPS Development Certificate" +title: "Aspirations - Use ASP.NET Core HTTPS Development Certificate" description: "Simplify HTTPS set up in your local development environment" date: 2025-03-18 image: @@ -16,7 +16,7 @@ tags: It's a good practice to use HTTPS in your local development environment to closely match the production environment and prevent future HTTPS issues. -In a previous [article](https://techwatching.dev/posts/aspnetcore-with-nuxt-https), I discussed how to set up HTTPS on a web application with an ASP.NET Core API and a Nuxt.js front end. This was done using the ASP.NET Core HTTPS Development certificate. However, for the front end, it required using the `dev-certs` [**built-in command of the .NET CLI**](https://learn.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-9.0&tabs=visual-studio%2Clinux-sles&wt.mc_id=MVP_430820#trust-the-aspnet-core-https-development-certificate) **to export the certificate files (key file and** `pem` file). That's fine, but it would be better if this step could be automated when using .NET Aspire. Let's explore that. +In a previous [article](https://techwatching.dev/posts/aspnetcore-with-nuxt-https), I discussed how to set up HTTPS on a web application with an ASP.NET Core API and a Nuxt.js front end. This was done using the ASP.NET Core HTTPS Development certificate. However, for the front end, it required using the `dev-certs` [**built-in command of the .NET CLI**](https://learn.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-9.0&tabs=visual-studio%2Clinux-sles&wt.mc_id=MVP_430820#trust-the-aspnet-core-https-development-certificate) **to export the certificate files (key file and** `pem` file). That's fine, but it would be better if this step could be automated when using Aspire. Let's explore that. As usual, we will use our [`AspnetWithNuxt` sample](https://github.com/TechWatching/AspnetWithNuxt). In our `WebApp`, we currently assume that the certificate files are already generated and available in our folder, so the paths to these files are hard-coded in the Nuxt configuration: @@ -56,7 +56,7 @@ What we would need instead is to use environment variables that contain these pa That seems better. But now we need a way to ensure the certificate files exist, generate them if they don’t, and automatically inject these environment variables. Ideally, this would be configured in the `AppHost` by calling a specific method when defining the `WebApp` resource. -And guess what, there is an [issue](https://github.com/dotnet/aspire/issues/6890) on the .NET Aspire GitHub repository discussing exactly such a method. Unfortunately, at the time of writing this method is not built-in but can be found in the [`aspire-samples` repository](https://github.com/dotnet/aspire-samples/blob/0c27e4e3bac5f102db1002fd2e0e1ba894e1009a/samples/Shared/DevCertHostingExtensions.cs). We just need to copy it and place it in our `AppHost` project +And guess what, there is an [issue](https://github.com/dotnet/aspire/issues/6890) on the Aspire GitHub repository discussing exactly such a method. Unfortunately, at the time of writing this method is not built-in but can be found in the [`aspire-samples` repository](https://github.com/dotnet/aspire-samples/blob/0c27e4e3bac5f102db1002fd2e0e1ba894e1009a/samples/Shared/DevCertHostingExtensions.cs). We just need to copy it and place it in our `AppHost` project. ::collapsible{openText="Show the code of the" closeText="Hide the code of the" name="DevCertHostingExtensions.cs file"} @@ -268,6 +268,6 @@ var webApp= builder.AddPnpmApp("WebApp", "../WebApp", "dev") .RunWithHttpsDevCertificate("CERT_PATH", "CERT_KEY_PATH"); ``` -And that's it. Thanks to .NET Aspire, setting up HTTPS in our application is now easier. And from what I've read about the issues on the repository, it seems there are likely improvements coming to .NET Aspire to make this feature built-in and even better. Anyway, this is a great example of how we can easily customize .NET Aspire to fit our needs and enhance the developer experience. +And that's it. Thanks to Aspire, setting up HTTPS in our application is now easier. And from what I've read about the issues on the repository, it seems there are likely improvements coming to Aspire to make this feature built-in and even better. Anyway, this is a great example of how we can easily customize Aspire to fit our needs and enhance the developer experience. You can find the complete code [here](https://github.com/TechWatching/AspnetWithNuxt/tree/6e8f2efa7c68d6399f12859230cdd0beaa8d8218). Keep learning.