I attended several interesting sessions; from HTML microformats, to Ruby on Rails, to WPF and Microsoft Expression Blend.
Scott Guthrie was the man of the day: large throngs of developers vied for seats in his sessions. His talk on WPF/E was extremely interesting. He was bombarded with questions from all of us and, while he obviously had to "chest his cards" about Microsoft's strategy, he did drop a few hints.
Things I took away from the session include:

• WPF/E is currently cross-platform (Windows and Mac OSX) and cross-browser (IE, Firefox, Safari). Linux isn't currently supported because a) there are so many different distributions, and b) although Linux has a lot of penetration on the server market, it doesn't have a big client presence; WPF/E is obviously a client technology. However, MS will support a Linux version in future if there is significant demand for it.
• Right now you can only use JavaScript with WPF/E and it doesn't support layout management and other advanced controls - however this is going to change as WPF/E will be getting a version of the CLR and some of the .NET Framework. So we be able to use C# in Safari!
• Following on from that, and reading between the lines a little: expect the .NET Framework in general to pitch up on Mac OS X. In my opinion, this is the single most exciting development of the century. Yes, forget the breakthroughs in stem-cell research and cognitive neuroscience: Microsoft is committed to going cross-platform. I've been waiting for this news since I first saw the promising Environment.NewLine property (which claims to return 'a string containing "\r\n" for non-Unix platforms, or a string containing "\n" for Unix platforms.')
• WPF/E isn't hardware accelerated - it's software-only. So there is no 3D support in WPF/E. However, Scott's cheeky grins and evasive diplomacy seemed to indicate that in a future rev we could expect hardware acceleration and all the wholesome goodness that comes with it.

The session was recorded, and will be available online - but no link as yet.

The day ended with drinks at a bar and a "geek" dinner which was enjoyable and great for networking. We've gotta find a better name for these "geek" dinners. I'm sure I'm not the only developer who doesn't like to think of himself as a geek. How about Dev Dinners?

I ALWAYS forget that you need to include the BindingFlags.NonPublic flag!

Consider defining a structure instead of a class if instances of the type are small and commonly short-lived or are commonly embedded in other objects.
Do not define a structure unless the type has all of the following characteristics:

• It logically represents a single value, similar to primitive types (integer, double, and so on).
• It has an instance size smaller than 16 bytes.
• It is immutable.
• It will not have to be boxed frequently.

If one or more of these conditions are not met, create a reference type instead of a structure. Failure to adhere to this guideline can negatively impact performance.

See Choosing Between Classes and Structures

• stack allocated instead of heap allocated
• value types instead of reference types

But that doesn't really help you when deciding whether to use them or not. And besides, I read somewhere (can't remember where) that the CLR optimizes heap allocations to the extent that the performance benefit of stack allocated structs is almost negligable over heap allocated "objects" (class instances).

So I've largely avoided structs. Today I found an article that kind of vindicates this decision - although for a different reason. It claims (and while I'm not sure of the authority of the author, he/she makes a good case) that structs should not be used because they violate the Principle of Uniformity. You can read it here:

http://www.geocities.com/csharpfaq/structs.html