Fix for WPF images and shared projects

Shared projects are crazy useful when developing for multiple platforms. Some people choose Portable Class Libraries (PCL), but if you need platform specific code, shared projects is the way to go.


Too long to read? Check out the animated gif on how to fix the issue.


The problem

Recently I was porting Orchestra and all Orc packages to support NET 4.5 besides NET 4.0. To do this, I introduce a shared project and create a NET40 and NET45 project that references the shared project. An example can be seen in the image below:


This works great because I only have to add files to the shared project, and the files will be compiled for both NET40 and NET45.

However, after converting my projects to shared projects, the WPF resources no longer worked. After digging into this issue, I found out that they don’t work very well with shared projects. As you can see in the image taking with .NET reflector below, it does not embed the resources correctly.

By default it uses the Content build action. Changing that to Resource manually via the properties window doesn’t work:


The next thing I tried was manually changing the item inside projitems (the shared project file).

This excludes the file from the projitems (no longer supported), but it does embed it as resource. Unfortunately the path is lost:


The solution

The solution is to use linked files for this. The following steps should be taken:

  1. Exclude the resources from the shared project (don’t delete them, just exclude them)
  2. Enable the Show all files toggle in the solution explorer
  3. Hold the Alt key and drag the resources to each project.
  4. Ensure that the build action of the resources is Resource

You can also check out the animated gif at the beginning of this post for a visual presentation of the fix.

Issue on MS Connect

Want this fixed? Please vote here on Microsoft Connect:

Easily measure performance of methods in .NET with MethodTimer

When developing applications in .NET, it’s wise to measure performance. While there are tools like performance counters available, they are simply too complex to set up and I hardly see anyone use them. The most used feature is the code below:

The downside of this is that it makes your code ugly to read (code waste) and you need to handle every return statement in the method to stop the stopwatch.

MethodTimer to the rescue

Simon Cropp has written a very nice weaver for Fody called MethodTimer that allows you to inject the stopwatch code above into any method by simply decorating it with an attribute.

Then it will be weaved into this:

Note that the code will take care of all return statements in the method, so all will be handled. Installing is super easy, just install the MethodTimer.Fody NuGet package.

Full support for async methods

Regular methods are easy, but what about async methods? They use state machines and there can be a lot of situations where the method can be returned. Starting with v1.15, async methods are fully supported. For example, the code below has a lot of return statements combined with await:

As you can see this method contains several return statements (before and after await statements), but will handle all situations. Measuring the duration of an (async) method has never been this easy!

GitLink 2.0 – making .NET open source accessible!

I am very proud to announce GitLink 2.0, the tool that will make open source code more accessible! This release is a major release introducing many new features and improvements. One of the improvements is support for more providers than GitHub, so I have renamed GitHubLink to GitLink.

First things first: this release wouldn’t be what it is now without the help of my friend Peter Kiers who saw the potential and lifted the product to a higher level.

Supporting more providers

As soon as we released GitHubLink, it went popular among open-source developers on GitHub. However, some people requested support for other providers such as BitBucket. This gave us the idea to create a generic approach where we could automatically detect the provider and find the right information. As of now, the following providers are supported:

  • BitBucket
  • GitHub

Are you interested in supporting a provider? Help us out with a pull request, it’s really easy!

Supporting more project types

GitHubLink supported both C# and Visual Basic projects. Starting with GitLink 2.0, all project types that Visual Studio can load are supported such as C++ and F#.

Improved performance

One of the downsides of GitHubLink was that it downloaded the whole repository in order to retrieve the latest commit SHA. GitLink 2.0 automatically determines whether there is a local .git folder. If so, it won’t even go to the official url to retrieve the latest commit but will use the local repository. If there is no local .git file, GitLink 2.0 will only fetch the latest commit and will no longer download any files from the remote repository resulting in much better performance.

Introducing PDB file verifications

Starting with GitLink 2.0, all PDB files are now verified before being updated. This means that GitLink checks whether all files inside the PDB file are actually available and contain the right hash.

Removing the F# and SourceLink dependencies

GitHubLink heavily relied on SourceLink, an F# implementation to update the PDB files to allow a custom source server. It was however hard to combine the world of F# and C# and we always had to ship the 2 assemblies with GitHubLink. In GitLink 2.0, the dependencies are no longer required and all logic is translated to C#. This improvement saves about 500 kb on the final GitLink assembly size.

How to get GitLink

You can download GitLink 2.0 here. It is also available on NuGet and Chocolatey. Note that if you have used GitHubLink in the past, we will be keeping compatibility packages for that until version 3.0. It’s best to update to GitLink as soon as possible.