Project references to multi-targeted projects

During the process of moving Caliburn.Micro to .NET Standard and the new multi-targeting project format I’ve encountered a number of issues in the tooling around intellisense and builds. This isn’t surprising given the relative newness of this approach, but I thought I’d share some of the issues over the next few weeks to help you out.

Techniques in creating great cross platform apps

My NDC Sydney 2017 talk “Techniques in creating great cross platform apps” is now available on Youtube.

Auto subscription for Event Aggregator

In many of my talks I’ve recommended using a messenger style class. These help to reduce coupling between view models when decomposing from a single “view model per screen” to a tree of view models. This intermediary class is called by a few different names, Messenger in Xamarin.Forms, Mediator in some others and in Caliburn.Micro, Event Aggregator.

Command conventions in Caliburn.Micro

If you’ve ever spoken to me personally at a convention or a user group (I’ll be at NDC Sydney if next week, comes say hello) then you may have heard me talk about disliking command objects in MVVM.

Controlling the output path in Visual Studio 2017

One thing you’ll notice if you’re experimenting with the new csproj project structure used in .NET Standard is the difference in Output Path. Typically the default output path for a new full .NET Framework assembly would be bin\$(Configuration)\ resulting in bin\Debug\ and \bin\Release\. In .NET Standard projects by default this output path isn’t defined in the csproj but defaults to much the same except that the Target Framework is also appended to the path. So for example if I created a new project targeting .NET Standard 1.4 like follows: