The unluckiest developer alive

Sometimes I think I should be a tester for developer tools. For some reason I have the uncanny knack of stumbling onto the most obscure bugs in Visual Studio.

I am currently trying to learn Microsoft Sync Framework, and decided (after watching a good video on how to do it) to set up an ADO.Net Sync Services Local Database Cache. I went through the process step by step, the only 2 differences between my environment and the one demonstrated in the video was that I was running SQL Server 2008, and I was using the AdventureWorks2008 database.

The procedure I followed was this…

1. Create a new Winforms Application
2. Add A new Local Database Cache (this starts the wizard)
3. select the AdventureWorks database
4. Select the Production.Products, Production.ProductDescription, Production.ProductPhoto tables to add to the cache.
5. Click OK.

Everything else I left as the default configuration. The result:

So I figure it’s something to do with my environment. I spent about half an hour Googling and looking at forums before I decided that I must be the first person ever to hit this bug. Next I tried to see if it was because of something in my environment, I checked my setup

Windows 7 64 bit; SQL Server 2008 SP1; Visual Studio 2008 SP1; Sync Framework 2.0 x64;

The only thing I could think might be an issue was the Sync Framework 2.0 x64, so I uninstalled and installed the x86 version. Still the same problem.

I then opened SQL Profiler and tried to see if anything was obvious there, but concluded that it was all OK (I later discovered that I didn’t look closely enough at this).

I then cracked open the wizard dlls in reflector to see if there was any help there, but alas, theat was pretty much a dead end too.

I even posted an article on the Sync Framework Forum.

Frustrated, I decided that it had to be my own environment that was causing the problem, so I set about creating a virtual environment on GoGrid. Once I had managed to get everything installed, I tried just the Production.Products table this time, and got the exact same error.

I then tried creating a completely new table in a completely new database, and, surprise surprise, it actually worked… well, almost. It got past the wizard, but the code it generated would not compile. It appears that I stumbled on yet another bug in the Sync Framework wizard, if you use a table called “SyncTable”, the generated code is broken.

Encouraged by the “success”, I pressed on undeterred. I finally got everything working by creating a table called “MyTable”.

Not satisfied that I had made it work (finally), I decided to try and track down the bug. After about an hour or so of playing around and not having any success, I finally cracked open SQL Profiler again and found that the last statement executed before it died when trying to create a local database cache for the Production.Product table was the following

SELECT * FROM [Product]ion.[Product]

Obviously the code that works out the schema and table name needs some reworking.

Technorati Tags: ADO.Net,ADO.Net Sync Services,Sync Framework