Stuff for Geeks

Louis Haußknecht's blog

Solved the Visual Studio code generation issue

clock May 5, 2009 11:53 by author Louis

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!

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Different code generation using upgraded Smart Device Project in Visual Studio 2008

clock May 4, 2009 18:19 by author Louis

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.

image

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.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Team Foundation Server Search in Code (VB.net)

clock April 30, 2009 23:49 by author Louis

The company I’m currently working for has about 100 developers, who are committing their code to SourceSafe.

Since Visual SourceSafe (VSS) has some serious issues and is far away from bein state-of-the-art the company is now in process of testing Team Foundation Server (TFS). Our team is the test team and we have moved our source (without history) to TFS.  

After some days of using the system, we were looking for the feature “Find in Files”, which was used quite often in the VSS era. We installed the TFS Powertoys which gave us a “Wildcard Search”. At first sight this feature looks like the good old VSS “Search in Files” but in fact this option searches only in filenames. After some googling I found this StackOverflow post of some other guy, who was looking for this feature.

For me it’s unbelievable to ship such a big product without basic functionality like “Search in Files”.

There are some answers which pointed me to a cool project: CS2Search.

CS2Search lets you index your code and search with some neat queries like

interface:IFooBar

Obviously this will give you all IFooBar interfaces in your indexed repository.

CS2Search uses Lucene.net to index the code.  Since Lucene.net uses files as input, you have to setup a scheduled task or some triggers/notifications to get the latest code out of the Source Control System.

I really like the CS2Search idea.  But It’s a pity for us, that there is no VB.net parser available out of the box, since the company develops in VB.net. But as simoneb said in this blogpost, it is possible to integrate your own parser through Windsor IoC.

Building a parser is a nice exercise and thanks to Microsoft and it’s missing search-feature in TFS I will dig around in this topic soon.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Setting up my blog environment

clock April 29, 2009 17:14 by author Louis

This will be my first blog entry on my new stuff-for-geeks.com site.

I decided to talk more about my daily life as a consultant and developer in the .net scene.

So here is my little HowTo:

1. Get a decend machine for your site

2. Choose a domain name

3. Choose a blog engine

4. Install and configure the site

5. Install the blog engine

 

Step one:

My choice was a root server with Windows 2008 Web as os.  You can get one with great support at strato.com. The machine was up and running in a few hours. 

Step two:

To start my blog, I needed a pretty domain name. I dug around my parked domains and found stuff-for-geeks.com! I bought this domain back in 2004. The idea was to sell geeky items like the good old IBM Clicky Keyboard. (Well that business was not running very well, but the silver lining was that I'm now proud owner of some rare vintage keyboards...)

Step three:

The Blogengine.

Some days ago the Visual Studio start page pointed me to the MIX 09 Keynote Video. Scott Guthrie introduced the Web Platform. You can get the Web Platform Installer (WPI) here. This little tool makes it really easy to install apps and developer tools on you server or workstation. Included are different Blogenginges. After some googling for the different pieces my decision was to use blogEngine.net.

Step four:

Site Installation

Installation of a site is very easy with the IIS 7 Manager. So I added a new blank site, and told IIS to listen for Host Headerslike stuff-for-geeks.com.

Step five:

Last not least by installing the blogengine was very easy. Just click install in the WPI and choose which site you want your app to be in. That's it. WPI is not just copying the contents to your directory, it configures security settings (BlogEnginge.net needs write access to the AppData Folder) you, so that after the installation you have a ready to go app on your machine!

 

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


About the author

Louis Haußknecht is a consultant for .net and Microsoft technologies. He lives in Germany and works in Europe.

  XING

Month List

Sign in