Since I was using ODBC to read/write Excel documents recently I was surprised not to have too much problems with it. Today a problem occured - funny thing because I was nearly through with changing the application to finally use SqlCE as persistency layer...
The problem was that we needed some large texts placed in some columns but excel just truncated it down to 255 chars (256 if you count the ' thats visible in excel). I didn't had much time to write some workaround at this point so I tested a little bit hoping to find a shorter workaround.
Of Course todays excel can handle more than 256 chars in a cell but when you save the document you'll get a warning for some incompatibility issues. Nice - file saved in "new" format - opened my program again - inserted a large text and ye......no - again truncated to 256 chars. So the ODBC driver seemed to switch back to old format. Since the driver seemed capable of handling xls files of office 12.0 (2007) according to the descriptions in the ODBC-Administration dialog I was looking for a simple way to make him use the new format. Finally I found something on the web saying that the driver determines the format by scanning some rows and while reading this I rememberd something I red earlier; there is an option "Rows to scan" in the ODBC-config and/or in the connection-string which was always set to 8. Well putting a large text in one cell in the first 8 rows and SUCCESS now even my application can write texts with more than 256 chars...
At this point I stopped testing so maybe it is possible to increase the RowsToScan variable to a max value or something - for me my quick and dirty workaround was done here

Today I wanted to Show a Modal Dialog until something was stored in the FormClosing event. For some reason at another point in an UnhandledExeptionHandler I called Application.Exit(). The result was another Exception "Collection was modified; enumeration operation may not execute"...
I was abled to reproduce this effect in a very simple WinForms-example with two forms and a button:

 private void button1_Click(object sender, EventArgs e)
 {
     Application.Exit();
 }

 private void Form1_FormClosing(object sender, FormClosingEventArgs e)
 {
     using (var frm = new Form2())
     {
         frm.ShowDialog();
     }
 }

So the clue is that Application.Exit enumerates its forms and raises the FormClosing event - which... opens a window on its own and so modifies the Applications Form Enumeration which led to this bug.
btw a MessageBox.Show did NOT produce this problem maybe because its just mapped to an Win32 API-Call that wont modify the .NET-Applications-Formlist.
I worked around that problem by simply Closing the Window instead (or just before App.Exit).

A few days ago I was about to use the linq to SQL column property "Delay Loaded" for the first time. I wanted to return some plain data objects with an (propably larger) Image field left empty to load it later only if the entity would be selected in the GUI. So I used one Method to give me a set of objects with an empty image field and later another method to give me a specific image.
I already knew this Delay Loaded-Property would cause the creaton of a System.Data.Linq.Link<T> internally. So I thought as soon as I would do a read-access to that image-column the full content would be loaded from the database (though even write-accesses will imply a pre-read of that data so dont think about avoiding loading huge data by setting the field to another value).
I used my datacontext in a using block where I typically set the ObjectTrackingEnabled to false because I dont needed that if I only do readings to the DB. But in fact it turned out that this would also avoid loading fields that are "Delay Loaded" - so ObjectTrackingEnabled set back to true and everything worked fine as long as I initially accessed the image field inside the using-construct (ok that makes sense easily..).
I checked against the documentation where I found a short page about how to retrieve information as read-only and found out that setting OTE to false will also set DeferredLoadingEnabled to false and that would skip the expanding of one-to-one and one-to-many relations - BUT no word about Linq.Links
Looking into the docs of DeferredLoadingEnabled also told me that if OTE is false DLE is not only set to false - its ignored completely - and again nothing about Delay-Loaded Fields. So maybe this info was helpful..

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...