An issue appeared today for a co-worker, who was getting failing unit tests on one of our components, when the tests were being run from the CodeRush Test Runner. By the way, have I mentioned my love for CodeRush + Refactor? No? Well I do, to the point where I have a work license as well as a personal, paid for out of my own pocket, license! Unfortunately, he was getting an error whenever he ran the tests against the library, which we know has been working without issue for years. Not only that, but when he checked the build history on our build box, there was no report of failing tests. That reminds me, you ARE running your unit test suite in your Continuous Integration environment, right? Right?
He then mentioned the error he was getting, which is a BadImageFormatException getting thrown. That immediately connected two dots in my head, and I verified my suspicions. I was right, as it turns out, our image processing library is compiled against a .Net wrapper against a platform specific DLL targeting the x64 platform. It turns out, his CodeRush test runner was running in 32 bit mode. The fix was a simple one, where he simply had to tell CodeRush to run in x64 mode if the target platform was AnyCPU. The option is fairly obvious, if you know where to look.
In order to enable it, bring up the CodeRush options (DevExpress menu –> Options or Ctrl+Alt+Shift+O for the keyboard inclined), expand the "Unit Testing" option folder on the left, and select the "Test Runner" sub-item. In the main window, about half way down, you will see a checkbox marked as "Execute in x64 mode if active configuration is AnyCPU". Check that, click Ok, and you’re set!
It is important to note that the only time this will cause an issue, if you have a library that is explicitly targeting a specific platform. If all of your libraries are targeting AnyCPU, you will not run into a problem, though you probably want to run your tests to where you are targeting both platforms, in case you notice any discrepancies, run into overflows, type incompatibilities, etc. In our case, we have an C++ image processing library that was compiled and linked to target the x64 platform, and as such, will only run in 64 bit mode.
Here’s a quick little handy shortcut for Agile Web Solutions’ 1Password product on the Mac.
In the past, when I needed to get information about a credit card or a password for an account I have stored in 1Password, I would take the long route of either editing the item, selecting the field, then either read or copy/paste the value, or simply use the “Copy” option found when hovering your mouse over the secret field.
However, I recently accidentally ran into the following trick, should you need to see the information that is masked, when running the full application (not the browser plugins), such as passwords, PIN, CCV, etc, do the following.
- Select the item you want to see from your Vault, be it login, wallet item, etc.
- Note the super-secret information is masked from view with dots, as in the example depicted above.
- Press and hold the “Option” key, and the secret information will be revealed, as in the example below.
That’s it! Very simple, but oh so effective and handy when dealing with a situation where you can’t use 1Password to auto-fill the information, either on a website that doesn’t play nice, or over the phone. Maybe auto-fill over the phone will be a feature in version 4!
Scenario: You are writing an application or library which targets the "AnyCPU" platform, but reference an external library (such as LeadTools) which are platform specific (x86/32 bit, x64/64 bit)
This situation is handled in several places, as there is no one unifying solution which applies to all phases of development.
During the Development Process
Storing the references
Create one folder for each supported platform. These can be placed either in a central location, or a subfolder of the solution/project. Best practice is to name the folder after the target platform. While this is by no means required, it is strongly recommended and urged.
- IA64 (very rate, not covered in this article, but the same steps apply and will work)
Initial project creation and adding references
Add the references to the project through Visual Studio as you typically would. Choose the binaries which are applicable for the platform which are presently using.
Working through the book Beginning WF: Windows Workflow in .NET 4.0 by Mark J. Collins, there came a point where the next step is to add an “Add” activity to the workflow (Chapter 4 for those interested). The method given is to make changes directly to the XAML of the Workflow designer, and it would then appear within the designer when switching out of code mode.
Unfortunately, I had a typo somewhere which my brain couldn’t reconcile immediately at this late hour, and took me thirty (30!) minutes and two re-types to get right. It didn’t help that there was no IntelliSense provided from within the XML editor, as I am accustomed to having with typical XAML code when doing WPF or Silverlight development.