Pure Walt, from Concentrated Thought
Resources for quickly getting up to speed on C#.
This is the page of C# resources that I wish I had when I got started.
Snag a copy of Visual Studio, whether it’s the free Express version, or one of the uber-featured ones.
In addition to .NET, snag the Reactive Extensions (Rx) library.
If you’re able to, grab a copy of Expression Blend as well for graphical layouts. Not mandatory, but it helps.
And you’ll want these books:
 |  |  |  |
And they say you can’t herd cats.
This morning I got up to go to the bathroom, but it was occupied by my wife. Making matters worse, I had to stand in line.
MySQL 5.1.51 introduced a nasty little bug that has the potential to really cause some production servers some ill — cascading delete and updates can sometimes fail if you’re dealing with “too much” data at once. Where “too much” is a relatively small amount. You may get bit if you have a one-to-many relationship.
A note of warning to MySQL users using 5.1.51, you may want to downgrade to 5.1.50 for a little bit.
There’s a problem with 5.1.51 in which cascading deletes or updates throw an error. Not good if you have constraints and one to many relationships.
ERROR 1030 (HY000): Got error -1 from storage engine
The mysql error log will say something like:
InnoDB: Cannot delete/update rows with cascading foreign key constraints that exceed max depth of 250
This is a confirmed bug in MySQL and is repeatable. The error will cause a transaction rollback. Not good news for people running production systems.
See MySQL Bug #357255.
While the problem was quickly identified and apparently resolved, as the defect report is closed, it does not look like the 06-Oct-2010 change has made it out to the production baseline as of the time of this writing.
Additionally, the MySQL pre-release snapshots on labs.mysql.com show there is a mysql-5.1.52 pending with a September date, and this hasn’t made it to general production yet.
That leaves one to speculate that the fix will appear in the 5.1.53 version, and we won’t be seeing that for a month or two. Yikes.
The type ‘System.IObservable
During an upgrade of a C# WPF application that was using Reactive Extensions, I ran into this compile error:
The type ‘System.IObservable
exists in both ‘c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll’ and ‘c:\Program Files (x86)\Microsoft Reactive Extensions\Redist\DesktopV2\System.Observable.dll’
This is roughly the same kind of Defined in Multiple Assemblies problem as I faced before. (Solution provided.)
In this case, the System.Observable.dll was pinned to the 3.5 release of the Reactive Extensions.
The solution was to:
The predefined type ‘System.Func’ is defined in multiple assemblies in the global alias … mscorlib.dll and System.Core.dll. SOLVED!
Today I migrated a C#/WPF project in Visual Studio 2010 from .NET 3.5 SP1 to .NET 4.0. Immediately the compile failed issuing this set of errors:
To resolve this error involved understanding a little bit more about C#, .NET, and the Common Language Runtime (CLR).
According to C# 4.0 In A Nutshell from O’Reilly Press, on page 181 it says:
Some of the .NET types are used directly by the CLR and are essential for the managed hosting environment. These types reside in an assembly called mscorlib.dll and include C#’s built in types, ….
At a level above this are additional types that “flesh out” the CLR-functionality, …. These reside in System.dll, System.Xml.dll, and System.Core.dll, and together with mscorlib the provide a rich programming environment….
So mscorlib and System.Core are both needed. This begs the question, why is Func declared in both and thus causing a conflict? Or is it?
Further on in C# 4.0 In A Nutshell from O’Reilly Press, on page 183 in a general note it says:
A notable exception is the following types, which Framework 4.0 have moved from System.Core to mscorlib.dll:
- The Action and Func delegates
- …
This suggests a case exists where mscorlib is from our current .NET (the later one has Func), and System.Core is coming from the old one (which is where Func lives for that version).
How is this possible? It’s our projects fault.
This question on StackOverflow provides some insight; check out Simon‘s answer.
In my case, I had an entry that looked like this:
Removing the TargetFrameworkVersion, shown in red above, un-pinned the dll from the older .NET framework and things worked just fine.
Copy File
An unexpected error is keeping you from copying the file. If you continue to receive this error, you can use the error code to search for help with this problem.
Error 0x80070057: The parameter is incorrect.
SOLVED!
Went to copy a directory on Windows 7 from one drive to another, something that I had done quite frequently, even earlier that day.
However, this time, and nothing had changed substantially with the source files, I got an Error 0x80070057 message stating “The parameter is incorrect.” At that point the copy dialog from my simple drag and drop would allow me to retry (useless) or abort mid-copy.
The error message was unusually cryptic and less that helpful:
Copy File
An unexpected error is keeping you from copying the file. If you continue to receive this error, you can use the error code to search for help with this problem.
Error 0x80070057: The parameter is incorrect.
The disk was not full and a check disk revealed no errors.
THE SOLUTION
The destination directory name that I was copying into was pretty long, I basically had used a descriptive prefix, a date stamp of YYMMDDHHMMSS, by a space dash space, and a short descriptive comment. All in all it was about ~55 characters in length.
The directory I was copying from was a fairly deep structure.
That made me wonder if the fully qualified name of some directory path wasn’t exceeding some limit. On Windows, it appears to be 256 characters. On a Mac it appears to be 1023 characters.
Tricks aside, I was limited to the file system limits.
So, on the same disk, with the same files, immediately after yet-another-failure to copy, I renamed the destination folder to something considerably shorter and tried again.
Quick experimentation showed that was indeed the problem: the resulting path name formed during the copy was too long.
Solution: shorten the destination folder name and/or tighten up the path.
Ran into an interesting problem where a WPF application was acting really, really, really slow. So slow that moving the application window was jumpy. Selecting items in a grid would take several seconds. Scrolling a list box of simple items would grind the CPUs for a while. And even typing in a regular text box was so delayed that I could type a word, sit back, and every few seconds a character would appear.
The problem turned out to be with the input stack at the operating system. Seems that the Pen / Tablet Driver was bringing the system to its knees, but only affecting WPF applications.
Disabling the driver and restarting the WPF application instantly showed colossal speed improvements for response time; the application responded near instantly. Re-enabling the driver while the application was running reverted the system to the broken state, although turning the driver back off did not bring the WPF application out of it’s slow like crawl. Restarting the WPF application resolved the problem, but the driver had to be disabled.
(Test conducted with WPF 3.5 SP 1 and Windows 7.)
This is clearly one of those things I did to myself as a good idea, then forgot about, only to be plagued by it later.
I noticed that all of my photographs on my camera were reporting a copyright with a 2009 year inside the exif data.
I’ve been unable to figure out where it was coming from, resorting to exiftool to remote it.
My natural thought was that perhaps it was some preference in a photo editing tool or a geospatial locator tool. But, no. Turns out I did it to myself.
The Canon EOS Utility has a nifty ability to include a value for the Copyright tag. And about a year ago when I tethered it to the computer, I must have noticed this and set it to some precanned value that includes the year.
It looked something like this:
Copyright (c) 2009 by Walt Stoneburner, All Rights Reserved.
And ever since then, my photos were stamped with that value. Which was fine, back in 2009.
Fixing the problem was as simple as tethering the camera again and firing up Canon EOS Utility. It also gave me an opportunity to update the firmware.
Strange copyright exif data: mystery solved.