The new entityframework ctp was released. The official statement is here.
It includes the designer, so I'm very curious how this fares against nHibernate! Congratz to the team!

The Devguy does a summary of the features. Read this hilarious piece:

• In previous CTPs the underlying provider connection was opened when the ObjectContext was constructed and held open for the life of the context—this would create issues, for instance, with databases where licensing was based on the number of concurrently open connections since the connection might be held open for an extended period of time—even when the connection is not being used.  The new model keeps the connection closed as much as possible while still appropriately dealing with transactions and avoiding promotion of those transactions from local to DTC where possible.

Really?

I mean, so, they now no longer keep the connection open all the time and instead have opted to close it when it's not in use..... because of licensing issues??

ROFL. I would think there are better reasons not to keep a connection open for too long, but that's just me.

Just ran across a comment from Daniel Puzey here, with the following excellent advise:

Often, by default, you'll get an error reported at Line 1 of the xaml, which is an obvious lie. You can catch the original exception, though:

- Open the "Exceptions" window (Debug/Exceptions) in Visual Studio.
- Click "add"
- Add "System.Windows.Markup.XamlParseException"
- Check the box to break on throw for this exception.
- Hit F5!

You'll find that the XamlParseException you catch is much more descriptive, and will give the correct position in the xaml file.

When we just started utilizing WPF we didn't like the way converters had to be created for every little thing you wanted. We looked into using jscript for this after a forum post by Jonathan. At that point, we decided against it. However, he went ahead and created a fantastic package which hasn't had enough exposure imho. So take a look here.

Basically, it will let you create inline code for simple converters. I wish I could use that now!

My team is scrambling to get a stable version of our application to our final test team! It's a very exciting time and things are going relatively easy. This is the time that small 'easy' things seem to work against you, as did a simple registry write:
Our application is a corporate intranet distributed xbap, which gets full trust by means of a certificate. It's users are all local-administrators (say whaaattt??). I needed to write a key to a registry and this worked fine in visual studio debug mode. However, once hosted, the application crashed, due to insufficient access to the registry. I checked the permissions on the key, and it had full control for administrators.

Giving the user group full control on the key did the trick. But why? I would have thought I had broken free of the sandbox by means of the certificate.

Chango V. from the WPF team explains:'PresentationHost.exe runs with a restricted process token. In particular, it gives up the SIDs for the Administrators and Power Users groups.'
That certainly explains it. Quite unexpected though. I probably haven't looked hard enough, but I couldn't find that in the SDK.

Also, he mentioned: 'Yes, this is a design flaw in our hosting process. You get "full trust" from CLR point of view, but not in terms of NT security. We'll try to address this issue in a future release.'

So there you have it. Keep that in mind when you develop full trust xbaps!