While using the Web Service Software Factory Modelling Edition to build up some WCF-Services I stumbled across a little Bug which was hard to find in the first place. While I was using the Host-Explorer to create my TestClient Proxies I noticed that some Endpoints led to creating wrong proxies where i.e. all Guids had been replaced by strings and many other stuff. Even with the Visual Studio Proxy generator some strange stuff occured such as generating classes like DoSomethingRequest1 which contained only one property of the Type DoSomethingRequest - so it seemed a bit of doublewrapped..
Finally I figured out what led to such behaviours: if you're designing a ServiceContract and putting more than one Message Part into a message you will get an Error saying that you have to set the "Is Wrapped"-Property of the message to True. This seems to be not a problem as long as the Request the message belongs to does not have another message associated (i.e. Request and Response) which has its "Is wrapped"-Property to False because it may have less than two Parts. Only if message is "wrapped" and one is not this problem occures so don't trap into that one

after a long journey of trying to get several WCF-STS-examples to run all at the latest failing at my selfmade certificates and endless hours of experimenting without exactly knowing what I was doing finally I found a simple but well explained blogentry which handles the basics of this stuff.
Part 1
Part 2

Yet another day of the CAB... I was using a customized Window-Workspace with my own derived SmartPartInfo. This SPI included a key-string which I usually filled with a primary key of an entity for which the window was shown (simple edit dialog). I used the key to check if the window is already opened so it was impossible to open/edit the same Entity twice. So far so good, but finally my key was always null in one of my dialogs. The only thing that was different to another (working) dialog was that I tried to change the title of the window after it was shown and I did this by giving it just a simple SmartPartInfo. So it was some older code but I was still wondering why it did not crash anyway - I thought wether the ApplySmartPartInfo-Method would have recognized that its "only" a SmartPartInfo or it wouldn't and a cast to my derived type would have failed.
Well, as often .NET Reflector solved the mystery.. turned out that CAB looks at both types - the Template-Argument for the SmartPartInfo-Type and the type of the given SPI-instance and uses Type.IsAssignableFrom to determine if the given instance is -or at least inherits from- the template-Type. If not -and thats the catch- it uses Workspace.ConvertFrom which will create a fresh new Template-Type SmartPartInfo (with all its default values set of course) and copies only the two things that it knows from ISmartPartInfo to the new instance: Title and Description. And so my key was rewritten and the whole stuff didn't work but also did not crash or anything other wrong...

Recently I had to use MSBuild directly to automate some builds. I also had to configure some preprocessor defines based upon a configuration. This is usually done by an Argument like this

"/p:DefineConstants=MY_PREPROC_FLAG"

Nothing special here since there are enough comments on the web about that. Today I needed one Flag more and I used the commandline syntax similar to how I knew it from the IDE:

"/p:DefineConstants=MY_PREPROC_FLAG;YET_ANOTHER_FLAG"

but this one didn't work.
So the point is that if you want to support multiple defines to a project by commandline you'll have to separate them by simple spaces...

"/p:DefineConstants=MY_PREPROC_FLAG YET_ANOTHER_FLAG"

and it will be added to the (semicolon-separated) Defines from the IDE.
Good to know I think...

I was using ODBC to Excel for a while and it turned out to work well (if you take care of integrity by yourself...) but for some reasons until now I hadn't used any DELETE FROM-Statement. So I was a little bit disappointed when my first DELETE returned this:
[HY000] [Microsoft][ODBC Excel Driver] Deleting data in a linked table is not supported by this ISAM.
(well the message was "ISAM unterstützt das Löschen von Daten in einer verknüpften Tabelle nicht." since my system is german)
Since the Message itself was somewhat confusing I found out that it is simply not possible to drop Excels lines via ODBC - you can clear lines but you cannot delete them. There are some workarounds in the net which may use other components to do the delete job but the ODBC wont let you.
I prefered simply to add a "Deleted"-Column to my Excel table and rejected these lines already in the DataAccess layer so the real data always remains. Maybe I'll write a Defrag Job later if the deleted data starts to cause performance problems.