VS2012: How to change a project’s physical location

By jay at September 26, 2012 19:02 Tags: ,

Ce billet est disponible en francais.

Physically moving a project in a Visual Studio solution has always been cumbersome. It’s often needed if you rename your [insert favorite language] project’s folder.

In previous versions of Visual Studio, you would move the project into the new location and either :

  • Remove the project from the solution and add it back using the new location
  • Go the warrior way, and hack around the very user-friendly .sln file format and change all the references

That’s been an annoying situation, but that could be worked around.

But every time, you’d lose your solution wide settings, such as default startup project or build configuration. And if you have many build configuration, I think you understand the pain of restoring all these settings properly.

Fortunately, there’s been a very small change in VS2012 that allows to provide a new location of a project file, if it failed to load because it was not found.


An update to @matthieumezil, Rx and the FileSystemWatcher

By jay at August 26, 2012 20:52 Tags: , , , , , , ,

@MatthieuMEZIL is a fellow MVP and friend of mine, and back in february at the MVP summit we shared our mutual interests with Rx on my side, and Roslyn on his side.

I’ve yet to blog about Roslyn, (even though a blog post is in preparation) but he started using Rx and is a bit blogging about it.

Now, Rx is a tricky beast and there are many ways to do the same thing. I’ve promised Matthieu I’d give him a few tricks on how to improve his code. Now that I do have a bit of time, here it is.


Windows 8, Developers, Hyper-V and the new VHDX format

By jay at July 13, 2012 22:03 Tags:

TL;DR: Windows 8 added support for SSD TRIM commands in its VHDX format, making very easy to boot from a virtual drive on an SSD drive. This allows to never install Windows directly on a physical disk anymore, easing backups, cloning and virtualization. It also allows for very easy migration between different versions of Windows 8.

It's been a very interesting year with Windows 8. We've been fed with two new releases since the Build conference, the Consumer Preview and Release Preview, and now it's the RTM that's coming along in August.

With all these releases to play with, it's a game of install, re-install and co-existence of multiple windows instances on my machine.

I do not like losing to much time staring at my computer while it reinstalls everything from scratch, particularly Visual Studio, and both booting a physical machine from VHD and/or virtualizing it Hyper-V has been very helpful to save time.


C# Async Tips and Tricks Part 2 : Async Void

By jay at July 08, 2012 17:05 Tags: , , , , , , ,

TL;DR: This article discusses the differences between async Task and async void, and how async void methods and async void lambdas, used outside the DispatcherSynchronizationContext, can crash the process if exceptions are not handled.

You can also read the part 3, Tasks and the Synchronization Context.

In the first part of the series, we discussed the behavior of async methods. The second part discusses how async Task and async void methods can differ in behavior, while seemingly being similar.


Authoring Async Methods

Async methods can be authored in three different ways:

async Task MyMethod() { }

which creates a method that can be awaited, but does not return any value,

async Task<T> MyReturningMethod { return default(T); }

which creates a method that can be awaited, and returns a value of the type T,

async void MyFireAndForgetMethod() { }

which is allows for fire and forget methods, and cannot be awaited.

You may be wondering why there are two ways to declare a void returning method. Read on.


C# 5.0 Async Tips and Tricks, Part 1

By jay at June 18, 2012 21:22 Tags: , , ,

Cet article est aussi disponible en francais.

TL;DR: This article is a discussion about how C#5.0 async captures the executing context when running an async method, which allows to easily stay on the UI Thread to access UI elements, but can be problematic when running CPU-bound work. Off of the UI thread, an async method may jump from thread to thread, breaking thread context dependent code along with it.

You can also read : Part 2, Async void 

C# 5.0 has introduced, language-wise, just two of new features (async and caller information) and a gotcha fix (a lambda lifted foreach loop variable scope change).

The biggest addition though, in terms of compiler magic, is the addition async. It’s been covered all over the place, and I will just comment the addition feature by itself, and the impacts it has when using it.

This article is the first of a small series about some C# async tricks and gotchas that I will try to cover to give a bit of insight, and hopefully help developers avoid them.


Improving the Startup Time of Xaml Metro Style Apps with Multicore JIT

By jay at June 11, 2012 05:15 Tags: , , ,

Ce billet est disponible en francais.

TL;DR: Microsoft introduced the Multicore JIT, which allows the recording of JITted methods during the startup of the app. This recording can be packaged in a Metro Style app for faster startup on Multicore CPUs by performing background compilation. Improvements range between 20% to 50%.


Since the beginning of the year, I’ve had the chance to work with some very interesting people at Microsoft, and one of the feature that came out from them was about the use of a new .NET 4.5 feature called Multicore JIT in Metro Style apps.


No Threads for you ! (in metro style apps)

By jay at March 17, 2012 13:06 Tags: , , , , , , ,

Cet article est disponible en francais.

As would say this guy, since you’ve most probably been using threads the wrong way (as Microsoft seems to think), you won’t be able to use the Thread class anymore in Metro Style applications. The class is simply not available anymore, and neither are Timer or ThreadPool.

That may come a shock to you, but this actually makes a lot of sense. But don’t worry, the concept of parallel execution is still there, but it takes the form of Tasks.


Why using Threads is not good for you

Threads are very powerful but there are a lot of terrible gotchas that come with it :

  • Unhandled exceptions in threads handlers, either raised from a Timer, a Thread or ThreadPool thread, lead to the termination of the process
  • Using Abort is quite bad for the process, and should be avoided
  • People tend to use Thread.Sleep to arbitrarily wait for some constant time that will most probably be incorrect, and that will waste CPU resources to manage a thread that does not do anything while it waits,
  • People tend to come up with complex designs to chain operations on threads, which most of the time fail miserably.

There are some more, but these a main scenarios where using Threads fall short.


Windows 8 Event Viewer’s Immersive-Shell and Metro Style apps

By jay at March 16, 2012 20:41 Tags: , , , , , , , ,

TL;DR: This article talks about an app startup error that can happen with Metro Style apps in Windows 8, how the presence of an app.config file can prevent the app from starting and how the Windows event log viewer’s new Immersive-Shell section can help.


The Windows 8 Metro style Xaml/C# application development is an interesting experience.

Since .NET is merely on top of a WinRT and its native structure, you’re left in a bit of a darkness sometimes, when it comes to debugging problems that come from WinRT.

Silverlight and Windows Phone also have their fair share of blind issues of this kind, either by having the application that exits with no apparent reason (when it is in fact a StackOverflow) or because you’ve set two namespaces names with the same content.

You’ve basically left at guessing, particularly on Windows Phone and Silverlight for the desktop, and if you’re lucky enough you’re having a error code that specific enough so that you can narrow your solution to a dozen google can find for you. If you’re not, well you’ve got a E_ERROR. Fail, as they say.

Windows 8 is actually a bit better at that, because of the Event Viewer. There’s a lot of details that appear there, and it’s very informative.


Xaml integration with WinRT and the IXamlMetadataProvider interface

By jay at March 07, 2012 21:04 Tags: , , , , ,

TL;DR: This article talks about the internals of the WinRT/Xaml implementation in Windows 8 and how it deals with databinding, its use of the IXamlMetadataProvider interface, tips & tricks around it, and how to extend the resolver to create dynamic databinding scenarios.


Xaml has been around for a while, and it’s been a big part of Silverlight and WPF. Both frameworks are mostly managed, and use a CLR feature known as Reflection, or type introspection.

This is a very handy feature used by Silverlight/WPF to enable late binding to data types, where strings can be used to find their actual classes counter-parts, either for value converters, UserControls, Data-Binding, etc...


The burden of .NET reflection

It comes with a cost, though. Reflection is a very expensive process, and up until very recently in Silverlight, there was no way to avoid the use of Reflection. The recent addition of the ICustomTypeProvider interface allows for late binding without the use of reflection, which is a big step what I think is the right direction. Having this kind of interface allows for custom types that define pre-computed lists of fields and properties, without having the runtime to load every metadata available for an object, and perform expensive type safety checks.

This burden of the reflection is particularly visible on Windows Phone, where it is suggested to limit the use of DataBinding, which is performed on the UI thread. The Silverlight runtime needs to walk the types metadata to find observable properties so that it can properly perfrom one or two-way bindings, and this is very expensive.

There are ways to work around this without having ICustomTypeProvider, mainly by generating code that does everything the Xaml parser and DataBinding engines do, but it’s mainly experimental, yet it gives great results.


WinRT, native code and the lack of Reflection

In Windows 8, WinRT is pure native code, and now integrates what used to be the WPF/Xaml engine. This new engine can be seen at the cross roads of Silverlight, WPF and Silverlight for Windows Phone. This new iteration takes a bit of every framework, with some tweaks.

These tweaks are mainly related to the fact that WinRT is a native COM based API, that can be used indifferently from C# or C++.

For instance, xml namespaces have changed form and cannot reference assemblies anymore. Declarations that used to look like this :


Now look like this :


Where the using only defines the namespace to be used to find the types specified in the inner xaml.

Additionally, WinRT does not know anything about .NET and the CLR, meaning it cannot do reflection. This means that the Xaml implentation in WinRT, to be compatible with the way we all know Xaml, needs to be able to do some kind of reflection.


Meet the IXamlMetadataProvider interface

To be able to do some kind reflection, the new Metro Style Applications profile generates code based on the types that are used in the Xaml files of the project. It takes the form of a hidden file, named XamlTypeInfo.g.cs.

That file can be found in the “obj” folder under any Metro Style project that contains a Xaml file. To find it, just click on the “Show all files” button at the top of the Solution Explorer file. You may need to compile the project for it to be generated.

In the entry assembly, the file contains a partial class that extends the App class to make it implement the IXamlMetadataProvider interface. WinRT uses this interface to query for the details of types it found while parsing Xaml files.

This type acts as map for every type used in all Xaml files a project, so that WinRT can get a definition it can understand, in the form of IXamlType and IXamlMember instances. This takes the form of a big switch/case construct, that contains string representation of fully qualified types. See this example :

private IXamlType CreateXamlType(string typeName) 
  XamlSystemBaseType xamlType = null; 
  XamlUserType userType;

  switch (typeName) 
    case "Windows.UI.Xaml.Controls.UserControl": 
      xamlType = new XamlSystemBaseType(typeName, typeof(Windows.UI.Xaml.Controls.UserControl)); 

    case "Application1.Common.RichTextColumns": 
      userType = new XamlUserType(this, typeName, typeof(Application1.Common.RichTextColumns), GetXamlTypeByName("Windows.UI.Xaml.Controls.Panel")); 
      userType.Activator = Activate_3_RichTextColumns; 
      userType.AddMemberName("RichTextContent", "Application1.Common.RichTextColumns.RichTextContent"); 
      userType.AddMemberName("ColumnTemplate", "Application1.Common.RichTextColumns.ColumnTemplate"); 
      xamlType = userType; 

  return xamlType; 

It also creates hardcoded methods that can explicitly get or set the value of every properties a DependencyObject, like this :

case "Application1.Common.RichTextColumns.RichTextContent": 
    userType = (XamlUserType)GetXamlTypeByName("Application1.Common.RichTextColumns"); 
    xamlMember = new XamlMember(this, "RichTextContent", "Windows.UI.Xaml.Controls.RichTextBlock"); 
    xamlMember.Getter = get_1_RichTextColumns_RichTextContent; 
    xamlMember.Setter = set_1_RichTextColumns_RichTextContent; 

Note that if you want to step into this code without the debugger ignoring you, you need to disable the “Just my code” feature in the debugger options.

Also, in case you wonder, the Code Generator scans for all referenced assemblies for implementations of the IXamlMetadataProvider interface, and will generate code that will query these providers to find Xaml type definitions.


Code Generation is good for you

Now, this code generation approach is very interesting for some reasons.

The first and foremost is performance, because the runtime does not need to use reflection to determine what can be computed at runtime. This is a enormous performance gain, and this will be beneficial for the perceived performance as the runtime will not waste precious CPU cycles to compute data that can be determined at compile time.

More generally, in my projects, I've been using this approach of generating as much code as possible, to avoid using reflection and waste time and battery on something that can be only done once and for all.

The second reason is extensibility, as this IXamlMetadataProvider can be extended to add user-provided types that are not based on DependencyObject. This is an other good impact on performance.


Adding custom IXamlMetadataProvider

It is possible to extend the lookup behavior for standard types that are not dependency objects. This opens the same range of scenarios that ICustomTypeProvider provides.

All that is needed is to implement the IXamlMetadataProvider interface somewhere in an assembly, and the code generator used for XamlTypeInfo.g.cs will pick those up and add them in the Xaml type resolution chain. Note that for some unknown reason, it does not work in the main assembly but only for referenced assemblies.

Every time the databinding engine will need to get the value behind a databinding expression, it will call the IXamlMetadataProvider.GetXamlType method to get the definition of that type, then get the databound property value.

A very good feature, if you ask me.


The case of hidden DependencyObject

By hidden dependency properties, I’m talking about DependencyObject types that are not directly referenced in Xaml files. This can be pretty useful for complex controls that generate convention based databinding, such as the SemanticZoom control, that provides a implicit “Key” property to perform the Zoomed out view.

Since this XamlTypeInfo.g.cs code is generated from all known Xaml files, this means that these hidden DependencyObject types that do not have code generated for them. This forces the CLR to intercept these failed requests and fallback on actual .NET reflection based property searching for databinding, which is not good for performance.

This fallback behavior was not implemented in the Developer Preview, and the binding would just fail with a NullReferenceException without any specific reason given to the developer.


The case of Xaml files located in another assembly

If your architecting a bit your solution, you’re probably using MVVM or a similar pattern, and you’re probably putting your views in another assembly.

If you do that, this means that there will not be any xaml file in your main assembly (aside from the App.xaml file), leading to an empty XamlTypeInfo.g.cs file. This will make any type resolution requested by WinRT fail, and your application will mostly likely not run.

In this case, all you need to do is create a dummy Xaml file that will force the generation of the XamlTypeInfo.g.cs, and basically make your layer separation work.


Until next time, happy WinRT'ing !

Switching a Windows 8 Consumer Preview from a VHD to Hyper-V

By jay at March 04, 2012 13:39 Tags: , ,

Now that Windows 8 Consumer Preview (CP) is out the doors, I'll start publishing a series of articles about Windows 8 development in various areas, but primarily focused on development.

I'll start today with some tips and tricks that allow to run Windows 8 natively from a VHD, but also run that same VHD from Hyper-V, within Windows 8 Consumer Preview.

The common scenario is simple, you want to try out stuff that worked in the Developer Preview (DP) inside Win8 CP, or run a two instances of the Win8 CP for testing purposes. Chances are you installed the DP on a VHD, from the excellent blog post from Scott Hanselman.

A few things about Hyper-V

Hyper-V’s been here for a while on the Server side, but chances are you never looked at it. Hyper-V will most likely completely replace Virtual PC, as it now supports 64 Bits virtual machines and the very useful dynamic memory feature. Dynamic memory basically add or removes physical memory assigned to the virtual machines depending on the actual demand. This allows to have higher virtual machine density on servers, but on client machines this is also pretty useful because you may not have 32GB of ram, and still want to use it for your primary OS.

This is why this tutorial suggests to have a machine starting with 512MB of RAM, so that it can grow to the appropriate amount, and not arbitrarily reserve 2 or 4GB of ram, just in case.


Running the VHD from Hyper-V

So now that Hyper-V is now included natively in Windows 8, and even though the final SKU in which it will be included is unknown, we can use it from the CP.

If you’re like me, you may have installed the CP directly on a SSD to make it pretty darn fast. Now, here’s how you install Hyper-V :

    1. Open the start menu, type “Feature” and open “Turn Windows Features on and off
    2. Select “Hyper-V” and OK. Reboot. (If the Hyper-V infrastructure is off, then either your CPU does not support hardware virtualization, or it is disabled in your bios)
    3. Launch the “Hyper-V Manager
    4. In the right hand side panel, select “Virtual Switch Manager
    5. Click on “Create a Virtual Switch
    6. Set a relevant network or network adapter name
    7. Select your network card, could be either a wireless or wired network card, then OK.
    8. In the right hand side panel, select “New” and “Virtual Machine
    9. Give it 512MB of RAM and check the “Dynamic Memory” box, then next
    10. Select the virtual network switch you previously created
    11. Select “Use an existing Virtual Hard Disk” and select the Windows 8 DP VHD or VHDX file
    12. Click next twice.
    13. Now in the list of machines in the Hyper-V Manager, right click on your machine and start.


Chances are that your machine will not boot and ask you to replace the disk with a bootable one.


Here’s how to fix that :

    1. Double click on the virtual machine line to open a Display Console
    2. In the Media menu, select “Insert Disk” and select the Windows 8 CP iso file
    3. Reboot the virtual machine using the reset button in the toolbar
    4. Once on the Windows 8 install welcome screen, type Shift+F10, this will show a command line window
    5. Run Diskpart
    6. Type “list volume
    7. Type “select volume 1
    8. Type “list partition” and find the “System Boot” partition or the primary partition
    9. Type “select partition 1” (replace the 1 with the partition listed at the previous step)
    10. Type “active
    11. Then type “exit
    12. Back at the command line, you should be on the X: drive
    13. Type the following “bcdboot c:\windows /s c:” (you may need to replace the second “c:” with the drive that is the System Boot, when installing on a physical machine)
    14. Once done, close the installer window to exit the installation and reboot
    15. You’re done !


Note that this section can be used to register pre-installed Windows 7 or 8 VHD to an existing Windows 7 or 8 physical machine. But in this case, you may need to find the actual hidden boot partition that the Windows Installation creates automatically. You’ll find that partition with the “list partition” command.

Happy Windows 8 CP’ing !

About me

My name is Jerome Laban, I am a Software Architect, C# MVP and .NET enthustiast from Montréal, QC. You will find my blog on this site, where I'm adding my thoughts on current events, or the things I'm working on, such as the Remote Control for Windows Phone.