I’ve long thought that WPF Performance Tools for .NET 4.0 from the Windows 7 SDK was completely broken, the Visual Profiler never showed anything. Seems I just hadn’t done a good enough job when searching for a fix.
Now three years later I stumbled across a blog post at msdn.com about a TimeZone fix for WPF Performance Tools that fixed my issue.
Hopefully I’m not the only one having trouble with aggregates, Linq to SQL and empty results. The query I had was something like the following.
var result = (from v in db.Table select v.IntColumn).Max();
This fails with an exception if Table is empty.
The null value cannot be assigned to a member with type
System.Int32 which is a non-nullable value type.
So after some reading on MSDN I found the extension method Queryable.DefaultIfEmpty, it returns a collection with one element that has the default value of the type of the IQueryable<T> if the IQueryable<T> is empty, that looked like it could solve my problem. But I quickly found out that it is not supported by Linq to SQL.
Could not format node 'OptionalValue' for execution as SQL.
So then after reading a blog post about this I ended up with the following query that does what I want.
var result = (from v in db.Table select (int?)v.IntColumn).Max()
It has the side effect that the generated SQL query contains an extra nested select but I think that is acceptable.
SELECT MAX([t1].[value]) AS [value]
SELECT [t0].[IntValue] AS [value]
FROM [Table] AS [t0]
) AS [t1]
Had some trouble creating a patch with MsiMsp.exe version 4.00 yesterday.
ERROR: Cannot overwrite patch '%TEMP%\~PCW_TMP.TMP\tempcopy.msp'. Check the permissions to make sure that patchwiz will have access to the file. (Note, this path cannot be a folder.)
The mistake I had made was pretty simple, but the error message above sent me in the wrong direction when trying to solve it. I thought there was a problem creating the temporary file, silly me. The issue was instead that the directory where I wanted the output msp file to be created didn’t exist.
Solved a problem with a build script last week. I had somehow caused the build to under some conditions take a very long time to start with heavy disk IO. After reviewing some recent changes I found the cause.
I had a ItemGroup that looked something like the following.
Apparently MsBuild evaluates all ItemGroups even if the condition of the group or item evaluates to false. The result is just discarded if the condition evaluates to false. So the item above included all dll files on the entire hard drive when PathProperty was not set. By trial and error I found out that the condition of Choose elements are evaluated before the items they contain.
So to speed things up I changed the above to the following.
Is this behaviour obvious to everyone else? Couldn’t find anything about it while reading the conditions documentation nor the documentation on items and properties on MSDN.
I wonder who thought a list like this would be helpful for anyone looking for more information. 🙂
From Varieties of Custom Controls on MSDN.
No idea why this limitation exists, but apparently it is not possible to call pinvoke methods in a nested class from a method in a generic class.
I had something like this:
public class Foo
private class FooGeneric
private HandleRef handle;
private const uint SOMEMSG;
private void DoSomething()
NativeMethods.SendMessage(handle, SOMEMSG, IntPtr.Zero, IntPtr.Zero);
private static class NativeMethods
[DllImport(“user32.dll”, CharSet = CharSet.Auto)]
public static extern IntPtr SendMessage(HandleRef hWnd, uint Msg, IntPtr wParam, IntPtr lParam);
Just before DoSomething was called in my code I got a TypeLoadException with the message:
Generic method or method in generic class is internal call, PInvoke, or is defined in a COM Import class.
Solved it by moving the NativeMethods class outside of the generic class.
I’ve been using a service called Plaxo now. It uses a Outlook plugin that updates my adressbook as the other Plaxo users I am connected to changes their contact information. Very handy.
Unfortunately they added a very annoying feature in a recent update, a Plaxo folder was added to the root of the start menu. Since I like to keep my start menu organized and tidy I really don’t want that entry there and tried to move it. To my surprise the next time I started my computer the Plaxo item reappeared at the root. Not only do they add an item to my start menu without asking me and without letting me choose where I want it, it is restored during the check for updates done when I login to my computer. Argh! Why would anyone do something like this? It adds no benefits for the users that I can think of, and annoys people like me.
Plaxo support said it is a feature and it is unlikely it will change in future versions. So I was very close to uninstalling this otherwise very handy tool, but then a collegue at work gave me a little tip. If I hide the item it wont get added back. Said and done, I just set the hidden attribute on the startmenu item and now I don’t have to see it anymore.
So what I really wanted to say with this post is, please don’t mess with my start menu!
Update: Maybe my wording wasn’t all that great. What I ment was that the Plaxo item that is created is at the root of the All Programs part of the start menu.
While writing a Nant task that resolves a type library guid and version to a path using QueryPathOfRegTypeLib via pinvoke I ran into a bit of trouble. When I used my task the tlbimp task complained that it wasn’t given a valid path. Apparently an extra ‘\0’-char is added to the end of the string returned by QueryPathOfRegTypeLib. I couldn’t figure out why it was added, don’t think there is anything wrong with the pinvoke declaration I got from from pinvoke.net, so for now I just strip the last character of the path in the task.
So now I can build my projects from scratch even if they require an interop assembly without hardcoding the path to the type library used.
Update: Just saw that the guy who wrote the signature on pinvoke.net wrote a small note about this after I asked him about it. Link.