The biggest improvement is that it now designed and tested to work in a multi-threaded environment.  Previous releases of SQL CE only worked in client-apps and would corrupt/crash in server environments.  SQL CE 4 specifically supports server scenarios.

We also now support shared hosting and medium trust - which wasn't supported before.  We are also updating SQL CE's SQL support to be more compatible with SQL Server and enable easy optional migration.

Hope this helps,

Scott

The announcement of "New Embedded Database Support with ASP.NET" is enough to make me yawn. What is great is that it is actually SQL CE 4 and has the major improvement of allowing multi-threaded access.

Believe me, it is a pain to ensure single-threaded access in a multi-threaded app with needed continuous access to an embedded database. Especially when you didn't realize that random corruptions happen with multi-threaded access.

Careful with those enumerables

Ever since .Net 2.0 introduced the yield keyword for creating enumerators, and even more after the introduction of LINQ in C# 3.0, I've seen more and more APIs return IEnumerable<T> instead of IList<T> or ICollection<T> or their older cousins the ArrayList and the array object.

That makes sense most of the time, especially for collections that aren't meant to be modified, and choosing between those different return types is not what I'm about to discuss here. You can find endless articles and threads about that.

I'm a big sinner when it comes to IEnumerable. Need to remember that lazy evaluation can lead to unexpected side-effects.

Events get a little overhaul in C# 4, Afterward: Effective Events

In Parts I, II, and III, I talked about the slight changes that we made to field like events, to the += and -= event accessor operators, and how this may affect you. Just so we’re all on the same page, I want to consolidate here a list of Dos and Don’ts so you know how to use these language features effectively and safely.

This is a good summary of how to use events in C# 4. Especially good to know if you like to have Warnings As Errors on (which you should).

Oh, right—sorry, I forgot. That devil will whisper, "You know, if you write this code in Visual Basic .NET, you can make the entire codebase Option Strict Off and Option Explicit Off, make the compiler shut up and you can go home early...." Hell, they've been whispering that bit of subversion since 2001. And ye Gods! The leveled cities! burned forests! cute little kitten bodies! all over the place! It's fortunate that we C# developers have kept all those Visual Basic developers on the straight-and-narrow path of true salvation static typing.

Maybe I am a static-typing fundamentalist, but you cannot say that the "dynamic" keyword in C# should be used in anything except Javascript/COM interop situations (okay, there are probably others, but it is a specialized case).

The author argues (and whines) that VB (something else I wouldn't hang my hat on) made people much more productive than C++. It did, but they had worlds of differences between them. VB.NET and C# have near zero. C# just shouldn't have dynamic/duck typing. If you want that, THEN USE ANOTHER LANGUAGE.

At least, he concedes there are different tools for different jobs. Unit testing is an area that a dynamic language excels in. I simply hate using a loosely typed anything in any kind of project that involves more than one person. Tribal styles of coding develop too easily.

Dynamic languages have their place. Just not in my C#, thank you.

Added unexpected feature: Streams for single and multipart archives. They must be seekable however. Maybe non-seekable streams soon when someone asks.

Another minor bugfix. Ran into this myself when I was trying to convert CBR files to PDFs. Spent so many hours chasing this down.

Until recently your only choice for developing applications for Apple’s iPhone was to jump into the Apple development ecosystem. This means being willing to write Objective-C code in the XCode IDE. For many developers, learning Objective-C was seen as a huge barrier-to-entry. This is especially true for many .NET developers whom have never had to worry about memory management, pointers, and other C language responsibilities that they are unfamiliar with.

Very long and good. I've only read the first bits and skimmed the first. Bookmarking for myself for later.