If you’re still stuck on .NET 2.0, 3.0, or 3.5 for any reason and don’t have access to the .CopyTo method for System.IO.Stream objects, the Stream.CopyTo extension method, available as a small NuGet package will make manually allocating buffers and other boilerplate associated with copying a buffer from one stream to another a thing of the past.
Just a quick heads-up for all our readers: our recently released RunInBash utility – which makes mixing-and-matching PowerShell/Windows/CMD commands with WSL/Linux/Ubuntu commands under Windows 10 as easy as prefixing WSL commands with $ to execute them from within a command prompt or PowerShell terminal – is now available under Chocolatey.
Continuing our promise to open source parts of our libraries and applications where possible, we’ve just released PrettySize, a C# and .NET library for representing file sizes in a human-readable (pretty) format. PrettySize is available for free (MIT-licensed) on GitHub and via NuGet for those that are interested, and forks, contributions, and pull-requests are actively encouraged.1
One of the best benefits of open-sourcing code is that it requires you to take a critical eye to what your code does and how it’s structured. Haphazard code interspersed throughout a dozen different files is cleaned up and re-organized in a way that can only bring benefits all around, from performance to ease-of-use, security, and future maintenance.
If anyone wants to try their hand at implementing IFormattable, consider this an open invitation. It’s not a functionality we ever needed, but some might find it useful. ↩
1Password and LastPass are probably the two best known names in the password storage business, both having been around from 2006 and 2008, respectively. Back in 2008, the internet was a very different place than it is today, especially when it comes to security. Since then, a lot has changed and the world has (hopefully) become a more security-conscious place – and security experts have come to a consensus on a lot of practices and approaches when it comes to encryption and the proper handling of sensitive data.
Both of these password managers are heavily vetted and constantly under scrutiny from security researchers, crackers, state security agencies, white hat hackers, and more with open bug bounty programs [1] [2] (though some considerably more generous than others), and are probably “safe” choices for the average computer user.. to an extent.
One of the biggest improvements to C# and the .NET ecosystem in recent years has been the introduction of the async/await programming paradigm and the improvements it brings to both performance (no need to create thousands of threads if they spend most of their time blocking on IO) and productivity (no need to muck around with synchronization primitives or marshal exceptions between threads). While it takes a bit of getting used to, once you’ve gone async/await, you (literally) can’t go back.
We are proud to present the latest addition to our open source portfolio, the Unicode.net library! We’ve extracted a number of encoding- and emoji-related namespaces and functions from a few of our projects going back many years and split them off to create Unicode.net: an open source library that can be used to aid in the safe processing and manipulation of (possibly) internationalized strings and non-ASCII characters (and then some).
Unicode.net is designed from the ground-up as a modern approach to text processing and text encoding, with only support for the most popular Unicode encodings: UTF-8, UTF-16, and UTF-32. Additionally, Unicode.net is designed to complement .NET’s existing (albeit extremely limited) Unicode support, instead of supplanting it, which primarily translates to embracing rather than shunning the System.String type wherever possible. Unlike many other text-processing libraries, Unicode.net does not want you to stop using the system types for string representation and to switch over to custom datatypes 😁.
This post is chiefly directed at .NET developers and others involved in the various stages of .NET deployment, in particular, anyone that’s been keeping tabs on the situation with the new cross-platform, open-source .NET Core initiative or .NET Standard, which came about as Microsoft’s response to the increased fragmentation of the .NET Platform as a result of the myriad of different deployment targets now available. If you’re not into that kind of stuff, feel free to skip this post, or read on and we’ll try to explain things sufficiently as we go through.
When a new Microsoft, with Satya Nadella at the helm, first open sourced the .NET Platform on November 12, 2014 it became clear that they fully intended to put everything they had into the initiative and that great things and big changes were coming to the .NET Framework and its languages. But what it also signaled was the inevitable beginning of a new level of fragmentation for the Framework, which had thus far – by and large – resisted any major fragmentation for the past 12 years of its existence.1 But taking a framework that was cobbled together from parts old and new, built atop of WIN32, GDI, and various Windows-specific anachronisms meant that porting the .NET Framework as-is to other platforms was nigh-impossible — and that major changes would have to be made to support this gargantuan effort.
There are notable exceptions to this, namely the .NET Micro Framework, the .NET Compact Framework, and Mono; however, these “members” of the .NET ecosystem – one not even by Microsoft – were never considered to be first-class .NET Targets within or without Microsoft. ↩
We’ve raved about Microsoft’s latest take on a Linux subsystem for Windows, this time in the form of the oddly-dubbed “Bash on Ubuntu on Windows” Windows Subsystem for Linux — herein and forever after referred to only as WSL for the sake of our collective sanity — but as awesome as being able to type bash in a command prompt to get access to holy posix goodiness, we think we can do better. Meet $.
$, formally known as RunInBash, is a simple command line helper utility that simply runs whatever follows it under WSL rather than in the current (Windows) terminal. Here’s a picture to illustrate (click to expand):
Hello international users of EWS! We’re really happy to announce the immediate availability of Easy Window Switcher 1.1.0, which brings support for internationalized keyboards to EWS users worldwide!
For those that haven’t been keeping in touch, Easy Window Switcher is a nifty, tiny utility that boosts your productivity by adding the ability to “alt-tab” between windows of the same application only, with the keyboard combination alt` (on US keyboards), a shortcut that should be intimately familiar to anyone that’s used OS X for any length of time.
We’ve just released the inevitable bugfix build for any product launch with Easy Window Switcher 1.0.1, which adds the ability to cycle between maximized windows. Hat-tip to Chris Bollman for reporting this bug.
Upgrading EWS is very straight-forward, as soon as you download and run the new version of EWS, you’ll see a dialog like the following: