Here's an example of mis-use that looks correct and how the code should seemingly work:

var anEmail = new MailMessage(yadaYadaYada); // settings cruft omitted for brevity
foreach (var thingToEmail in GetThingsToEmail())
{
  using (var stream = thingToEmail.OpenStream())
  {
    var attachment = new Attachement(stream);
    anEmail.Attachments.Add(attachment);
  }
}
anSmtpClient.Send(anEmail); // BOOM-Streams are closed so exception is thrown

Well that sucks, right? We could write some ugly try..finally code and keep a bag of the streams and then iterate them in the finally and call dispose
OR
we can keep the simple pattern above and still work with the API limitations with this handy little component:

var anEmail = new MailMessage(yadaYadaYada); // settings cruft omitted for brevity
using (var scope = new AggregateDisposable())
{
  foreach (var thingToEmail in GetThingsToEmail())
  {
    var stream = thingToEmail.OpenStream();
    scope.Track(stream);
    var attachment = new Attachement(stream);
    anEmail.Attachments.Add(attachment);
   }
  anSmtpClient.Send(anEmail); // Happy happy Joy joy
}

And Bob's your uncle. Just because I happen to be a very nice guy I have provided a nice overload that actually allows you to materialize the IDisposable component, track it, and set it to your choice of variable in one go like this=>
var stream = scope.Track(() => thingToEmail.OpenStream());

Well there you go. Enjoy!

AggregateDisposable.zip

http://blogs.msdn.com/b/webtopics/archive/2009/01/19/service-principal-name-spn-checklist-for-kerberos-authentication-with-iis-7-0.aspx

Basic Usage:

var myContainer = new WindsorContainer();
myContainer.Facilities<AutoFactoryFacility>();

// initialize your container registerations

var foo = myContainer.Resolve<IFoo>();
Debug.Assert(foo != null);

var fooFactory = myContainer.Resolve<Func<IFoo>>();
Debug.Assert(fooFactory != null);

var foo 2 = fooFactory();
Debug.Assert(foo2 != null); 

AutoFactoryFacility.cs

WriteOnlySet{T}.cs

Turns out most people were only thinking that you could execute SQL strings only as opposed to detailed parameterized SQL statements. That's not correct. It's all supported and approved.

Scenario 1. Using Parameterized SQL statements

So this covers selects as well as invoking sprocs. If you have named parameters in your sql string EF is more than happy to take them and set values based on some very simple rules.

1. The SQL contains a parameter name value markup item (e.g. @ParamName) in the query iteself OR
2. The SQL contains a .Net format string replacement token (e.g. {0}

public IEnumerable<T> SqlQuery<T>(String sql, params SqlParameter[] parameters)
{
 return parameters == null 
 ? this.Database.SqlQuery<T>(sql)
 : this.Database.SqlQuery<T>(sql, parameters.Cast<Object>().ToArray()); // Removed covarient by creating Object array
}

--declare @sql nvarchar(max) = 'execute mySproc @value' EXAMPLE SPROC EXECUTE STATEMENT
declare @sql nvarchar(max) = 'select newid(),@SystemName'
declare @value nvarchar(max) = N'an input value;

DECLARE @ParmDefinition nvarchar(500) = N'@value nvarchar(500)';

-- define the table variable to hold the query output. In this case I could
-- have performed modification from the underlying sproc result set but I didn't

declare @results TABLE(
SystemId uniqueidentifier,
SystemName nvarchar(500)
)

-- Execute the sproc and fill the table variable with the output
INSERT @results
execute sp_executesql @sql,@ParmDefinition, @value=@value

-- Return the values coerced to your desired shapre.
SELECT SystemID, SystemName [Name] FROM @results

HE SHOOTS HE SCORES!! So engoy your EFing journey out there
folks and remember, think about your entire toolkit when solving problems!

Written in 2005 and references Visual Studio 2003 but points still hold.

tdd.zip

Let's start with this simple axiom:  DO NOT BUILD YOUR OWN QUEUING SYSTEM UNLESS THAT'S WHAT YOU ARE HIRED TO DO!

By the time you get it designed, debugged, and actually working you'll find that you've just spent your entire dev budget on something that probably doesn't even have half the real features of MSMQ (or any other vendor product). And I am not talking about little used fringe cases you don't need. I am talking about core infrastructure requirements for asynchronous communication infrastructure: Poison message detection, scale out, manageability tools, WMI and monitoring, QoS, and on and on...

Personally I think that the reason that people shy away from MSMQ is simple and clear: the documentation sucks, real working samples are rare, the features have quirks that are not always known, and lastly asynchronous message based solutions are hard. Well, I cannot fix the last item, hard is hard and unless you know how to design a Saga based solution you're going to have trouble. But the others are not hard, they just need explaining and simple working solutions to show how it works. With that being the case I am going to show the most basic of systems, a client and a server leveraging WCF with MSMQ. Attached to this blog is a very simple application that allows a client to fire and forget a WCF message and a service to activate and transactionally process it. I believe that this code and configuration should be clear enough (there's little to it!) and should "just work". Just make sure that you have MSMQ installed on your machine and run Visual Studio in elevated admin mode (so you can create MSMQ objects on your first run).

MSMQ Example.zip

thanks to Scott Adams and his wonderful wit!

Powershell: finally a real scripting environment (those of us refugees from the Unix Wars finally can feel whole again) in windows but one that works in real live .Net objects!
Remoting: like telnet without the craptastic-ness leveraging WS-Management as infrastructure marshaling commands / responses securely across the network.

This is pure bliss - almost as if I was back in BSD again!

Now there's plenty of stuff on the interwebs about how to work with remoting sessions interactively. There's also some information on how to work with powershell's automation API (read: your CLR code is running and hosting powershell directly in process). What it doesn't seem is that there's any examples of working with powershell automation with a remote session out there. Or if there are, they are not working in what I expect is the most common use case:
- Machines in Active Directory with Trust relationships leveraging Kerberos for the interactive user credential

So to fix this I've gone and whipped up a small sample application that will show you the extra "bits" you need to use / configure to remote your automation applications. This post expects that you have a working understanding of powershell and the automation API (or at least can get the essence of it from the very understandable API).

As anyone performing automation knows your entry point to hosting powershell lays in the System.Management.Automation assembly (This is normally found in the %Program Files x86%\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0 directory). The first thing you need to do is to figure out what computer you are going to connect to and build the appropriate Uri for the WS-Management endpoint. There's scant information on this out there but basically the format is "<Scheme>://<ServerName>:<Port>/wsman". The two schemes that are supported are "http" and "https" and by default the management port will be 5985. editorial note: this port can be changed. Don't do it! So let's see some code:

var remoteComputer = new Uri(String.Format("{0}://{1}:5985/wsman", Scheme, ComputerName));

From there you need to create one of the RunspaceConnectionInfo types. There are two that come out of the box, NewProcessConnectionInfo and WSManConnectionInfo. You'll want the latter (obviously). This type has a constructor with a plethora of overloads. For the curious you have options to supply the PSCredentials here as well which is great if you have the credentials for the user to connect as which great if they need to be different from the interactive user OR you need to perform a double hop and Kerberos Delegation is not enabled.

var connection = new WSManConnectionInfo(remoteComputer);

From there you need to create a runspace (pretty much par course for powershell automation) and supply your connection object and then open the connection.

var runspace = RunspaceFactory.CreateRunstpace(connection);
runspace.Open();

From there create your powershell instance and bind it to the runspace (note: this is an IDisposable class so wrap it in a using statement or other construct)

var powershell = PowerShell.Create())
powershell.Runspace = runspace;

From there it's all the standard powershell automation calls you are already familiar with (e.g. AddCommand, AddScript, Add* methods). Here I'll just assume I have a command already built in a string variable and will invoke it, returning the output of the command (as a collection os PSObjects).

powershell.AddScript(command);
var results = powershell.Invoke();
foreach (var output in results.Where(o => o != null)
{
  Console.WriteLine(output.ToString());
}
//Assume we're done
powerrshell.Close();

And that's that! As you can see there's really no mystery in combining Powershell Automation and Remoting. It's very straight forward to use and accomplish; In all likelyhood you'll spend more time getting your Powershell statements correct than worrying about automation issues =D). Now do be aware that you need to enable powershell remoting and all the appropriate firewall/security settings on the target computer. All this can easily be handled by the WinRM service with a handy and easy configuration statement. Simply run (on an elevated command prompt if UAC enabled) "WinRM quickconfig" and it will prompt you to make the required configuration changes with the default values. It supports a quiet mode and the ability to supply all parameters via the command line which is important say for installers and whatnot.

I've put together the world's ugliest console application to show off listing files in a given path on a specified computer via Powershell Automation Remoting.

PowerShell Remoting.zip

where the set of D is dimensions and the set of M is measures. Let F(x) calculate the number of members and G(x) the size of the member.

Debate.

 edit: I should have noted this is the approximation of the size. Depending on storage system there's obviously overhead to this.