cmb-web.co.uk

Could not load file or assembly or one of its dependencies. An attempt was made to load a program with an incorrect format.

When running a web application on Windows 64-bit you may receive the following the error message:

'Could not load file or assembly xxxxxx or one of its dependencies. An attempt was made to load a program with an incorrect format.'

The reason for this is the Appliction Pool in IIS is not allowing 32-bit application to run.

You can fix this in IIS Manager by selecting the Application Pool and opening the Advanced Settings dialogue, link on the right of the IIS Manager:

 You can then toggle the option for 32-bit applications:

Formatting text directly in XAML

You can format text strings directly in the XAML code of a WPF application.

For example, you can use standard .NET formatting such as currency and date:

<TextBlock Text="{Binding Amount, StringFormat={}{0:C}}"/>
<TextBlock Text="{Binding Date, StringFormat={}{0:dd/MM/yyyy}}"/>

The empty {} after the StringFormat= escapes the text before the formatting string.

You can add text in front of the formatting string too, e.g.
StringFormat=Amount: {0:C}
in which case you don’t need to escape the string with the {}.

More advanced formatting options can be acheived using a multi-binding, for example:

<TextBlock>
  <TextBlock.Text>
    <MultiBinding StringFormat="Date {0} Time {1}">
      <Binding Path="DueDate" />
      <Binding Path="DueTime" />
    </MultiBinding>
  </TextBlock.Text>
</TextBlock>

Unit testing internal methods

When unit testing applications you write tests for the exposed public methods.  Philosophically this is correct as you need to test the functionality exposed by your class to the consuming application, and any private or internal functions that use functionality that also needs testing should be discrete from this class. This functionality should be ‘injected’ into the class using some form of unit-testable framework; such as dependency injection using interfaces, allowing them to be tested separately.

However, there are occasions when you want to hide methods from external consumers for good reason, but still need to unit test them.  For example, producing a library to distribute to third-parties.

To do this with .NET you can mark the assembly with InternalsVisibleTo and specifiy the public key of the project allowed to view your internals.

For example, I have a project called MyNewProject and a project containing units tests for this called MyNewProjectTests, I can add the following code to the assembly.cs file in MyNewProject with the public key of the test project:

[assembly: InternalsVisibleTo("MyNewProject, PublicKey=0024...")]

Note, I’ve not included the entire public key here.

Now the internal methods are visible to the test project we have one more task. The unit test frameworks Rhino Mocks and Moq use a proxy class called DynamicProxyGenAssembly2 to represent your object when testing. We therefore need to expose the internals to this class also. We do this in the same way with another entry in the assembly.cs file:

[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2, PublicKey=0024")]