In general, mocking out the Entity Framework DAL is a big pain to accomplish. ObjectContext has no interface and the T4 templates aren't written to create interfaces for the objects they create.

This hampers good unit testing and makes them less injectable.

Put an interface on ObjectContext. Have the T4 Templates put interfaces around all of the objects that are generated and make sure that all objects used have interfaces so that mocking frameworks, like MOQ or Moles & Pex can automatically generate stubs to replace the objects in unit tests so that tests don't need to be tightly coupled to the database.

Many cryptographic hash and encryption functions take advantage of circular shift:

(val << shift) | (val >> (32 - shift))

Modern C and C++ compilers recognize this expression, and compile it accordingly to X86's ROTR/ROTL instruction. I believe the .NET runtime should be able to recognize the IL sequence that the above expression would generate:

ldloc val
ldloc shift
shl
ldloc val
ldc.i4 32
ldloc shift
sub
shr.un
or

And optimize that sequence into a single X86 ROTR/ROTL sequence.

I'm pretty sure it doesn't do that now, according to my experiments.

The best thing to do is to introduce some sort of ROTL/ROTR instruction into CIL itself, but I gather that entail much more work than performing an optimization pass over the CIL and looking for that sequence.

ARM supports circular shift via the ROR instruction (a left-rotate is the same as a right rotate), so the Windows Phone/8 Table platforms support this optimization as well!

At present the CLR only loads satellite assemblies if they are signed with the same key as the fallback assembly to which they refer. This means that the only people that can add new cultures to an existing assembly are the original authors. This includes the .NET Framework itself, ASP.NET MVC, Silverlight and every signed assembly released by Microsoft (or indeed anyone else).

The .NET Framework 4 is currently available in 23 languages (plus English). ASP.NET MVC 3 is currently available in 9 languages. If the language you want isn't on this list then there is nothing you can do to add support for your language. As an example Welsh is not on either of these lists.

I suggest that the way the CLR loads satellite assemblies is changed. Authors of assemblies could add an attribute to their assembly indicating that they accept relaxed rules on loading satellite assemblies. Hereafter the CLR would load any satellite assembly that matches the parent except for the key with which it is signed.

The consequence is that it would allow the author of the assembly to grant other .NET developers the right to add new culture support to existing assemblies. For example I could create my own Welsh resources for the .NET Framework and/or ASP.NET MVC. Furthermore it would allow my company the option to allow other developers to add additional language support to our products without returning to the development team to sign their satellite assemblies. This makes the post-build localization model much more realistic.

One caveat that I suggest is that the CLR would only load the satellite assembly if it contains resources only (i.e. no executable code).

If you run a .NET app that needs to talk to the web, and you're behind an authenticating proxy server, then that app will fail to talk to the web.

Internet Explorer and Google Chrome work, Visual Studio and loads of other Microsoft apps will work. They can all talk to the web. But every .NET-based app or website I've ever seen will fail.

The implications of this are profound. I've seen umpteen forum posts over the years where people are scratching their heads, wondering what's wrong. I've seen IT guys re-route their users thru special-case connections to the web, because the user has to access some web functionality.

I've installed a piece of software that needs to authenticate a license key over the web... only to fail. And then you have to call their support lines.

I've seen Umbraco and Orchard CMS users fail to access the online galleries of themes and widgets. No-one - developers, users, IT guys - have a clue what's wrong or how to fix it.

Even Microsoft's .NET apps fail: if I try to run WCF's svcutil.exe on a remote service, it will fail... because I'm behind an authenticating proxy server.

And yet the fix is so simple. Simple, but no-one knows about it... no-one! Take a look at this StackOverflow question:-

http://stackoverflow.com/questions/299940/how-should-i-set-the-default-proxy-to-use-default-credentials

The simple, simple fix is to add this to your .NET app's app/web config file:-
<system.net>
<defaultProxy useDefaultCredentials="true" />
</system.net>

But since no-one knows about this, let's end the years of confusion and have .NET 4.5 change the default value of useDefaultCredentials from false to true. Problem solved, and everyone can get on with their lives.

If Internet Explorer "just works", why can't .NET-build apps "just work"?

And for a better-argued case, see here:-
http://sticklebackplastic.com/post/2007/01/26/Poxy-proxies.aspx

Thank you.