In my experience with running Queries in .NET apps vs. Query Analyzer is that most don't actually call the Procedures or Ad-hac queries in the same way. For example, it IS a best practice to always use a "parameterized command" in .NET, this way you code will hit the same Cached Plan REGARLESS if it's ad-hoc or a Stored Procedure being called.

So, imagine I have a .NET app that is using a Parameterized Command. And on the 2nd call it retrieves a much bigger data set than the 1st call. In this case, it will use the same cached plan because the only thing changing is the command parameter values. Howedver, in Query Analyzer, most don't take the time to actually declare "variables" for their ad-hocs there, and instead call the Procs by explicitly setting values on it.

Example:

SqlCommand command = new SqlCommand;

command.CommandText = "spGetData";

command.CommandType = StoredProcedure;

command.Parameters.Add(...);

command.ExecuteNonQuery();

// This execution always hits the same plan

-- Now for Query Analyzer

Exec spGetData '01/01/2006', '01/01/2007

-- This will NOT use the same plan if other dates are used

-- because the parameters are changing

Declare @Date1 DateTime, @Date2 DateTime

Select @Date1 = '01/01/2006', @Date2 = '01/01/2007'

Exec spGetData @Date1, @Date2

Select @Date1 = '01/01/2006', @Date2 = '01/01/2008'

Exec spGetData @Date1, @Date2

-- This WILL use the same query plan and could potentionally be slower...

All I'm saying is that you should be careful how you are testing the speed and query plans. You can't blame a .NET everytime something is slow. I am agreeing with the "WITH RECOMPILE" option, but I also might try to prepend a "Merge, Hash, or Nested" Join clause in my joins if I could find an optimal solution that way.