Roundup #25: NETStandard2.1, Code Behind The Vulnerability, Compositional UIs, ML.NET

Here are the things that caught my eye this week.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.


.NET Standard 2.1

Since we shipped .NET Standard 2.0 about a year ago, we’ve shipped two updates to .NET Core 2.1 and are about to release .NET Core 2.2. It’s time to update the standard to include some of the new concepts as well as a number of small improvements that make your life easier across the various implementations of .NET.

I find it interesting, but predictable, that .NET Framework 4.8 will stay on .NET Standard 2.0.  At this point, I would consider only .NET Core and Mono/Xamarin to be following the standard going forward.


The Code Behind The Vulnerability

OWASP illustrates that developers keep making the same mistakes over and over again, but what about more esoteric vulnerabilities?

In this session Barry will take you beyond SQL injection covering some of the code behind now fixed ASP.NET vulnerabilities. By the end of the session you should be poring through your own code looking for problems with dictionaries, compression, encryption and more



Compositional UIs With Hosted Views and Hypermedia

This is a session given by Asbjørn Ulsberg at Nordic APIs 2018 Platform Summit on October 24th, in Stockholm, Sweden.

In the new brave world of decoupled and autonomous microservices, there’s a lot of knowledge, best practices and attention given to APIs. But once you start integrating these APIs in a UI, it quickly becomes a monolith of highly coupled components that replicate a lot of the functionality provided in the underlying APIs.

As everyone probably knows and agrees to by now, monoliths are not a design goal. By making your UI compositional through hosted views and by moving some of the business logic from the client to the server through the use of hypermedia, you can achieve full vertical integrations that are horizontally decoupled in a microservice fashion all the way from the persistence layer and up to the user interface.



ML.NET 0.7 (Machine Learning .NET)

We’re excited to announce today the release of ML.NET 0.7 – the latest release of the cross-platform and open source machine learning framework for .NET developers (ML.NET 0.1 was released at //Build 2018). This release focuses on enabling better support for recommendation based ML tasks, enabling anomaly detection, enhancing the customizability of the machine learning pipelines, enabling using ML.NET in x86 apps, and more.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #24: JSON, .NET Core 3, Framework Reference, Orleans Dashboard

Here are the things that caught my eye this week.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.


The future of JSON in .NET Core 3.0

JSON has become an essential part of virtually all modern .NET applications and in many cases even surpassed the usage of XML. However, .NET hasn’t had a (great) built-in way to deal with JSON. Instead we’ve relied on Json.NET which continues to serve the .NET ecosystem well.

Moving forward, we plan on making some changes to our JSON support.



A first look at changes coming in ASP.NET Core 3.0

While we continue to work on finalizing the next minor version of ASP.NET Core, we’re also working on major updates to our next release that will include some changes in how projects are composed with frameworks, tighter .NET Core integration, and 3rd party open source integration, all with the goal of making it easier and faster for you to develop. For broader context around .NET Core 3.0, we encourage you to check out our previous announcements around the addition of WinForms and WPF support to .NET Core 3.0 on Windows. We’ll publish more details about new features coming in ASP.NET Core 3.0 in the near future.

The big takeaway for me was that ASP.NET Core 3.0 will only run on .NET Core 3.  This means no more .NET Standard support.  In other words, no longer supporting .NET Framework.



ASP.NET Core 3.0 will only run on .NET Core

As announced on the .NET Blog earlier this month, .NET Framework will get fewer of the newer platform and language features that come to .NET Core moving forward, due to the in-place update nature of .NET Framework and the desire to limit changes there that might break existing applications. To ensure ASP.NET Core can fully leverage the improvements coming to .NET Core moving forward, ASP.NET Core will only run on .NET Core starting from 3.0. Moving forward, you can simply think of ASP.NET Core as being part of .NET Core.

Here’s a link to the discussions thread since the previous link contains the announcement.



Replace PackageReference to Microsoft.AspNetCore.App with FrameworkReference

Most NuGet packages provide both compilation and runtime assets. Microsoft.NETCore.App and Microsoft.AspNetCore.App effectively only provide the first – compilation references. Users must install other runtime assets to make .NET Core apps work but this is not obvious or intuitive, and not always possible: for example, Azure Web Apps, AWS, Google Cloud, etc. This violates a reasonable expectation of using a NuGet package, and has been a continual source of confusion for users.



.NET Standard v2.0 vs v2.1

Neat object model diagram showing the differences between .NET Standard 2.0 and 2.1.



Microsoft Orleans Reporting Dashboard

Orleans is an easy to use actor framework, but how can you monitor your deployment? Luckily, there’s something simple to use — Orleans Dashboard!



Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Clearing Local NuGet Cache

Local NuGet CacheWhy would you need to clear your local NuGet cache?  Recently I realized that my local NuGet cache was just over 7GB.  Yes, gigabytes.

Local NuGet Cache

You may not even realize that NuGet stores copies of NuGet packages on your machine.  There are a couple of places they are stored.

If you have the latest .NET Core SDK, you can run:

dotnet nuget locals all --list 

Or if you have the latest NuGet.exe you can run:

.\nuget.exe locals all -list

The result will show you the locations of where NuGet packages are cached.

Global Packages

If you check out the location of global-packages, mine was just over 7GB.


You can clear these package locations by using:

dotnet nuget locals all --clear

or with

.\nuget.exe locals all -clear


You don’t have to clear all location types (global-packages, http-cache, etc).  For more options check out:

dotnet nuget locals --help


.\nuget.exe locals -help

Thanks Oren Novotny!

Thanks go out to Oren Novotny for pointing out this functionality.  Have you been using this already?  Let me know on Twitter or in the comments.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.