Bugs

Yibo writes this blog on a number of critical bugs in MS .Net Framework. These bugs are stale and MS never bothers to fix them.

Deserialization in Dll

You can't deserialize an object from a dll. Why? This is the way how the deserializer works. In the serilization stream, the serializer BinaryFormatter.serilize() write along the info of the assembly in which the serializable class is defined. On the other end, the deserilizer BinaryFormatter.serilize() will try to load the assembly whose info is retrieved from the stream; if the serializable class definition is in your executing exe, it works fine; if the serializable class definition is in an external dll which is located in the same directory in your file system, it works fine too; it will not work if the serializable class definition is in an external dll which is located in the same directory in which the executing exe is in.

Therefore, don't use serializable class in a dll which is not located in the executing directory even though it is located in a sub directory.

Workaround: put all dlls in one directory; try to find something in the .net framework to substitute your serializable class even thought this is hacky.

WPF Resource

This really gave me enough headache. The Visual Studio Compiler sometimes just won't compile resources into assembly properly for no reason. If you resource won't load, just right click on the project and do rebuild for a hundred times. Before you swear, double check if you mark your resources as "Resources" instead of "Content". If you don't specify the resources to be "resources", you can't blame MS.

Sometimes resources are indeed compiled into assemblies but they still won't load. In this case, the program may or may not throw an exception which can be either a IOException:Cannot locate resource or a DirectoryNotFoundException if you put your resources in a folder (like images/image.png). I can't figure out what's going on; Rebuilding without changing any code could fix it sometimes but not always. If rebuilds won't fix it, try alternative syntax: I just switch between new Uri("images/image.png", UriKind.Relative) and new Uri("pack://application:,,,/images/image.png") back and forth. Combine rebuilding and alternative syntax(both syntax should work the in the same way in theory) will eventually fix it. I know you will be pretty mad; me too.

No Workaround found.

foreach loop null reference

foreach (string aString in stringList) will throw a null reference exception, where stringList is an ObservableCollection<string> holding 0 elements. Sounds ridiculous but it happens.

Workaround: check the count before the loop. Sounds retarded but works.

Width/ActualWidth difference

Sometimes a simple control's width is larger than the actualwidth by a small margin (1-5, random to my observation) for no apparent reason. In other words, if you set control.width = value, the control is sized to value with the actualwidth being value; however, control.width may actually jump to a slightly larger value at certain point (although this happens really rarely).

Workaround: always use actualwith if possible.

WPF Databinding DataContext update breaks binding

Sometimes, you changed a variabe (not a property but affecting other properties bound) in a data object and WPF won't update the UI. This makes sense because WPF only knows when properties are changed. So you just do a UIObject.dataContext = dataObject (you called this same statement somewhere before). This does not update the UI but destroys the binding compeleted. This makes no sense.

Workaround: call UIObject.dataContext = null followed by UIObject.dataContext = dataObject will force a re-binding.

Popup Windows lose data context

A popup windows (Popup class) will inherit the data context from its parent control (where it is popped up from). The data context will be lost if the focus moves to another control when the popup is still open. This is ok. But the data context is not restored next time the popup is shown.

Workaround: manually restore the datacontext object in a event handler (e.g. ContextMenuOpening).

InputHitTest not work properly with a Panel that has or is a first, depth search child of another Panel

A panel class (Grid, DockPanel, and etc) calls InputHitTest will not detect the first depth search child of this panel. If the method takes a coordinate on its first, deepest child, it will return null rather than the child expected. If the panel is a first, deepest child of another panel, calling InputHitTest on this panel will always return null.

Workaround: use panel.InputHitTest(point) || firstchild.CoverPoint(point) where CoverPoint is a manual check of coordination.