2014-05-20 12:00:00

Ever have a day like this one?

Check email and notice a message from somebody having trouble using SQLitePCL.raw on Windows Phone 8.1. Realize that I haven't run the test suite since I started working on the new build scripts. Assume that I broke something.
Hook up the automated test project to the output of the new build system. Sure enough, the tests fail.
Notice that the error message is different from the one in the user's email.
Realize that the user is actually using the old build system, not the new one. Wonder how that could have broken.
Bring up the old build system, run the tests. Yep, they fail here too. Must be something in the actual code.
Dig around for a while and try to find what changed.
Use git to go back to the last commit before I started the new build system stuff. Rebuild all. Run the tests. They pass. Good. Now I just have to diff and figure out which change caused the breakage.
git my working directory back to the current version of the code. Rebuild all and run the tests again to watch them fail again. BUT NOW THEY PASS.
Wonder if perhaps Visual Studio is less frustrating for people who drink Scotch in the mornings.
Decide that maybe something was flaky in my machine. The tests are passing again, so there's no problem.
Realize that the user wasn't actually running the test suite. He was trying to reference from his own project. And he had to do that manually, because I haven't published the nuget package yet. Maybe he just screwed up the reference or didn't copy all the necessary pieces.
Run the tests in the new build system to watch them pass there as well. But here they STILL FAIL.
Decide to take the build system out of the equation and just finish getting things working right with nuget. Build the unit test package separately in its own solution. Add a reference to the nuget package and start working out the issues.
Run the tests. Everything throws because the reference got added to the "bait" version of the PCL instead of the to the WP81 platform assembly. Oh well. This is what I need to be fixing anyway.
Notice that the .targets file didn't get properly imported into the test project when the package was installed. Wonder why. But that's gotta be why the platform assembly didn't get referenced.
Realize that the bait assembly somehow got referenced. Wonder why.
What is Scotch anyway? Go read several articles about single malt whiskey.
Decide to take nuget out of the equation and focus on why the new build system is producing dlls that won't load.
Google the error message "Package failed updates, dependency or conflict validation". I need to know exactly what was the cause of the failure.
Realize that the default search engine or IE is Bing. Do the same search in Google. Get different results.
Become annoyed when co-worker interrupts me to tell me that there is a new trailer for Guardians of the Galaxy.
Read a web page on the Microsoft website which explains how to get the actual details of that error message. Spend time wandering around Event Viewer until I see the right stuff.
Realize that the web page is actually talking about WinRT on the desktop, not Windows Phone.
Try to find a way to get developer-grade error messages in the Windows Phone emulator. Fail.
Notice that below the error message, Visual Studio's suggested resolution is to instead use a unit test project that is targeted for Windows Phone, even thought IT ALREADY IS.
Blame Steve Ballmer FOR EVERYTHING.
Wonder if WP81 is the only thing that broke. Run the tests for WinRT. They fail as well.
Get annoyed because the only way Visual Studio can run the unit tests for just one project is to unload all the others.
Get upset because the Visual Studio Reload Project command doesn't work like the way it did a week or two ago. Now it reloads all the projects instead of just the one I wanted. Did the installation of the Xamarin Visual Studio integration break it?
Go back to the very basics. Run the unit tests for plain old .NET 4.5. They pass.
Re-run the unit tests for WinRT to watch them fail again. NOW THEY PASS.
Realize the co-worker is absolutely right. The most important thing is to watch the Guardians of the Galaxy trailer.
Get annoyed because the sound on my MBP isn't working. Watch the whole trailer anyway, without sound.
Review all my project settings in the Visual Studio dialogs, just to see if I notice anything odd.
Go back to my web browser. Realize that the world of Scotch whiskey might actually be more complicated than Visual Studio.
Go home. Discover that the annual spring invasion of ants in our kitchen is proceeding nicely.
Fight some more with Visual Studio. Give up. Go to bed.
Wake up the next morning. Discover that the teenager's contribution to our war against the ants was to leave unrinsed plates by the sink. Thousands of ants feasting on cheesecake debris and syrup.
Open the laptop. Run diff to compare the csproj and vcxproj files from the old build system against the new one. See that there are no differences that should make any difference.
Change them all anyway. Update every setting to exactly match the old build system. One at a time. Run the test suite after each tweak so I can figure out exactly which of the seeminlgy-harmless changes caused the breakage.
Wait. My kid had cheesecake and waffles FOR DINNER?
Become seriously annoyed that Visual Studio changes the Output pane from "Tests" to "Build" EVERY SINGLE TIME I run the tests.
Finish getting all the settings to match. The tests still don't pass.
Try to remember if I ever done anything successfully. Anything at all. Distinctly recall that when I was mowing the lawn this weekend, the grass got shorter. Focus on that accomplishment. Build on that success.
Realize that the old build system works and the new one doesn't. There has to be a difference that I'm missing. I just have to find it.
Go back to the old build system. Rebuild all. Run the tests so I can watch them pass and start over from there. BUT NOW THEY'RE FAILING AGAIN.
Go do something else.