Reasoning about a program’s behavior is extremely tricky in the best of circumstances. When you throw in asynchronicity, it is the absolute worst. It’s like your code is trapped in a convoluted time travel movie. You want to perform some operation, but that requires stepping into a time portal and coming out at some indeterminate future date. Who knows what has changed since you’ve been gone? Add a few more asynchronous operations, and your code very quickly becomes a tangled mess of wibbly-wobbly, timey-wimey stuff. Read more on Time and Relative Distance in Source (Code)…
After working on .NET applications for the past six years, I recently spent a few months using Ember.js and AngularJS. Both originally supported organizing files in a project by type: separate top-level directories for models, controllers, views, etc. But this has changed over the past few years to prefer organizing by feature area—Ember with pods Angular with modules.
C# 6 recently added support for exception filters, which enable a few helpful scenarios. In this post, I’ll demonstrate how they can be used to improve debugging and crash dump analysis. Read more on Improving Analysis with C# 6 Exception Filters…
Event Tracing for Windows (ETW) has been around for a while now, but many (if not most) developers have never used it. I’ve primarily used it for performance tracing, and it’s flexible enough to be used for logging regular application events as well. Read more on Performance Analysis with ETW: Event Tracing for Windows…
I’ve recently been working on a .NET web application. We are mainly a Mac-based development shop at Atomic, so I’m working on this application in a virtual machine. My weapons of choice are VMWare Fusion and Visual Studio 2012 (not much of a choice), but that is neither here nor there.
Our application uses the Helvetica Neue font family. This font comes pre-packaged with Mac, but isn’t included in Windows. So, in order to effectively design and preview our application, I needed to make it available from my host machine. Here is how I did that.
Recently, I’ve been playing with the F# programming language in my free time. One barrier that I ran into was the fact that I don’t have a Windows machine, meaning I had to use the Mono runtime on my Macbook. This presented some challenges that I had to work through.
So, why was I playing with F# in the first place? I had been looking for a language to fix some frustrations that I had with my current toolset:
- Lack of static typing that isn’t painfully repetitive (Java)
- First class support for common functional programming idioms – e.g. immutable by default, option types, pattern matching, etc. (All of the above)
I also wanted to take the opportunity to get some experience with the Microsoft/.NET ecosystem. Since the Microsoft stack is incredibly popular at many companies, including some of our clients, it seemed like a solid bit of knowledge to have. Also, I was excited about the possibility of using the Xamarin stack to create mobile apps with F#. Read more on Running F# Using Mono and Unix…
I ran into a situation the other day where I had to turn on/off the visibility of a text run in WPF, and I discovered that text runs do not have a visibility property.
Whenever I run into a situation where I need to add functionality to a control, I always turn to attached properties as my go-to tool. Here is a quick and easy way to add the visibility functionality using an attached property.
Writing C#.Net async code can be a bit of a challenge, and writing tests around the code can frequently cause much pain and agony. In fact, conventional wisdom around the Internet seems to be that writing async tests is hard enough that it’s okay to avoid it.
Writing tests has enough benefits (most notably that it improves the quality of the code under test, and it allows us to refactor and add future features with less risk) that it’s worth taking the time to experiment with testing strategies to find something that works for your project. Read more on Testing C#.Net Async Code…
So, you just wrote a great new .NET app and you’re ready to release it into the world. Great! But… how do you ensure your awesome ideas and intellectual property won’t be ripped off? After all, a person with malice in her heart could simply decompile your work and see the code laid bare, right? In this post, I’ll consider what obfuscation can do for us, what .NET obfuscation tools are available, and what the drawbacks are of using them.
How Obfuscation Works
Obfuscation is a way of modifying a program to make it harder to reverse-engineer. Usually that means attempting to defeat a decompiler, or at least make the decompiled output useless to a human reader. Most obfuscation tools available for .NET are commercial (a list can be found here), though there are some free alternatives available. Most obfuscation tools can apply some combination of the following transforms: Read more on Obfuscating a .NET Program: Worthwhile?…
Data binding establishes a connection between the application UI and business logic. When it works, it’s a wonderful thing. You no longer have to write code that updates your UI or pass values down to your business logic. When it breaks, it can be frustrating to figure out what went wrong. In this post, I will give you some tips on how you can debug your data bindings in WPF.
1. Add Tracing to the Output Window
Here is a sample
TextBlock that has a missing data context. In this situation, you will not get any errors in the Visual Studio output window.