*N Async, the next generation
Aug 10, 2016
In the previous installment, I discussed how to use iterators (yield return
) to create async methods. This time, we’re about to do almost the opposite – use async methods to implement async iterators.
In the previous installment, I discussed how to use iterators (yield return
) to create async methods. This time, we’re about to do almost the opposite – use async methods to implement async iterators.
Update: Just use IgnoresAccessChecksToGenerator
TL;DR Just grab the .snk from the Roslyn repo, name your bridge assembly to something from the InternalsVisibleTo (e.g. Roslyn.Hosting.Diagnostics), sign it with the key, and you can access all the internals at compile time, with IntelliSense!
I have been waiting for while for the Roslyn team to expose the completion and signature help services so I could use them in RoslynPad without having to compile my own version. This was expected to be included in Update 1 but got pushed back.
If you’re using async/await a lot (a given nowadays), you may have noticed stack traces are not very readable. For example, this is a 3 async method chain’s stack:
Update
With Service Fabric SDK v2 this became much simpler. Check out this SO answer of mine for details.
Windows PerfMon is an invaluable tool, but it’s UI remained the same for years, stuck somewhere in the 1990’s. This is my attempt at “reimagining” it.
When awaiting tasks in C#, you have the option to configure how the continuation behaves - whether it uses the Synchronization Context or not.
One of my clients recently needed to hook up a USB barcode reader to their app. Input from the reader needed to be redirected and handled by a special service, and ignored by the rest of the application. WPF has a property named Device in its KeyEventArgs class, but unfortunately it turns out that it uses the same instance for all input devices hooked up to the PC.
One of the goals in concurrent programming is to reduce contention. Contention is created when two (or more) threads contend for a shared resource. The performance of synchronization mechanisms can vary considerably between contended and uncontended cases.
WPF enables you to develop great looking applications very fast. But sometimes with this rapid approach one can overlook an important aspect - performance. It’s very common for developers to look into UI performance last, especially in LOB applications, but performance can have a significant effect on how professional your application is perceived to be.
You’ve all read about the asynchrony promise of C# 5 (if you haven’t, I highly recommend reading Eric Lippert’s series about the subject or this post won’t make much sense). I think it’s a great step forward, and it would make asynchronous programming all a lot easier.
A few months ago I’ve decided to write a Prism tutorial by building a WPF UI for the .NET Reflector.
I’ve prepared a class diagram for my students of main WPF controls, divided into Decorators, Panels, Content Controls and Items Controls. The diagram was generated using the new Visual Studio 2010 Visualization and Modeling Tools (with a bit of manual cleanup).
One of the new features in .NET 4.0 is Side-By-Side In-Process (SxS InProc) execution of older CLRs (e.g. .NET 2.0). Previously, SxS was supported only in different processes. If you look it up, you’ll find these two (yet to be updated) blog posts by the CLR team, an MSDN Magazine article as well as one in the MSDN Library. You can get a good review of supported scenarios and some code, but what they all sorely lack is a working sample. (Update: There’s a new detailed article from the CLR team.)
I always prefer simpler solutions. The solution I proposed on my previous post was not that simple, and was not complete. It may still be useful for other stuff, but for the purpose of preserving ClearType while using DWM, I just have to admit it has too many issues.
WPF has ClearType issues. Hopefully some of them will be solved in the upcoming .NET 4.0. Meanwhile, however, I have concocted a nifty solution to one of the scenarios – placing stuff on the Aero Glass DWM frame.
One of the most popular posts in this blog is the one explaining how to override the system theme and get the Vista look on non-Vista systems. This is possible because WPF ships with the theme files for all operation systems (well, all Microsoft OSs that WPF works on, i.e. XP, XP Media Center and Vista) and due to the fact that WPF doesn’t really use the system resources to get the OS theme, but rather relies on a private implementation of them that resides in the PresentationFramework.{Classic, Luna, Royale, Aero} assemblies.
I’ve released a new version of WPF Contrib (October 2008, although it’s released in November. I changed the release name a few times, so I decided to leave it like that. I’m only late by a few days…
First of all, you didn’t miss part one. Just thought it was a funny reference.
All code in this blog (unless noted otherwise) is released under the MIT license.
I’ve been using InteropBitmap in my GdiTextBlock. The control creates a new GDI+ Bitmap every measure pass, which it then converts to a WPF BitmapSource using the Imaging.CreateBitmapSourceFromHBitmap() method (this method returns an InteropBitmap).
In a previous post I mentioned the new Zune 3.0 visualizations. I really liked them, so I decided to try and create them using WPF’s new (3.5 SP1) Effects.
It’s been a while since I’ve done anything with GDI+ (i.e. System.Drawing). System.Windows (i.e. WPF) is so much more powerful.
I’ve been quiet for a while. Working a lot, and also burning the midnight oil, trying to bring life into this project I call… the WPF Contrib.
You can do really neat things with Bitmap Effects in WPF. Shadow, Bevel, Outer Glow can all have a great impact on how your application looks. But you should be aware that they don’t come cheap. They are rendered in software, which yields very poor performance. Also, ClearType is turned off on elements that have them applied, so your text becomes blurry.
WPF has a separate ClearType rendering system, which is better than GDI’s (mostly because it also does y-direction antialiasing; read more here and in the WPF Text Blog.)
WPF comes with a few theme assemblies, one for each Windows theme (Luna, Royale and Aero and the fallback theme, Classic.) Usually the theme is loaded according to your current system theme, but if you want to create a consistent look for your application, you may want to force-load a specific one.
It’s a fairly uncommon scenario to want to animate a type that’s not already built into WPF. But when you do, it takes quite a lot of work, mostly hacking it with Reflector to explore this undocumented venue.