I experienced the strangest thing with my installation of Visual Studio 2008 last Friday. In the middle of developing a Windows Forms application, I noticed that the Properties window had stopped working. It was still there, just blank, and so was the dropdown above it where the components usually reside.

Update 19-12: This blog post will be revised soon. I have since experienced this same error under different conditions which had a different solution.

Update 20-12: This blog post is superseeded by this one. I have now found a generic strategy to follow if this situations occurs. The solution presented below was probably a one-time fix that will most probably not help you. Please read the new article.

This was not just with the current file, but for all files in my solution. It would not even display the mainly informal properties of the current file selected in the Solution Explorer. Closing the solution and re-opening it did not help. Hiding the properties window and re-showing it did not help. Google led me to several suggestions, most of them telling me to execute a command in the Visual Studio command prompt (devenv /setup) would fix things. Nope, not for me. Starting VS in safe mode to eliminate plugins. Still blank. Even other solutions I opened now had a blank properties window. Oh dear. I was now getting worried that I broke something very serious in my VS installation.

By now I had found a workaround though: clicking inside the property viewer and pressing ESC. This however was needed *every* time I changed the selected control or component. I was on a serious timeline for a presentation of this application so I managed to use this tedious workaround to put in the last changes I wanted and compiled. The presentation went great btw.

Finding the problem

Monday late afternoon I finally had time to investigate further. I rolled my working copy back to the last point in time I knew it worked (those among you that are not using version control software (like SubVersion) yet, start now!), and opened it in Visual Studio. Hey, my properties window was back! I now knew that it was at least something in my solution, and not the VS installation itself, that was causing the problem. But what?

I started rolling forward all changes I made since then. Unfortunately, some of these were in fairly big chunks, so once I identified the revision that broke the property window again, I was still left with a large amount of changes to sift through. Note to self: check in smaller changes next time! Also complicating the matter was that once the properties window broke, it would not work again until the entire IDE was restarted. Just rolling back and re-opening the solution was not enough. This explained why Friday other solutions looked broken too, but in fact weren’t (phew).

This morning I finally found it. The solution contained two standard WinForms datasets (.xsd files). One of them would open correctly in the Dataset editor (though without properties of course), the other would remain at some “please wait while loading” message forever and show none of the TableAdapters in it. That was suspicous behavior. So I looked at the changes I made to this .xsd file in the problematic revision. One of the TableAdapters in there had several queries I gave specific names. It did not have the usual default Fill() or GetData() method, the default query was named FillById(). However, much later in development I did need a kind of “get all records” function and added it the TableAdapter, naming it “Fill”, like Visual Studio would have done by default. I should not have done that.

Really, the source of the entire problem was having a tableadapter with a custom query named Fill(). Apparently, just the simple fact that a DataSet was present in a single project in the entire solution, that had a single TableAdapter with a custom query named Fill(), was enough to break the Properties window as soon as the solution was openend by Visual Studio and it would not work again until VS was restarted. Wow.

Note that Visual Studio never complained to me about naming the method as such, and the project compiled and ran absolutely fine. It just broke the properties window in the IDE. It looks like the VS IDE treats tableadapter methods named Fill() and perhaps also GetData() in a special way, and chokes on them when they are not what was expected. Ouch!

Fixing it

After all this, fixing it was relatively easy. I opened the .xsd file in a texteditor (I can really recommend UltraEdit) and found the line describing the method. It looks something like

<DbSource DbObjectName=”(tablename)”… FillMethodName=”Fill” etc. >

I changed the “FillMethodName”, “GeneratorSourceName” and “UserSourceName” attributes from “Fill” to “FillAll” and saved. Back in Visual Studio, I right-clicked the just updated .xsd file, chose “Run Custom Tool”, tried to build it (which fails as expected) and then used the compiler error list to fix all references to Fill() that were now broken. Save all again, rebuild, and close and re-open Visual Studio and re-open my solution. Visual Studio and my solution were all fine. Yay!

If I ever find time to reproduce this in a simple demo application, I’ll file this with Microsoft Connect. For now, it’s cost me enough valuable time already! I’m writing this here so I won’t forget might I ever run into this again, and perhaps save some of you some time that run into this corner case but very annoying bug.