Specifying an Assembly's Location with MEF

Today I came across a problem with dynamically loading assemblies using MEF, when the assembly being loaded has a dependency on yet another assembly. In my case this was SignalR.

Assembly Host (.exe) -> Assembly (.dll) -> SignalR (.dll)

I was typically seeing the error:
Could not load file or assembly 'AssemblyNameHere, PublicKeyToken=xxxxxxxxxxxxxxxxx' or one of its dependencies. The system cannot find the file specified.

The reason for this is because the CLR is looking for the dependency in the directory in which the assembly host is running, and not the location of the assembly MEF loaded in.

The way around this is in this MSDN article. By using the probing tag in the app.config, you can specify the directory to look for dependencies. The caveat with using probing is you can only specify sub-directories of the assembly host, so if you want to use an absolute path to another place on the disk then probing isn't the solution, but I'd argue whether you needed it in another place anyway.

The config change required should look something like this:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="Modules\"/>
    </assemblyBinding>
  </runtime>
</configuration>

Read More

Dragging a ListView control in a fullscreen WPF touch app causes the whole window to shift

I recently had a bug with the ListView control in WPF where I had a ContentControl using a ScrollViewer with the ItemsPresenter inside of it. When using touch, and navigating through the items, the whole window would shift when you reach the end of the list, which then allowed the user to access the underlying Windows shell.

The cause of this is due to a potential bug in the ScrollViewer control, where the UIElement.ManipulationBoundaryFeedback event is fired, and is not handled by the ListView. As this is a routed event, it continues up the chain and eventually reaches the Window control, which then handles the event and results in an animation of the entire window.

MSDN states:
The ManipulationBoundaryFeedback event enables applications or components to provide visual feedback when an object hits a boundary. For example, the Window class handles the ManipulationBoundaryFeedback event to cause the window to slightly move when its edge is encountered.

The fix (or hack) for this, is to hook in to the event and handle the event, so that it does not bubble up to the Window control.

Read More