Topics

.NET Aspire enhances the local development process with its powerful orchestration feature for app composition. In the .NET Aspire App Host, you specify all the projects, executables, cloud resources, and containers for your application in one centralized location. When you run the App Host project, .NET Aspire will automatically run your projects and executables, provision cloud resources if necessary, and download and run containers that are dependencies for your app. .NET Aspire 9 added new features to give you more control over how container lifetimes are managed on your local machine to speed up development when working with containers. Containers with .NET Aspire Let’s look at a simple example of a .NET Aspire App Host that creates a local Redis container resources, waits for it to become available, and then configures the connection string for the web projects: // Create a distributed application builder given the command line arguments. var builder = DistributedApplication.CreateBuilder(args); // Add a Redis server to the application. var cache = builder.AddRedis("cache"); // Add the frontend project to the application and configure it to use the // Redis server, defined as a referenced dependency. builder.AddProject<Projects.MyFrontend>("frontend") .WithReference(cache) .WaitFor(cache); When the App Host is started, the call to AddRedis will download the appropriate Redis image. It will also create a new Redis container and run it automatically. When we stop debugging our App Host, .NET Aspire will automatically stop all of our projects and will also stop our Redis container and delete the associated volume that typically is storing data. Container lifetimes While this fits many scenarios, if there aren’t going to be any changes in the container you may just want the container to stay running regardless of the state of the App Host. This is where the new WithLifetime API comes in allowing you to customize the lifetime of containers. This means that you can configure a container to start and stay running, making projects start faster because the container will be ready right away and will re-use the volume. var builder = DistributedApplication.CreateBuilder(args); // Add a Redis server to the application and set lifetime to persistent var cache = builder.AddRedis("cache") .WithLifetime(ContainerLifetime.Persistent); builder.AddProject<Projects.MyFrontend>("frontend") .WithReference(cache) .WaitFor(cache); Now, when we run our App Host if the container isn’t found it will still create a new container resource and start it, however if it is found with the specified name, .NET Aspire will use that resource instead of creating a new one. When the App Host shuts down, the container resource will not be terminated and will allow you to re-use it across multiple runs! You will be able to see that the container is set to Persistent with a little pin icon on the .NET Aspire dashboard: How does it work? By default, several factors are taken into consideration when .NET Aspire determines whether to use an existing container or to create a new one when ContainerLifetime.Persistent is set. .NET Aspire will first generate a unique name for the container based on a hash of the App Host project path. This means that a container will be persistent for a specific App Host, but not globally if you have multiple App Host projects. You can specify a container name with the WithContainerName method, which would allow for a globally unique persistent container. In addition to the container name, .NET Aspire will consider the following: Container image Commands that start the container and their parameters Volume mounts Exposed container ports Environment variables Container restart policy .NET Aspire takes all of this information and creates a unique hash from it to compare with any existing container data. If any of these settings are different then the container will NOT be reused and a new one will be created. So, if you are curious why a new container may have been created, it’s probably because something has changed. This is a pretty strict policy that .NET Aspire started with for this new option, and the team is looking for feedback on future iterations. What about persisting data? Now that we are persisting our containers between launches of the App Host, it also means that we are re-using the volume that was associated with it. Volumes are the recommended way to persist data generated by containers and have the benefit that they can store data from multiple containers at a time, offer high performance, and are easy to back up or migrate. So, while yes we are re-using the volume, a new container may be created if settings are changed. Having more control of the exact volume that is used and being reused allows us to do things such as: Maintain cached data or messages in a Redis instance across app launches. Work with a continuous set of data in a database during an extended development session. Test or debug a changing set of files in an Azure Blob Storage emulator. So, let’s tell our container resource what volume to use with the WithDataVolume method. By default it will assign a name based on our project and resource names: {appHostProjectName}-{resourceName}-data, but we can also define the name that will be created and reused which is helpful if we have multiple App Hosts. var cache = builder.AddRedis("cache") .WithLifetime(ContainerLifetime.Persistent) .WithDataVolume("myredisdata"); Now, a new volume will be created and reused for this container resource and if for some reason a new container is created it will still use the myredisdata volume. Using volumes are nice because they offer ideal performance, portability, and security. However, you may want direct access and modification of files on your machine. This is where data bind mounts come in when you need real-time changes. var cache = builder.AddRedis("cache") .WithLifetime(ContainerLifetime.Persistent) .WithDataBindMount(@"C:\Redis\Data"); Data bind mounts rely on the filesystem to persist the Redis data across container restarts. Here, the data bind mount is mounted at the C:\Redis\Data on Windows in the Redis container. Now, in the case of Redis we can also control persistence for when the Redis resource takes snapshots of the data at a specific interval and threshold. var cache = builder.AddRedis("cache") .WithLifetime(ContainerLifetime.Persistent) .WithDataVolume("myredisdata") .WithPersistence(interval: TimeSpan.FromMinutes(5), keysChangedThreshold: 100); Here, the interval is the time between snapshot exports and the keysChangedThreshold is the number of key change operations required to trigger a snapshot. Integrations have their own specifications for WithDataVolume and WithBindMount, so be sure to check the integration documentation for the ones you use. More control over resources We now have everything set up, persisted, and ready to go in our App Host. As a bonus, .NET Aspire 9 also added the ability to start, stop, and restart resources including containers directly from the dashboard! This is really nice to be able to test resiliency of your applications without having to leave the dashboard. Upgrade to .NET Aspire 9 There is so much more in .NET Aspire 9, so be sure to read through the What’s new in .NET Aspire 9.0 documentation and easily upgrade in just a few minutes with the full upgrade guide. There is also newly updated documentation on container resource lifetimes, persisting data with volumes, and the new dashboard features. Let us know what you think of this new feature in .NET Aspire 9 and all of the other great features in the comments below. The post .NET Aspire Quick Tip – Managing Container & Data Lifetime appeared first on .NET Blog. View the full article

It has been an absolutely outstanding year of content for .NET from creators around the globe sharing their passion for .NET and the .NET team giving insight into the latest and greatest in the world of .NET. From events, live streams, and plenty of on-demand content dropping on the .NET YouTube nearly every single day, it is a great way to stay up to date, but also get involved and give feedback to the team in real-time. This year, developers tuned into the .NET YouTube more than ever before with over 8 million views of content, left over 6,000 comments, smashed the like button over 120,000 times, and over 50,000 new subscribers joined the channel. There is now more variety of content than ever and that has led to over 700K hours of watch time this year alone! This is over 29,000 days watched or to go even a step further… nearly 80 years! Top .NET videos of 2024 It was fun looking back at this year’s top videos as it really was a wide range of content. The most watched video on the channel was Scott Hanselman and David Fowler’s What is C#? video in the C# for Beginner’s series. However, if we take a look at just new videos released in 2024 then Scott shows up yet again, but this time with Stephen Toub in the first entry in Deep .NET on async/await. That was closely followed up with Dan Roth and Safia Abdalla’s What is ASP.NET Core? that went directly into the new front-end and back-end beginner series that launch this year. There is so much more to recap though as there were over 260 new videos released on the .NET YouTube this year! Let’s take a look at what else the community has been tuning into. Deep .NET If you are looking for deep technical content, then look no further than Scott Hanselman and Stephen Toub’s series, Deep .NET. Each episode, Scott and Stephen go in-depth on a topic which has ranged from async/await, Span, RegEx, LINQ, ArrayPool, Parallel Programming, and more. Recently they have been hosting more .NET team members including Eric Erhardt who went deep on Native AOT. Scott and Stephen will be back in 2025 with even more Deep .NET episodes and you will hear from even more voices from the .NET team. So, if you love this type of content, be sure to reach out to Scott & Stephen or leave a comment on YouTube and tell them who and what you want to hear about on Deep .NET. .NET Conf 2024 At this year’s .NET Conf, the 14th entry in the series, we celebrated the launch of .NET 9 and the amazing .NET community. Completely free & virtual, this year’s 3-day event featured a BONUS 4th day of exclusive YouTube premier sessions and the 3rd iteration of the .NET Conf – Student Zone! With over 90 sessions to explore, there is something for everyone. Not to mention that there is still time to link up with your local community with .NET Conf local events happening through January 2025! .NET Conf wasn’t the only major .NET streaming event this year. In August, .NET Conf: Focus on AI highlighted the latest in AI development with .NET. We also celebrated the launch of .NET Aspire 8.1 with a full day of content at .NET Aspire Developers Day. If you are looking for more cloud content for .NET applications, the Azure Developers YouTube ran events on all things .NET on Azure and another event all about using Azure with .NET Aspire! ASP.NET Core Beginner Series Dan Roth and Safia Abdalla re-introduced the world to ASP.NET Core and then went deeper with full beginner series on both front-end web development and back-end API development with .NET. For front-end web development, Dan dives deep into Blazor, Razor, components, render modes, and so much more to build a complete application from scratch. If you are more into API development, then Safia has you covered with all things ASP.NET Core for APIs including building, testing, adding middleware, dependency injection, and so much more. These are just a few of the new beginner series that launched this year to help developers jumpstart their development journey with .NET. Introduction to .NET Aspire Can you believe that it was just 7 months again that .NET Aspire officially launched, helping developers streamline their development process and build better distributed applications? So much has happened in the world of .NET Aspire including several new releases, the launch of the .NET Aspire Community Toolkit, and plenty of .NET Aspire content. One of the most watched series on the .NET YouTube was Welcome to .NET Aspire, where the team took developers through all of the different parts of .NET Aspire. Looking to get started and want to see how to integrate .NET Aspire into your existing apps? Then Jeff Fritz has you covered with the brand new .NET Aspire beginner series, a 90 minute deep dive into all things .NET Aspire. Top .NET Live Streams of 2024 Events and on-demand content weren’t the only thing happening on the .NET YouTube. There was a live stream taking place nearly every other day with over 150 taking place in 2024 alone! Let’s take a look at the top stream. Let’s Learn .NET – Blazor The Let’s Learn .NET series is a world wide live stream interactive event where you can follow along at home to learn a new .NET technology and ask questions live. Besides events, this year’s #1 most watched live stream was the Let’s Learn Blazor event walking through the latest and greatest in building full-stack web apps with .NET. That was only the start for Let’s Learn .NET as they continued throughout the year and included .NET Aspire, Containers, and AI with Semantic Kernel. It has been really exciting to see the series grow and now be live streamed in 7 different languages for developers everywhere! On .NET Live: Modular Monoliths with ASP.NET Core Steve Smith is iconic when it comes to ASP.NET Core architecture videos and guidance. His session at .NET Conf every year consistently is one of the most watched and commented on. This year, the On .NET Live team had him on to talk all about making decisions between monolith and microservice based architecture. Every week the On .NET Live team brings on amazing community members to talk about a wide range of topics, so be sure to browse the entire catalog of live streams. .NET Community Standups Hear and interact directly with team members building .NET here at Microsoft. That is what the .NET Community Standups are all about, they are a behind the scenes look at its development and a great way to have your voice heard and get your questions answered. In 2024, over 100K developers tuned in live and another 300K developers caught up on past community standup streams. Here are the top community standups of 2024 for each team: ASP.NET Core – .NET 9 Roadmap & Blazor Hybrid in .NET 9 Languages & Runtime – C# 13 and beyond .NET Data – Database Concurrency .NET AI – Get Started with AI in .NET .NET MAUI – .NET MAUI and .NET Aspire That’s a wrap! Thanks to everyone that created, enjoyed, commented, smashed that like button in 2024! We have tons of great new content coming your way in 2025 so make sure you go and subscribe to the .NET YouTube if you haven’t yet to stay up to date. If you don’t have access to YouTube, don’t worry as all .NET videos are also available on Microsoft Learn! What were your favorite videos and live streams of 2024? What are you looking forward to in 2025? Let us know in the comments below. The post Top .NET Videos & Live Streams of 2024 appeared first on .NET Blog. View the full article

Welcome to your new Invision Community! Take some time to read through the Getting Started Guide and Administrator Documentation. The Getting Started Guide will walk you through some of the necessary steps to setting up your community. The Administrator Documentation takes you through the details of the capabilities of our platform. Go to the Documentation

We are currently making an unexpected change to the way that .NET installers and archives are distributed. This change may affect you and may require changes in your development, CI, and/or production infrastructure. We expect that most users will not be directly affected, however, it is critical that you validate if you are affected and to watch for downtime or other kinds of breakage.   The most up-to-date status is being maintained at dotnet/core #9671. Please look to that issue to stay current.   If you are having an outage that you believe is caused by these changes, please comment on the reference GitHub issue and/or email us at dotnet@microsoft.com.   [HEADING=1]Affected domains[/HEADING]   We maintain multiple Content Delivery Network (CDN) instances for delivering .NET builds. Some end in[iCODE]azureedge.net[/iCODE]. These domains are hosted by edg.io, which will soon cease operations due to bankruptcy. We are required to migrate to a new CDN and will be using new domains going forward.   It is possible that [iCODE]azureedge.net[/iCODE] domains will have downtime in the near-term. We expect that these domains will be permanently retired in the first few months of 2025.     Note   No other party will ever have access to use these domains.   Affected domains:     [iCODE]dotnetcli.azureedge.net[/iCODE] [iCODE]dotnetbuilds.azureedge.net[/iCODE]     Unaffected domains:     [iCODE]dotnet.microsoft.com[/iCODE] [iCODE]download.visualstudio.microsoft.com[/iCODE]   [HEADING=1]Our response[/HEADING]   We made several changes in response. We have tried to reduce what you need to do to react. In many cases, you won’t need to do anything special.   New CDNs:     Official builds: [iCODE]builds.dotnet.microsoft.com[/iCODE] CI builds: [iCODE]ci.dot.net[/iCODE]     Updated .NET install script:     The install script now uses the new domains, per dotnet/install-scripts #555 This script has been deployed to the official locations, as described in dotnet-install scripts reference     Addressing CI installers:     GitHub Actions has been updated to use the new domains, per actions/setup-dotnet #570 We expect that GitHub Enterprise Server will be addressed in January. Azure DevOps [iCODE]UseDotnetTask[/iCODE] will be updated in January We do not yet have a date for updating Azure DevOps Server.   [HEADING=1]Domain configuration[/HEADING]   We are in the process of changing the configuration of our domains. At present, they may be using a combination of Akamai, Azure Front Door, and edgio. Our highest priority has been maintaining domain operation while we initiate new service with other CDN providers and validate their capability in our environment.   We are using Azure Traffic Manager to split traffic between them, primarily for reliability.   [HEADING=1]Call to action[/HEADING]   There are several actions you can take to determine if you have any exposure to [iCODE]azureedge.net[/iCODE] retirement.   Search your source code, install scripts, Dockerfiles and other files for instances of [iCODE]azureedge.net[/iCODE]. We also noticed that there is a lot of use of our storage account: [iCODE]dotnetcli.blob.core.windows.net[/iCODE]. Please also search for it. The storage account is unaffected, however, it would be much better for everyone if you used our new CDN. It will deliver better peformance.     Update [iCODE]dotnetcli.azureedge.net[/iCODE] to [iCODE]builds.dotnet.microsoft.com[/iCODE] Update [iCODE]dotnetcli.blob.core.windows.net[/iCODE] to [iCODE]builds.dotnet.microsoft.com[/iCODE]       Note   The new CDN is path-compatible with those servers. It’s only the domain that needs to change.   Please check for copies of the install script that you may have within your infrastructure. You will need to update it.   You will need to move to the latest version of the GitHub Action and Azure DevOps Task installers to ensure that you are protected from downtime.   Please check firewall rules that might prevent you from accessing our new CDNs, similar to this conversation.   [HEADING=1]Closing[/HEADING]   We are sorry that we are making changes that affect running infrastructure and asking you to react to them during a holiday period. As you can see, the need for these changes was unexpected and we are trying to make the best choices under a very compressed schedule.   We are hoping that the mitigations that we put into place will result in most users being unaffected by this situation.   With every crisis, there are opportunities for learning. We realized that we are missing public documentation on how to best use all of the installation-related resources we provide, to balance reliability, security, performance, and productivity. We will be working on producing this documentation in the new year.   The post Critical: .NET Install links are changing appeared first on .NET Blog.   Continue reading...

We are currently making an unexpected change to the way that .NET installers and archives are distributed. This change may affect you and may require changes in your development, CI, and/or production infrastructure. We expect that most users will not be directly affected, however, it is critical that you validate if you are affected and to watch for downtime or other kinds of breakage. The most up-to-date status is being maintained at dotnet/core #9671. Please look to that issue to stay current. If you are having an outage that you believe is caused by these changes, please comment on the reference GitHub issue and/or email us at dotnet@microsoft.com. Affected domains We maintain multiple Content Delivery Network (CDN) instances for delivering .NET builds. Some end inazureedge.net. These domains are hosted by edg.io, which will soon cease operations due to bankruptcy. We are required to migrate to a new CDN and will be using new domains going forward. It is possible that azureedge.net domains will have downtime in the near-term. We expect that these domains will be permanently retired in the first few months of 2025. Note No other party will ever have access to use these domains. Affected domains: dotnetcli.azureedge.net dotnetbuilds.azureedge.net Unaffected domains: dotnet.microsoft.com download.visualstudio.microsoft.com Our response We made several changes in response. We have tried to reduce what you need to do to react. In many cases, you won’t need to do anything special. New CDNs: Official builds: builds.dotnet.microsoft.com CI builds: ci.dot.net Updated .NET install script: The install script now uses the new domains, per dotnet/install-scripts #555 This script has been deployed to the official locations, as described in dotnet-install scripts reference Addressing CI installers: GitHub Actions has been updated to use the new domains, per actions/setup-dotnet #570 We expect that GitHub Enterprise Server will be addressed in January. Azure DevOps UseDotnetTask will be updated in January We do not yet have a date for updating Azure DevOps Server. Domain configuration We are in the process of changing the configuration of our domains. At present, they may be using a combination of Akamai, Azure Front Door, and edgio. Our highest priority has been maintaining domain operation while we initiate new service with other CDN providers and validate their capability in our environment. We are using Azure Traffic Manager to split traffic between them, primarily for reliability. Call to action There are several actions you can take to determine if you have any exposure to azureedge.net retirement. Search your source code, install scripts, Dockerfiles and other files for instances of azureedge.net. We also noticed that there is a lot of use of our storage account: dotnetcli.blob.core.windows.net. Please also search for it. The storage account is unaffected, however, it would be much better for everyone if you used our new CDN. It will deliver better peformance. Update dotnetcli.azureedge.net to builds.dotnet.microsoft.com Update dotnetcli.blob.core.windows.net to builds.dotnet.microsoft.com Note The new CDN is path-compatible with those servers. It’s only the domain that needs to change. Please check for copies of the install script that you may have within your infrastructure. You will need to update it. You will need to move to the latest version of the GitHub Action and Azure DevOps Task installers to ensure that you are protected from downtime. Please check firewall rules that might prevent you from accessing our new CDNs, similar to this conversation. Closing We are sorry that we are making changes that affect running infrastructure and asking you to react to them during a holiday period. As you can see, the need for these changes was unexpected and we are trying to make the best choices under a very compressed schedule. We are hoping that the mitigations that we put into place will result in most users being unaffected by this situation. With every crisis, there are opportunities for learning. We realized that we are missing public documentation on how to best use all of the installation-related resources we provide, to balance reliability, security, performance, and productivity. We will be working on producing this documentation in the new year. The post Critical: .NET Install links are changing appeared first on .NET Blog. View the full article