Posted on Oct 18 • Originally published at bytehide.com Howdy, fellow developers! Here’s another exciting journey that we’re about to embark on, exploring the brand new features and updates released in .NET 8 Release Candidate 1 (RC 1). As the seasoned C# developer I am, I can’t wait to dive into the nitty-gritty details this update has to offer.From cross-building Windows apps on non-Windows platforms with Win32 resources to enabling Hardware Acceleration in WPF applications accessed via Remote Desktop Protocol, trust me, there’s a lot here to propel your creativity and efficiency to a whole new level.Are you ready to decode this beast?Well, stay tuned and let’s take reap the benefits of these innovations together!Let’s get to the core stuff and explore what’s new within the System.Text.Json namespace.You’re going to love these exciting additions! Be sure to keep up, we’re going to dive into the latest improvements in the .NET 8 Release Candidate 1 that pertain to System.Text.Json.Isn’t it fabulous how developments never cease? RC1 introduces extension methods for streaming deserialization of IAsyncEnumerable.Let’s take time to appreciate this by looking at a little code snippet, shall we?It’s just like magic, isn’t it?The power of JsonContent.Create has taken the limelight and how! Now, you can create JsonContent instances using trim safe/source generated contracts.Here’s a little demo just for you.One of the top highlights in their array of features is the newly introduced capability of parsing JsonNode instances from streams.The process of data parsing, traditionally a complicated concept to grasp, has now been made simpler and smoother with our cutting-edge mechanism that can parse JsonNode instances directly from streams.The excitement this feature is garnering isn’t surprising when you consider its potential to streamline the parsing process, an advantage clearly discernible to anyone who takes a moment to study the code.You know the good old JsonSerializerOptions.MakeReadOnly() method, right? Well, there have been a few tweaks to make it more trim conservative.But don’t just jump right into using it, there’s a tiny change. It’ll now throw an exception if the options aren’t kitted out with a resolver. Yeah, you heard it right! No resolver? You’re crashing with an exception!Okay, just to stick with our shoe theme, let’s think of this as tailoring a cool shoe design when we’ve got a final production run. We’re adding some comments to explain and keep on track. Here it is:With this, your brand new cool shoe design is ready for the final production run! It’s been designed, tested, and finally ready to be strutted on the fashion runway.Done this way, if there’s no resolver, the method will say “No problem buddy! I’ve got your back!” And bam, it’ll assign the standard reflection resolver to the option. It’s like a safety net in case you forgot to specify a resolver.Wondering what’s new when it comes to Android Application development in .NET? Hold on to your hats, folks, because I’m about to share something game-changing! Come on board as we explore the AndroidStripILAfterAOT setting on Android.Do you know what happened with .NET 6 and onwards? They implemented this cool thing called Profiled Ahead-of-Time (or AOT, if you want to sound all techy) compilation mode. It’s pretty sophisticated: whenever you’re building an application in ‘Release’ mode, it automatically starts using this new mode.So why the big fuss, you ask? Well, let me tell you, it’s because of the huge improvements it brings to the table. For starters, your app starts running like greased lightning, and the performance during runtime is just phenomenal. It’s like upgrading from a tricycle to a Ferrari!But, hang on a minute, before you start popping champagne, there’s a small catch. When AOT compilation is put to use, the size of your application tends to pump up. You might think of it as a trade-off, but it’s not necessarily a bad thing. Size doesn’t always matter, right?Well, our saviour here is the specific way the profiled AOT works – it doesn’t just go compiling everything left, right, and centre. Instead, it chooses specific bits of your app’s launch path to compile.This method accelerates startup times while only slightly expanding the application size. So, how can one tackle this issue of inflated size? The solution lies in AndroidStripILAfterAOT, a recent addition to the .NET functionalities.It reduces unused Intermediate Language (IL) that was compiled using AOT, and therefore decreases the application package (apk) size. This can result in a significant size reduction between 0 and 3.5% for an application built from a dotnet template application.Let’s face it, when developing Android applications, performance often takes precedence over everything else. If you are willing to allow for a slight uptick in app size in favor of enhanced performance, taking the AOT-compilation route for all the code is a smart move. The introduction of $(AndroidStripILAfterAOT) advances this approach a step further.This feature eliminates the unused Intermediate Language (IL), making any surge in app size due to AOT-compilation more manageable. An added advantage is that the removal of this unused IL can bolster your application’s .NET code security.However, keep in mind that although it strengthens the code, it does not make it completely secure against reverse-engineering tactics.Want to test drive it yourself? Incorporate the following MsBuild property for your Android app:By setting AndroidStripILAfterAOT to true, you’ll override the existing AndroidEnableProfiledAot setting and all trim-able AOT’d methods get shown the door. Profiled AOT and IL stripping can work in harmony when setting both explicitly:Now, let’s compare apk sizes for a dotnet new android app under different configurations:For the record, when you have $(AndroidStripILAfterAOT) set to false and $(AndroidEnableProfiledAot) set to true, you’re going with the default Release configuration environment and your app will stand at 7.7MB.So, excited to get stuck into these new features? I sure am! It would be great to get your feedback. If you stumble on any bugs or issues, please file them directly at the dotnet/runtime repository. Your input will help us make this feature even more user-friendly. Start exploring and let’s keep improving together!As we get closer to the General Availability (GA) release of .NET 8, an essential amendment has taken place in the .NET container images. Ready for what’s new? Say goodbye to the “preview” in the tag name for RC 1 and we’ll walk you through the changes.In the previous preview versions of .NET 8, we published the floating tags as 8.0-preview and 8.0-preview-. Well, from the RC 1 release onwards, we won’t maintain these tags. You may now be wondering what you should do instead. Well, simply replace your tag references with 8.0 and 8.0-. Sound easy, right?What’s the rationale behind the change, you ask? This transition ensures a smooth sailing journey towards the GA release of .NET 8. Moreover, these are set to be the permanent tags maintained throughout the lifecycle of .NET 8.Do you happen to create Windows apps from non-Windows platforms? This is going to be your favorite. Now imagine this, you’re building applications meant for Windows but on non-Windows platforms.Any recognized Win32 resources get seamlessly integrated into the resulting executable. A sigh of relief for cross-building aficionados, isn’t it?We’re talking about things like your application icon, manifest, and version information. Cool, right?In the past, to get these resources, applications had to be built on Windows. Eliminating this gap in cross-building support was a high demand, as it majorly alleviated issues related to infrastructure complexity and resource usage. Goodbye to those pain points and say hello to more efficient cross-building!Alright everyone, sit tight because I’ve got some groundbreaking news that will make your developer hearts sing! Remember how it used to be such a task to convert .NET applications to containers and then pushing these containers off to registries like Docker Hub and Azure Container Registry? Well, those days are over, my friends, thanks to the fantastic SDK Container publish feature!Now, I’m sure you’re no stranger to the fun and games we usually have when it comes to authenticating this sort of procedure. Most of the time, we’re stuck using that docker login command, right?However, there was always a catch when dealing with certain registries like Azure Container Registry – they aren’t into ordinary usernames & passwords. No siree, they instead kick it up a notch and use OAuth token exchange for authentication. Unfortunately, our poor old SDK Container publishing tools struggled to deal with this level of sophistication.Let’s get the confetti out because our long-awaited hero is here – the .NET 8.0.100 RC1! Starting today, our SDK Container publishing tool is totally cool with OAuth token exchange authentication method! Yeah, hard to believe, isn’t it? Finally, Azure Container Registry and other registries using the same method are now fair game!Any Blazor WebAssembly aficionados out there? If you use often WASM Browser, this one’s for you! Both platforms now support ahead-of-time (AOT) compilation where you can directly compile your .NET code into WebAssembly.AOT compilation does come with its perks – it boosts runtime performance. But, as a caveat, it also results in larger app sizes. With the new WasmStripILAfterAOT mode, we can slice the size of the _framework folder by a nifty 1.7% – 4.2%. If you’re curious about how we arrived at these figures, check out the above Github issue.Trust me when I say, this feature is a superstar whenever you go for AOT compilation. Smaller app size, and same stellar performance? Yeah, give it a shot!Ready to whip this tool into action? Set the following MsBuild property for your Blazor WebAssembly or WASM Browser app:By using this command, a large portion of the Intermediate Language (IL) code from both the built-in libraries and the code written by you splendid application developers will be chopped off. It’s like a neat little trim for your code to make it sleeker and more efficient.Hey there, WPF fans! Have you ever been working remotely, using a WPF application, and thought: “Man, I wish this thing had sharper visuals?” Well, it’s your lucky day because we’ve got just the update you’ve been dreaming of!Back in the day, you used to only have the option of software rendering, even when accessing your WPF applications remotely. Remember how frustrating that was? You’d have a beast of a machine capable of hardware rendering, but still being forced to settle for software rendering… a total bummer!Well, forget all that because we’re stirring things up with an amazing new feature that empowers developers to leverage the pure power of hardware acceleration when using the Remote Desktop Protocol (RDP). No more limitations, and no more settling for less. You just flip an AppContext switch and voilà, you are all set!Scratching your head wondering what the heck this hardware acceleration gibberish is? Let me break it down for you. Hardware acceleration is when we let your computer’s graphic processing unit (GPU) take the reins. This GPU speeds up the creation of visuals and graphics within your WPF application.So, what can you expect? A smooth, captivating visual experience that looks sweet and runs buttery smooth—quite the upgrade from software rendering, where your computer’s central processing unit (CPU) did all the heavy lifting. This old-school method was slower, not super efficient and let’s be honest, a total vibe killer.Alright, let’s get down to the nitty-gritty. How do you actually switch on this hardware acceleration feature in RDP? Well, my friends, you have not one but two ways to get this done, because who doesn’t like a little flexibility and choice, right?Gear up, folks, and test drive this fresh-off-the-lab feature. And should you stumble upon any glitches along the way, don’t hesitate to reach out. Got a bug to report or feedback to give? Send them directly to our dotnet/wpf repository. We’re eager to hear from you, because together, we’re only going to make the experience even better!So there you have it, a deep dive into the world of .NET 8 Release Candidate 1. I hope you found this useful and picked up a trick or two to implement in your projects. Remember, innovation and updates are always part of the developer’s lifecycle. Keep exploring, keep learning, and don’t forget to have fun while coding!Till next time, keep your code clean, your bugs minimal, and your passion for coding aflame. Happy coding, folks! Remember, the game is about continuously improving, adapting to changes and staying ahead – and there is no better way to do that than embracing every new update that comes your way.So, stay tuned for more engaging content, updates, and development adventures.Templates let you quickly answer FAQs or store snippets for re-use.Thank you Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse Mila Wu - Oct 10 Shaunak Jagtap - Oct 9 Leonardo Camargo - Oct 12 Nathan Tarbert - Oct 13 Once suspended, bytehide will not be able to comment or publish posts until their suspension is removed. Once unsuspended, bytehide will be able to comment and publish posts again. Once unpublished, all posts by bytehide will become hidden and only accessible to themselves. If bytehide is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to ByteHide. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag bytehide: bytehide consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging bytehide will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.