True to the motto “oldie but a goldie” I have a simple solution for a typical problem arising in a modular WPF application: If you have a setup where your Resource Dictionary is located in another project, the designer is very likely to be ignorant about its contents. Merging the dictionary into your App.xaml Resource node will handle the runtime situation correctly, but VS is likely to fail in showing the resource at design time as desired.
TL;DR: the template on GitHub. Some time ago I released a simple OWIN-based ASP.NET Web API template that was meant as a quick and easy starting point for developing SPA applications. The tempalte was released as Visual Studio template. A reader asked my if I would provide an update for Visual Studio 2015 (RC). The answer is a clear yes and no. With VS2015 and the new ASP.NET version on the doorstep it wouldn’t make sense to release an updated version of the simple SPA starter template based on OWIN components.
Together with my colleague Ricardo, I put together a set of Roslyn code diagnostics that enforce some best practices when dealing with async code in C#/.NET. To make use of them, you need the latest CTP of Visual Studio 2015. The source code for the diagnostics and fixes is over at GitHub: https://github.com/olohmann/AsyncAwaitAnalyzer You can pull in a NuGet Package to use them directly in a VS2015 project: Install-Package AsyncAwaitAnalyzer -Pre When things have stablized (i.
Update 2015-10-22: Since I received a couple of requests to maintain this template for Visual Studio 2015, I’ve published an update to the extension gallery. The source code is now on GitHub Update 2015-05-12: Already on Visual Studio 2015 or Visual Studio Code? Check out my blog post on an updated version of this template for VS2015 that uses Yeoman and ASP.NET vNext. You want to develop a simple Single Page Application (SPA) with ASP.
I am writing a lot of sample code and usually I have to fill my samples with some random data. A typical entity in most scenarios is a person or a contact. Since I am tired with putting in some static names here and there and copy and paste them between samples, I wrote a little library that generates random contact sequences. It takes the most common first and last names of the US and generates random combinations of them.
In my last blog post I described the general idea of using Rx to handle typical query situation with all their pitfalls. Let us take the idea one step further in developing a WPF control that directly makes use of Rx. The source code excerpts in this post are simplified and I tried to focus just on the important aspects. The final code looks a bit different and can be downloaded from GitHub.
In this blog post we will focus on the Rx aspects of developing an autocomplete feature. In the next blog post we are going to work on a re-usable WPF auto-complete TextBox that uses Rx under the covers. Some months ago I delivered a Workshop on Reactive Extensions (Rx). If you never heard about Rx, you should read this first. One little exercise I did with the workshop attendees was to develop a basic auto-complete TextBox that would query an online dictionary service and the results would be shown in the UI.
Not exactly a brand new topic in the area of WPF development are attached behaviors. However, in my opinion, they should be used more often - that’s why I decided to write about it. Let us start from the beginning. What is an attached behavior? From a high level perspective attached behaviors allow you to write a snippet of code that can add additional features to a WPF control without doing something that drastic as inheriting from an existing control class.