An exciting chapter is upon us, folks, with the amazing .NET 8 RC 2!It’s out, and I must admit, it’s impressive—a lot like a treasure trove of an adventurer who’s had a really productive adventure.
Let’s get to it right away!
Better Docs: Microsoft’s READMEs
Whoa! Have you seen this? Microsoft has introduced READMEs for .NET libraries. As a developer, documentation should be your best friend. But sometimes, sifting through multiple docs to find how a method works can be, well, boring. The folks at Microsoft seem to understand this pain. They are now providing READMEs for their NuGet packages.
The README is the moment of truth. It’s your first interaction with a package. It tells you what the package does, and how you can start using it. By providing more comprehensive READMEs, Microsoft is making life easier for developers. This move enhances the overall developer experience. You won’t spend an eternity searching for information about various methods and functionalities.
But, hold on, this isn’t for all packages yet. It’s a work in progress. Currently, they have READMEs for several packages. The list includes the popular ones like Microsoft.Extensions.DependencyInjection and Microsoft.Extensions.Logging among others. Some new packages like Microsoft.Bcl.Numerics and Microsoft.Bcl.TimeProvider also got their READMEs.
I love this initiative. Documentation is an essential part of the developer experience, and it’s about time we had consistency across the board. From setup instructions to code examples, readability is key. Trust me, your future self would thank you for putting up a wholesome README.
The only downside I see is that this is limited to Microsoft packages for now. But don’t worry, I’m optimistic that this will catch on, and soon enough, all the packages would have comprehensive READMEs. So, let’s get cracking with these new packages. Shall we?
Oh, here’s the best part. You don’t have to do anything to get these READMEs. Your package explorer would automatically display them when you select one of these packages. Now, isn’t that cool?
MSBuild: Simple CLI-based project evaluation
Microsoft has taken another gigantic leap forward with a cracking feature in .NET 8 RC 2, MSBuild: Simple CLI-based project evaluation. Brace yourselves as we are about to delve into what this magic can do and, spoiler, it’s going to make our lives a whole lot easier! You ready?
Microsoft’s MSBuild has been the bulwark for .NET’s build platform, masterfully assimilating data and integrating tools from other ecosystems. However, the downside has been the difficulty of making this data accessible to scripting and tooling landscapes.
Ever had to manually insert your MSBuild code into Properties, Items, or Target Outputs, and then decipher those files? If that rings a bell, prep up! This new feature’s about to turn those tides and revolutionize your tooling-game. Sounds like a relief, doesn’t it?
Let’s peek at this sample, shall we?
>dotnet publish --getProperty:OutputPath
bin\Release\net8.0\
Picture this: You’re asking your toy robot for your red and blue crayons. Like magic, you see the robot bring you a little box, named ‘Properties’, that contains your requested crayons inside it – exactly what you wanted! This would be especially handy for tools like CI pipelines. Say goodbye to hardcoded output paths, and say hello to being data-driven!
But wait, there’s more! Alright folks, picture this scenario – we’re involved in a pretty dynamic operation. Something like, let’s say, creating and publishing a Container Image with the assistance of the .NET SDK. Wouldn’t it be super handy if some of the container’s characteristics were smartly churned out during the process?
>dotnet publish -p PublishProfile=DefaultContainer --getProperty:GeneratedContainerDigest --getProperty:GeneratedContainerConfiguration
Also, imagine you’ve asked your robot to do a specific task, let’s say paint a rainbow. Using a special same-as-magic command, –getTargetResults, you can see the result of the rainbow painting task your robot just completed. Simple, isn’t it? Now you have the green light to parse this data using your favorite language and JSON CLI tools, and integrate it into your tooling infrastructure. Now how’s that for evaluating a CLI-based project?
You’re probably asking, does the same template apply to MSBuild Items too? A big, loud yes is the answer! You can ask for them by Item Type using the –getItem: command. And wouldn’t you know it, MSBuild fetches these as JSON objects in a list under the name of the Item, all tucked in under the ever-present “Items” key.
We can also tug out the results of a specific Target that’s run using –getTargetResults:. You’ve got the hang of it by now, these results turn up under the TargetResults property.
>dotnet publish -p PublishProfile=DefaultContainer --getTargetResult:ComputeContainerBaseImage
Seems like Christmas came early, don’t you think? This undoubtedly enables MSBuild to readily blend with your tooling, paving the way for a smoother and more comprehensive dev experience.
SDK Container Publish: Publish to .tar.gz Archive
Let me draw your attention to a brand new feature offered by .NET 8 RC 2 that will truly make your life as a coder more comfortable, especially if you’re working with Docker or similar container platforms. Introducing the ability to directly publish your output as a .tar.gz archive!
Sounds cool, huh? Now why the fuss over this, you ask? Well, imagine a situation where your team needs to run several systems scanning over your images before pushing them into production. The tooling previously only allowed for direct pushes, which could be a limiting weapon in your team’s production arsenal. Here’s where this upgrade comes in to save your day!
Now, you can create a container directly as a tar.gz archive. You can move this archive, scan it, load it into local Docker toolchain – you get the freedom to dance to your own tunes!
Let’s dive into a quick code run to see how this works!
>dotnet publish -p PublishProfile=DefaultContainer -p ContainerArchiveOutputPath=./images/sdk-container-demo.tar.gz
Note the new shiny command parameter ContainerArchiveOutputPath. If you’re wondering, instead of pushing the image to Docker or a remote registry as we did before, we create a .tar.gz file specified by this property. Want to generate the name for the .tar.gz automatically? Sure thing, just provide a folder name, and the filename would be <image-name>.tar.gz by default.
And once you have your neat little tar.gz file, you’re all set! Move it, scan it, load it into Docker with docker load, the world is your playground!
>docker load --input .\images\sdk-container-demo.tar.gz
Easy as pie, right? Roll out your image straight into Docker and soar into action!
This new feature packs a massive punch and offers flexibility that could enable new workflows for likely more teams! Give it a spin, and let’s keep pulling rabbits out of the hat to evolve our coding narrative!
SDK Container Publish: Publish to tar.gz Archive
Ever had to publish your applications to a tar.gz archive for Docker scenarios, and found yourself wishing it was a bit more streamlined? Well, it’s time to rejoice, because with .NET 8 RC2, this has become a whole lot easier! .NET 8 RC2 now ships with a feature to publish your applications directly to a tarball – Yup, that’s right, we can now publish our apps directly to a tar.gz archive. Neat, isn’t it?
This is a feature I’ve been waiting for like a kid on Christmas eve. Not only does it simplify my workflow, it also makes it tons more efficient. With this, Microsoft teams are giving us developers more powers to play with!
Before this feature, imagine we wanted to dockerize our application. We would have needed to publish it, tarball it, and then add that tarball to our Docker image. It’s all too manual, isn’t it?
Now, things are different, and they work like a charm! The new SDK publishing feature allows us to do just this but in a single shot. The output of the SDK’s publish command is a tar.gz archive, ready to go! Let’s see how we can do this:
dotnet publish -c Release --output /app /p:PublishReadyToRun=true --nologo
tar -czf dotnetapp.tar.gz -C /app .
Our application is now published and tar.gz’d into a neat little package in just two steps. It’s a piece of cake, isn’t it? I know it’s a small change, but it’s the little things that make our lives as developers easier!
For all those of us who’ve been doing the tango with Docker and .NET core applications, this is a major win. No more juggling around with intermediary steps – we’ve got it all built-in now. This eliminates those extra mundane steps and lets us focus on what’s important – crafting exemplary applications!
This isn’t just about convenience though. By reducing the complexity of operations, it mitigates the chance of human error during the build process, making your entire pipeline more reliable. Quality and convenience, brought together!
In my professional opinion, this is an excellent addition to the .NET 8 RC2 features. It’s a great example of a tool evolving to streamline the user’s workflow. Now, that’s the kind of gamechanger I like to see! Increase in productivity, decrease in frustration – what’s not to love?
Conclusion
And that brings our .NET 8 RC 2 journey to a close, folks! It’s been quite a ride dissecting and analysing these new features. They say change is the only constant in tech, and aren’t we glad about that? Time to roll up those sleeves and start experimenting with these upgrades. You’re all set to take your development skills up a notch with RC 2.
Ready to play in this new sandbox, are you?
Top comments (1)
Sorry if I'm misreading this, but I think you've written about publishing to .tar.gz twice. I think maybe the two sections need to be merged?