I've had my Motorola Droid A855 for a while now, and am quite happy with my "smart phone" / PDA / email "thing." However, yesterday I was charging it through my computer, and rebooted. Little did I know, this would lead to an hour of misguided troubleshooting. This was suggested to me as a well known fact, but I could only find one clear mention of this problem (not that I scoured the internet too hard, but if it was very well known I would think it fairly easy to find).

That aside, I awoke to find a system update on my Droid. This was to go from 2.2 (FRG01B) to 2.2 (FRG22D), which "officially" supports installing Flash (10.1) via the Market. Which I promptly tested on YouTube and with a flowplayer example page.

The Flash Player seemed to drop frames on YouTube, with the full YouTube application being a much nicer user experience.

I also made sure to set plugins to "on demand" just in case flash ads are going to slow down the browsing experience.

I would have also linked the QR code (generated via Google's chart API) but WordPress seems to want to convert market://search?q=pname:com.adobe.flashplayer in to simply com.adobe.flashplayer when in the href of an anchor. Fun times.

Update:
Link and QR code fixed.
Now visible from any browser!

This last week a coworker was trying to manually manage which revisions were being built by our continuous integration system. However, doing so without a complete understanding of exactly how to approach the problem. Not to mention the fact that the continuous integration system provides a mechanism to specify the revision as a parameter for the build.

In an effort to minimize the amount of interaction required, as well as to apply a level of control, my coworker was supplying the build system with a URL like https://<server>/<repo>/!svn/bc/<revision>/<path> which is what a Subversion client that supports HTTP/DAV to access repositories uses to retrieve specific revisions, as well as other revision information. This failed with a very angry exception, that the URL didn't support the REPORT verb (well, it kind of said that).

As it turns out, there are -- quite understandably, a number of special URLs for accessing various pieces of information about the history of items within a repository. These "private" URLs are currently defined in http://svn.apache.org/repos/asf/subversion/trunk/subversion/mod_dav_svn/dav_svn.h and the comments seem to suggest that they are extensions above and beyond DAV.

The Subversion Book discusses mod_dav_svn, and even mentions that the '!svn' part can be changed with the SVNSpecialURI configuration directive. Other than that it doesn't really say much about the special URLs. All of this suggests that these URLs should not be used explicitly. Without digging too much further, that's the conclusion I came to anyway. Was fun to read about though.

Yesterday afternoon I was playing around with this program I wrote for my Dad while I was in college so that he could crop and upload photos for eBay auctions. Visual Studio 2003 was the tool of choice, using C# and targeting the 1.1 CLR. Development on the tool was pretty light, and I moved on to Visual Studio 2005, and had to make a change to the program. I spent quite a bit of time working with Visual Studio 2005, but still wanted to target the 1.1 CLR.

This led me to MSBee, which is a set of msbuild targets that let you build against the 1.1 CLR in Visual Studio 2005. Which worked well enough, until I wanted to move to Visual Studio 2008. So to simplify things there, I moved to the 2.0 CLR. I removed the MSBee modifications to the project file, and got things working. Moving to the 2.0 CLR wasn't too messy, as it had been widely deployed through Windows Update. However, now one of my Dad's friends was also using the program. Field trip! Apply updates, and copy over the new version -- oh and solve random other computer issues. Yay.

And here we are, all caught up to yesterday. Finally getting around to Visual Studio 2010, and figured the "eBay Images" tool was as good a project as any to start with. Opened fine, built and even ran the first time. Great! I fixed a bug I had remembered my Dad telling me about. Rebuilt, and ran.

I am a bit of a regular in the ##csharp channel on freenode, so I thought that was as good a place as any to ask. It's a pretty quiet place at 1:30am CDT. But by 2am someone had suggested that I might be referencing some 3.5 or 4.0 assemblies. Quick to check as I'm only referencing 5 assemblies -- nope. Then I thought I should open the .exe up in Reflector to see what it reported. Which listed two versions of mscorlib.dll as dependencies, 2.0 and 4.0. This seemed quite strange, and was where I fell asleep in my chair thinking about it, and woke up at 5am to actually go to bed -- not really thinking about this problem any more.

After waking up rested and refreshed, at 10am, I took another crack at the problem. Some more conversation in ##csharp, the suggestion was that the compile was bad and the only resolution was to reinstall the various framework version that I had installed (which would entail reinstalling 1.1, 2.0, 3.5, 4.0 and all updates for each -- not something I was interested in doing).

Some lucky googling led me to this Microsoft Connect post, which described exactly what I was seeing. One of the detailed comments talked about the ToolsVersion attribute of the Project node in the .csproj file.

The ToolsVersion set to 2.0 is apparently a problem. Changing that to 4.0 made everything quite happy, as the workaround from the Microsoft Connect post suggested (I didn't notice the Workarounds tab until after reading all of the replies).

And tada, everything is working again!

https://code.opello.org/svn/ebayimages/ if you want to look at my very ugly, needs to be rewritten, source code. Which certainly doesn't cover the entire history of the program, but it's an ongoing effort.