DEV Community: Edward Miller

A feature wishlist for C#

Edward Miller — Sat, 27 Jul 2024 17:53:10 +0000

C# is very near to a perfect programming language, by my standards. But there are still some rough edges.

There has been much discussion about proposals such as extension types or the field keyword inside getters and setters, which are mostly about convenience.

And there's been a lot of work on source generators and AOT, which is mainly about performance.

But I think we need a focus on correctness. Here are some examples:

Real Nullable Types

The null reference exception is a legacy of the "billion-dollar mistake" that Tony Hoare said he made in the design of the ALGOL W language in 1965. We have been dealing with it ever since.

Nullable types ought to be an authentic part of the type system in C#. They currently appear to be like a thin shim of syntactic sugar that are little more than Roslyn analyzers.

If you make a public function that requires a non-nullable parameter that is a reference type, and call it from another project that doesn't enable nullable types... there is actually nothing stopping the parameter from being filled with null.

No error would be thrown at compile-time or runtime when trying to fill that parameter with a null.

So, despite that you have already clearly specified your intentions, you have to guard your public parameters against null references.

And if you try to detect whether a type is nullable or not, using reflection, then a reference type is going to always be seen as nullable. As far as I know, there is not even a way to write a generic function that detects whether you defined a reference type as non-nullable. Because no matter what you actually do it really is nullable.

All of that works fine for value types, but that still leaves way too much room for covert null reference exceptions.

Better type inference for generics with constraints

We should be able to do complex constraints where one generic type is a collection of another generic type. This helps broaden the expressivity of the type specifications, and thereby more precisely define what it is the program ought to be doing at compile-time.

We should want this for all the same reasons we like strong types in general.

Exception Type Matching

All possible exception types that can be thrown by a particular function call should be known at compile-time, much like Rust's concept of the Option type.

Analyzer CA1031 exists specifically to inform the user that they ought not be catching general exceptions.

A better language would be able to show you precisely in the IntelliSense popup all possible exception types that could be thrown, even without the library authors documenting the exceptions with XML comments.

If this were the case this would help the specific kinds of exceptions to be handled in the specific ways that they ought to be, without any fear of unknowns.

In Rust, you can do a switch statement upon all the possible exceptions, which makes it really clear when one of the possible exceptions wasn't considered.

In C#, baking this into the normal try-catch syntax would be fine, and then turning on CA1031 by default would be fine, as long as IntelliSense would always and reliably tell you exactly what exception types are missing. As it does with a switch statement on an enum.

And, aside from correctness-oriented improvements, there are some oversights in existing features need to be addressed:

Kotlin-style `init` blocks

If you want to add some imperative logic during initialization, you cannot currently use a primary constructor. Kotlin solved this with the init block. C# should copy that.

And some general .NET Framework enhancements are needed in the standard libraries:

Range support in `ICollection`

This one is super obvious. ObservableCollection is a great example of where we need it. There have been countless custom implementations of something like ObservableRangeCollection. Having all of the changes show up in a single CollectionChanged event makes vastly more sense than users falling back to using loops of Add() calls because the framework has this deficiency.

Deserializing interfaces with `System.Text.Json`

Newtonsoft.Json supports this by default without much effort on the part of the developer. System.Text.Json now has some support for "polymorphic deserialization," but it involves a lot of manual intervention on the part of the programmer.

Apparently, there are security concerns around this, and the current approach certainly allows for improved performance. But for quick and dirty stuff, it would be nice to have a simple default that just works for most cases. While still giving some safety valves against attack vectors, like attempting to (de)serialize Exception types.

`ConfigureAwait()` improvements

Library authors generally want to use ConfigureAwait(false) everywhere, but there is no easy way to define this globally. Having the codebase littered with ConfigureAwait(false) everywhere is ugly, and some async function calls are likely to be overlooked and thus defeat the entire point.

Turning on analyzer CA2007 can help, but you would need to intentionally do so, and know to do so. And it is still annoying.

There must be a better way.

A plan for cybersecurity and grid safety

Edward Miller — Fri, 10 Feb 2023 22:42:51 +0000

Humanity needs the following for cybersecurity and grid safety, particularly in our new era of machine learning and deepfakes.

These would be high-impact causes to fund or contribute to:

Identity Verification and CAPTCHA

We require coordinated efforts to design next-generation ID verification and CAPTCHA systems, potentially using various multi-factor validation focused more on validating that someone is a biological organism rather than someone who has language ability or who knows your Social Security Number.

Efforts: TPM standard, biometrics, Login.gov

Quantum-Proof Cryptography

We must encourage adoption of quantum-proof encryption. Quantum computing has a small chance of destroying all cryptographic infrastructure. That would mean all of our civilizational infrastructure would be compromised, from banking to the military.

Efforts: Open Quantum Safe project

Formal Verification

We must ensure adoption of formally verified and memory-safe computing infrastructure including OSes, TLS, DNS, NTP, SSH, etc.

Efforts: seL4, Project Everest, the Prossimo project of the ISRG, Let's Encrypt, and Prusti for the Rust language

EMP Shielding

We must harden all communications and energy grid infrastructure with EMP shielding. This can be accomplished with basic technology, such as faraday cages. But there is quite a lot of grid infrastructure, and it all needs to be carefully shielded, and that could potentially cost a lot of money.

All the news we are seeing about weather balloons being shot down is potentially related to testing out the US's readiness against a high altitude EMP blast. Such a blast could wipe out all communications infrastructure on an entire continent, and lead to unfathomable destruction.

But it isn't just nation-states that can inflict this damage. Solar storms can produce the same effects, and it is inevitable that we will be dealing with such an event. We need to be prepared, even if the cost is steep.

Efforts: H.R.2417 Secure High-voltage Infrastructure for Electricity from Lethal Damage Act (not passed)

Data Breach Protection

There are many known-faulty central bottlenecks for information security and identity compromise, like the cartel of credit reporting agencies. If we cannot outright obsolete these, we must at least penalize them for security breaches.

For certain extremely important information, like credit reporting systems, zero-knowledge and fully homomorphic encryption may be important. And they should at least try to keep up with malicious actors, who do pursue such things. But such systems are onerous and expensive, and wouldn't be pursued unless it were made urgent.

Efforts: Homomorphic Encryption Standardization, S.2289 Data Breach Prevention and Compensation Act (not passed)

Endpoint Security and Router Security

We should leverage the threat of court fines and insurance penalties to get organizations to decommission obsolete hardware and software, for themselves and their members. It takes decades to roll out core networking upgrades at the moment, but threats are moving fast and that is unacceptable. ISPs should give rewards to those who are in compliance with all the latest security measures.

Gray hat hackers have done such things as remotely exploiting scores of routers purely to perform remote updates and security patching. That is a possible area of help, but isn't organized.

Efforts: Ongoing efforts by many organizations with things like Wifi 6, WPA3, multi-factor auth requirements, Windows 11, etc.

Automated code checking

Automated bots to help open source codebases are now common. They perform static analysis, automated dependency upgrade pull requests, and so on. This model can and has been extended to automatically patch common coding mistakes, and we are just scraping the surface of what is possible

Efforts: Dependabot, CodeQL, Coverity, facebook's Infer tool, etc

Reproducible Builds

Reproducible build systems need to become common, since compromised build servers have been known as a key vector for compromising libraries and vended software. This would allow us to have peace of mind that running a scripted build process will always produce an identical binary that can be reliably checked by others. Thus, when downloading a binary from a server, you can have confidence that it was produced using the source code you expected, rather than just taking it on faith.

Efforts: Reproducible Builds project

Code Styling should be enforced by default

Edward Miller — Fri, 03 Feb 2023 18:14:27 +0000

Having standards, even suboptimal ones, is usually better than not having any standard.

Languages, compilers, IDEs, templates, and so on should all enforce consistent standards by default.

The Rust language has rustfmt and clippy. Javascript has eslint and prettier.

I'm a C# guy, so that is what I care about. For .NET we do have StyleCop analyzers. And EditorConfig exists to help at the IDE level across all languages. And git itself can be configured with such things as eol and autoclrf.

But StyleCop is not on by default, and not enforced by default. A default EditorConfig configuration is not automatically applied by default when generating project templates, either via Visual Studio or "dotnet new".

Someone already went through the trouble of producing a editorconfig dotfile that conforms to the StyleCop rules, and yet it isn't even suggested to be applied by any important C# tool. Which is a glaring oversight as bad as when default gitignore files were not suggested by default, leading to countless repos cluttered with bin and obj folders.

The concept of Semantic Diffs may finally be starting to take off, and that will eventually go a long way to improve things when it comes to diffs.

But messy diffs are not the only reason to want code to be consistent. It is also crucial for readability, and even for ensuring that the program logic is explicit. If it is mandatory to qualify instance members, as StyleCop's rules recommend, that helps make things explicit. Yet, the de facto community conventions in C# are the opposite of the guidelines.

Future versions of Visual Studio, OmniSharp, Roslyn, and the dotnet CLI should be taking this to heart going forward, and begin to enforce all of this by default for new projects.

But the best thing you can do is to keep your own home tidy, by ensuring that you turn on StyleCop analyzers, enforce them in your pipeline, and include a strict editorconfig dotfile.

.NET MAUI iOS Camera Photos Rotated bug fix

Edward Miller — Sun, 29 Jan 2023 08:17:50 +0000

At the time of writing this article, there is a bug in MAUI that has existed since Xamarin.Forms where photos taken from iOS do not respect the device orientation, or record that information in the EXIF data, and thus they can end up incorrectly rotated.

This one was one of the most annoying bugs in MAUI, and I solved it with this workaround taken from IeuanWalker on this thread.

I adapted the code to more precisely conform to the existing MediaPicker conventions, and am using nullable types.

Just put this in your Platforms/iOS folder:

namespace YourAppName.Platforms.iOS;

using System;
using System.Threading.Tasks;
using Foundation;
using Microsoft.Maui.Graphics.Platform;
using UIKit;

public static class PhotoCaptureUtil
{
    public static async Task<FileResult?> CapturePhotoAsync(MediaPickerOptions? options = null)
    {
        options ??= new MediaPickerOptions { Title = "Take a photo" };

        return await MainThread.InvokeOnMainThreadAsync(async () => await InternalCapturePhotoAsync(options));
    }

    private static async Task<FileResult?> InternalCapturePhotoAsync(MediaPickerOptions options)
    {
        var taskCompletionSource = new TaskCompletionSource<FileResult?>();

        // Create an image picker object
        var imagePicker = new UIImagePickerController
        {
            SourceType = UIImagePickerControllerSourceType.Camera,
            MediaTypes = UIImagePickerController.AvailableMediaTypes(UIImagePickerControllerSourceType.PhotoLibrary),
        };

        if (string.IsNullOrEmpty(options.Title))
        {
            imagePicker.Title = options.Title;
        }

        var vc = Platform.GetCurrentUIViewController() ?? throw new InvalidOperationException($"Cannot retrieve {nameof(UIViewController)}");

        imagePicker.AllowsEditing = false;
        imagePicker.FinishedPickingMedia += async (sender, e) =>
        {
            var jpegFilename = Path.Combine(FileSystem.CacheDirectory, $"{Guid.NewGuid()}.jpg");
            var uiImage = e.Info[UIImagePickerController.OriginalImage] as UIImage;
            var normalizedImage = uiImage.NormalizeOrientation();
            var normalizedData = normalizedImage.AsJPEG();

            await vc.DismissViewControllerAsync(true);

            if (normalizedData.Save(jpegFilename, false, out var error))
            {
                _ = taskCompletionSource.TrySetResult(new FileResult(jpegFilename));
            }
            else
            {
                _ = taskCompletionSource.TrySetException(new IOException($"Error saving the image: {error}"));
            }

            imagePicker?.Dispose();
            imagePicker = null;
        };

        imagePicker.Canceled += async (sender, e) =>
        {
            await vc.DismissViewControllerAsync(true);
            _ = taskCompletionSource.TrySetResult(null);
            imagePicker?.Dispose();
            imagePicker = null;
        };

        await vc.PresentViewControllerAsync(imagePicker, true);

        return await taskCompletionSource.Task;
    }

    private class CameraDelegate : UIImagePickerControllerDelegate
    {
        public override void FinishedPickingMedia(UIImagePickerController picker, NSDictionary info) => picker.DismissViewController(false, null);
    }
}

and then call it like so:

    if (!MediaPicker.IsCaptureSupported)
    {
        await Shell.Current.DisplayAlertAsync("Camera permissions are not enabled on this platform.");
        return;
    }

#if IOS
    var fileResult = await PhotoCaptureUtil.CapturePhotoAsync();
#else
    var fileResult = await MediaPicker.CapturePhotoAsync();
#endif

Use .NET MAUI Map control with MVVM

Edward Miller — Sun, 22 Jan 2023 04:08:24 +0000

To use the current version of the .NET MAUI map control with MVVM, you will need to wrap it with some extra properties, if you want basic functionality like being able to set a selected pin or move the map via the ViewModel.

namespace MvvmMap;

using Microsoft.Maui.Maps;
using Map = Microsoft.Maui.Controls.Maps.Map;

public class MvvmMap : Map
{
    public static readonly BindableProperty MapSpanProperty = BindableProperty.Create(nameof(MapSpan), typeof(MapSpan), typeof(MvvmMap), null, BindingMode.TwoWay, propertyChanged: (b, _, n) =>
    {
        if (b is MvvmMap map && n is MapSpan mapSpan)
        {
            MoveMap(map, mapSpan);
        }
    });

    public static readonly BindableProperty SelectedItemProperty = BindableProperty.Create(nameof(SelectedItem), typeof(object), typeof(MvvmMap), null, BindingMode.TwoWay);

    public MapSpan MapSpan
    {
        get => (MapSpan)this.GetValue(MapSpanProperty);
        set => this.SetValue(MapSpanProperty, value);
    }

    public object? SelectedItem
    {
        get => (object?)this.GetValue(SelectedItemProperty);
        set => this.SetValue(SelectedItemProperty, value);
    }

    private static void MoveMap(MvvmMap map, MapSpan mapSpan)
    {
        var timer = Application.Current!.Dispatcher.CreateTimer();
        timer.Interval = TimeSpan.FromMilliseconds(500);
        timer.Tick += (s, e) =>
        {
            if (s is IDispatcherTimer timer)
            {
                timer.Stop();

                MainThread.BeginInvokeOnMainThread(() => map.MoveToRegion(mapSpan));
            }
        };

        timer.Start();
    }
}

Then you will want to implement it in XAML, backed with a ViewModel that contains an ObservableCollection of whatever model object you are using (in this case "Records").

To get the event arguments back from the EventToCommandBehavior, you need to specify the TypeArguments, as shown.

Note: this is also implementing the CustomPin control from Vladislav Antonyuk to allow for custom icons. If you use this, then you need to name the map and bind the map to the pin via the name, as shown.

    <ContentPage.Resources>
        <converters:StringToLocationConverter x:Key="stringToLocation" />
        <converters:RecordToIconConverter x:Key="recordToIcon" />
    </ContentPage.Resources>

    <cc:MvvmMap x:Name="mvvmMap1" ItemsSource="{Binding Records}" MapType="{Binding MapType, Mode=OneTime}" MapSpan="{Binding MapSpan}" IsShowingUser="True">
        <cc:MvvmMap.ItemTemplate>
            <DataTemplate x:DataType="models:Record">
                <cc:CustomPin Location="{Binding Location, Converter={StaticResource stringToLocation}}"
                              ImageSource="{Binding Converter={StaticResource recordToIcon}}"
                              Label="{Binding Name}"
                              Map="{Reference mvvmMap1}" />
            </DataTemplate>
        </cc:MvvmMap.ItemTemplate>
        <cc:MvvmMap.Behaviors>
            <toolkit:EventToCommandBehavior EventName="Loaded" Command="{Binding LoadedCommand}" />
            <toolkit:EventToCommandBehavior x:TypeArguments="MapClickedEventArgs" EventName="MapClicked" Command="{Binding MapClickedCommand}" />
        </cc:MvvmMap.Behaviors>
    </cc:MvvmMap>

The converter allows storing locations as strings in your database or wherever, and could look like this:

namespace YourProject.Converters;

using System.Globalization;

public class StringToLocationConverter : IValueConverter
{
    public object? Convert(object? value, Type? targetType, object? parameter, CultureInfo? culture)
    {
        if (value is null)
        {
            return null;
        }

        if (value is not string latLong)
        {
            throw new ArgumentException("value is not a string");
        }

        return GetLocation(latLong);
    }

    public object ConvertBack(object? value, Type? targetType, object? parameter, CultureInfo? culture) => throw new NotImplementedException();

    public static Location GetLocation(string latLong)
    {
        var (latitude, longitude) = GetLatitudeAndLongitude(latLong);
        return new Location(latitude, longitude);
    }

    public static (double Latitude, double Longitude) GetLatitudeAndLongitude(string latLong)
    {
        if (string.IsNullOrEmpty(latLong))
        {
            throw new ArgumentNullException(nameof(latLong));
        }

        var segments = latLong.Split(',');
        var latitude = double.Parse(segments[0], CultureInfo.InvariantCulture);
        var longitude = double.Parse(segments[1].TrimStart(), CultureInfo.InvariantCulture);
        return (latitude, longitude);
    }
}

See a working example here: https://github.com/symbiogenesis/MauiMvvmMap

.NET MAUI thoughts

Edward Miller — Sat, 21 Jan 2023 22:56:16 +0000

I am wrapping up developing a .NET MAUI app targeting Windows, Android, and iOS.

Overall, I would say that despite all the hiccups it was exactly what I was hoping for. Most of the problems I experienced were a result of the immaturity of the platform early on, and have since been resolved.

Despite having no specific mobile development experience, I was able to make progress very quickly. And would be able to go even faster today.

I had done a bunch of Silverlight, WPF, DotVVM, and other XAML style development for ages, and XAML + MVVM is by far my favorite stack.

I first coded the app in Xamarin.Forms since MAUI hadn't been released. But migrating was fairly easy. The upgrade-assistant tool helped some, and having any experience with ASP.NET style dependency injection makes the new parts feel familiar.

Stuff I liked:

It provides an open source cross-platform stack for native application development in .NET, with support for the latest .NET versions.
It is more batteries-included than Xamarin.Forms. Lots of concepts from Xamarin Essentials, the Xamarin Community Toolkit, and the wider ecosystem were simply incorporated directly into the framework, and expanded upon. Like SVG support, built-in screenshots, geolocation, permissions, file pickers, dark mode detection, and other platform-agnostic helpers.
It interoperates very seamlessly with Blazor, so you would be able to share everything from your ViewModel layer and below.
You can even directly incorporate WebView2 controls that you can interact with pretty nicely, which should allow mixing in web content, such as React, Angular, or Blazor apps.
My application was able to use an offline-first approach via Entity Framework and SQLite. I ended up implementing a bi-directional offline sync between SQLite and SQL Server, and this was done very easily as a background syncing service via the Dotmim.Sync library. And I was able to completely share the DbContext between the clients and the server.
I didn't know this at first, but there is an awesome IQueryAttributable interface that you can implement to parse all query parameters in one central place, and this just feels vastly nicer to use than attributes.
MAUI/Xamarin Shapes are really cool for making programmable platform-agnostic vector graphics.
The MAUI Community Toolkit has a lot of nice things like the Popup control, StateContainer, DockPanel, FolderPicker, and MVVM helpers.
The newest .NET versions support so many cool features built-in, and you can turn on a ton of extra features (nullable types), roslyn analyzers (Roslynator, StyleCop), code formatting helpers (EditorConfig), static analysis tools (InferSharp), build pipeline enhancements (Reproducible Builds, Nuget lockfiles), and so on. With all these guard rails up, it feels like the space for errors is much lower.

Hiccups:

Took awhile for the integrated map control to be released but it is mostly here now. Needed to do a bunch of manual work to implement custom icons, Windows support, and MVVM support.
GUIDs didn't seem to be implemented in a byte-identical way across the client-server boundary, which broke the syncing if Guids were primary keys, so I switched to ULID via NUlid and all problems were resolved. It also has the benefit of being sortable, and encoding datetime information inside of it. I don't know where this Guid bug ultimately can be blamed, but this is the kind of mysterious thing that you may end up dealing with given that you are using different compiler toolchains on the different platforms. Mono and .NET are still not perfectly identical, even though they are converging.
Entity Framework migrations support for SQLite is still limited, but improving.
The new Single-Project concept is more trouble than it is worth right now. The old Xamarin.Forms per-platorm project approach worked better. The new single-project style will often trigger a build for all of the platforms when you are only meaning to run or publish a single one. And unit tests can be annoying to set up with the Single-Project approach because the target frameworks are incompatible. I find myself commenting out parts of the CSPROJ frequently to deal with these kinds of issues, and had to add a bunch of conditional restrictions to various tags. These issues may just be growing pains.

Stuff I didn't like:

WinUI3 is still lacking basic and critical features like camera support and a native map control. And it is the only supported Windows target.
Encountered a fair amount of bugs. Most of them have been resolved, or I found workarounds, but new ones pop up as well. Expect some of this. Thankfully, the service releases come out monthly.
It feels like source generators are slowly taking over. It can be implemented really well sometimes, and there are lots of cool ones for regex and enums and such, but I didn't like the way it was done in CommunityToolkit.Mvvm. The magicalness of it is more of a downside than an upside. Also, I have experience with the older approach from PropertyChanged.Fody and friends, and that style seemed nicer. But you can just choose not to use them.
It supports so many fast-moving targets that are ultimately out of the control of the MAUI team, so a lot of things will inevitably break with new releases of Android, iOS, Mac, Tizen, and WinUI. The fact that it targets native controls on each of the platforms contributes to inconsistencies, and drawn controls are still a ways off.
Similarly, the submission processes to the various app stores can be challenging, and ever-evolving, but I eventually got the hang of it. Even things like version strings can be a challenge, and MAUI doesn't try to enforce a default versioning standard that will reliably work in all the stores. But it isn't a unified process. You use the Archive tool for Android and iOS, but use a separate wizard for Windows. Luckily, dotnet publish works as a consistent pipeline-friendly alternative. And EXE support on Windows is here too.
MAUI Shapes cannot be used as an ImageSource, which precludes easily using them in buttons, various libraries, etc.
There is no good free option for a DataGrid. But with a bunch of work I was able to adapt a basic open source library for my needs. I just made about a dozen PRs into that repo, so hopefully you will be able to benefit from my efforts.
I don't particularly like the UseMaui tag in the csproj since it just hides the package version. Useless magic. Luckily, nuget lockfiles can help keep it clear what service release you are on, etc. In addition to all the many other reasons to use lockfiles. Hope nuget turns them on by default sometime soon.