Controller Led Navigation in Angular

I recently tried AngularJS for a pet project. I watched a great tutorial about the platform, then dove in head first. You can see what I built here: MysterySolver

I enjoyed Angular. It was straightforward to use, and allowed me to bang out a lot of functionality without much cumbersome boilerplate code. Jasmine, the testing framework set up in the bootstrap source, was also pretty slick. I really liked how I could nest a bunch of test blocks inside of each other to reuse common setup code.

The only serious bump I ran into was getting multiple controllers to work together.

My goal was to build a wizard-style flow. A user enters a bit of info, hits a button, then enters more info. The answers in one step affect the questions in future steps, or might cause steps to be added or taken away. I wanted the controller to trigger the navigation, and I wanted to pass state when it did.

View-led navigation would have been easy: add a link whenever you like. A user clicks and the new controller is loaded. This kind of navigation is great for keeping controllers ignorant of each other. I suspect this approach is better for search engine indexers as well. It wasn’t ideal for me.

I searched the Internet and read a bunch of documentation hoping to find an easy answer. What I found was a bunch of other people asking the same questions. When I finally decided to build it myself, the solution was easier than I expected:

To navigate, I used code like this:

In the destination controller, I fetched the navigation parameter like this:

It was easy to test this code. Whenever I expected a controller to navigate, I checked the value of $location.path(). To pass navigation parameters into controllers, I just called the navigate method before the controller was created in the setup block.

Unfortunately this solution breaks the back button. Because the browser triggers backward navigation, the navigation parameter won’t be set when the controller tries to load. This wasn’t something I needed, so I left alone.

64-bit IIS vs. 32-bit Assemblies

I found my first 64-bit bug at work. I was moving a windows service built for the ‘Any CPU’ to a 64-bit server. It started fine on the new server, and gave no indication of poor health in the logs, but one key function was malfunctioning. Im not exactly sure what the cause is, but I know that the hash of any binary file was resulting in the same value. The service does some direct memory manipulation which is a likely culprit.

Fixing the problem was easy: Set all the assemblies to compile for the 32-bit platform, check it in, build it, ship it.

Except that my web service now looks like this:

Server Error in ‘/MyApp’ Application.

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

This application has two parts on the server: a windows service that processes emails, and a web service for interacting with them. The two parts share a database and a bunch of business logic, so they also share some assemblies. The windows service works great now that I’ve converted all the assemblies to 32-bit, but the web service wont start.

Although the error message is a bit misleading, it wasnt that hard to find the problem. When IIS is running in 64-bit mode (as it tends to do on 64-bit servers), all of its application pools will be 64-bit, and a 64-bit application pool cant load a 32 bit assembly. These are all the ways I can think of to fix it:

  • IIS 7 can run an application pool in 32-bit mode
  • IIS 6 can be configured to run in 32-bit mode, or you can run a second instance in 32-bit mode, though I dont imagine both instances could share the same ports
  • Write 32-bit and 64-bit versions for any platform-specific operations using conditional compilation, then build two versions of your assemblies
  • Rewrite the malfunctioning parts of your app so you dont have any platform-specific code
  • Compile most of your assemblies for ‘Any CPU’, but compile entry-point assemblies (such as my service executable) for 32-bit

A configuration-based solution isnt ideal based on the number and management practices of our environments. Finding and removing platform dependence would be the best technical solution, but it would be risky and time consuming. Switching some of my assemblies back to ‘Any CPU’ did the job with a minimal amount of impact.