Yesterday I wrote about an issue with a Visual Studio 2005 Smart Device projects, which were moved to Visual Studio 2008.

Since creating a new project of that type in VS 2008 creates properties instead of public fields there have to be differences in the project description (*.vbproj for a vb.net project). To look for differences I like WinMerge most. So I launched it and compared a fresh VS2008 project file to the upgraded one.

There were many differences in both file. Because comparing both files alone did not help, I investigated a bit in how the code was generated. One evidence was the comment 'This source code was auto-generated by Microsoft.CompactFramework.Design.Data, Version 2.0.50727.3053.'

Visual Studio uses this dll (located in %programfiles%\Microsoft Visual Studio 9.0\common7\ide) to generate the proxy code. There is almost no info available on this assembly, therefore I had to start my favorite toy: Red Gate's Reflector.

The class DeviceDiscoCodeGenerator is responsible for generating the code using standard CodeDom techniques. In CodeDom you can specify CodeGenerationOptions as flags to specify how primitive types are represented (as fields or as properties). The flag I was looking for is GenerateProperies. And indeed, this flag is set in GenerateCode method guarded by an if statement. The if statement evaluates a build property ("FileUpgradeFlags"). Looking back in the project file (*.vbproj), there was an empty FileUpgradeFlags tag:

<FileUpgradeFlags>
    </FileUpgradeFlags>

To set the flag I had to remove this entry. After doing a "Update Webreference" in Visual Studio, CodeDom generated the properties as expected!

We moved our smart device project from Visual Studio 2005 (VS2005) to Visual Studio 2008 (VS2008).

Everything worked after the upgrade except one odd thing: We have a ComboBox, which datasource is bound to a collection which type is provided by a webservice. The client side code to access the webservice was generated using the "Add Webreference" feature. If we start our application, the ComboBox is filled with the correct number of items provided by the datasource property, but every item shows only the name of the class (default ToString() behavior) and not the value, we provided in the DisplayMember property.

After some debugging, I found out, that setting the DisplayMember of the ComboBox has no effect. Retrieving the DisplayMember property gave us a nothing/null value. The reason for this was the designer generated code, which can be found in the Reference.vb file.

All properties which we had in the file turned into public fields! We had no compile time errors, but at runtime we now tried to set the DisplayMember of our ComboBox to a public field, instead of a public property. I'm not sure if it is working on a Windows Application if you set the DisplayMember to a public field, but on the Compact Framework it is not working!

The curious thing is, that if you create a new Project in VS2008 and add the same webservice as a reference, all the properties are generated as expected.

I have no solution to this problem yet, but it's a serious issue, if you have to move a lot of VS2005 projects to VS2008 and update the Webreferences because there are no compile-time warnings or errors.

There is a workaround. Use wsdl.exe to generate your client-side stubs and then edit unsupported code as mentioned on msdn.

I'll updated this post as soon as we have a solution for that problem.

Update: Solved this issue. See here.