I stumbled upon this question asking about linq's aggregate algorithm and thought this is the kind of question that is best answered by reverse engineering, so I went to Visual Studio and wrote the following code (this code is meant to be used in a Compact framework project where the Combine function can only have two parameters):
public static string Combine(string path1, params string[] paths)
{
return paths.Aggregate(path1, System.IO.Path.Combine);
}
Then I set the cursor to the Aggregate method, pressed F12 key (I have Resharper installed), and was led to the following code:
// Decompiled with JetBrains decompiler
// Type: System.Linq.Enumerable
// Assembly: System.Core, Version=3.9.0.0, Culture=neutral, PublicKeyToken=969db8053d3322ac, Retargetable=Yes
// MVID: 77D23A6E-E19D-435B-9CBB-733D74F92072
// Assembly location: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\WindowsEmbeddedCompact\v3.9\System.Core.dll
Lots of stuff...
public static TAccumulate Aggregate<TSource, TAccumulate>(this IEnumerable<TSource> source, TAccumulate seed, Func<TAccumulate, TSource, TAccumulate> func)
{
// Stub method ('ret' instruction only)
}
Now obviously, this is not the code that runs when I call Aggregate since... Aggregate does something. The question is what exactly does this result from the decompiler means? And What would be an appropriate method to reverse engineer the "Aggregate" method?
--EDIT--
I just realized what I said above is only true when done in a Compact Framework project, when I decompile the standard framework's Aggregate I get the correct source code.
If you want to decompile CF assemblies, you have to use the actual BCLs, not the stubs that are typically used as a reference in Studio (and no, I don't have any idea why they did that). I see you're using 3.9, so I'm not certain the path you need to look at, but for 3.5, you can find them here:
C:\Program Files (x86)\Microsoft.NET\SDK\CompactFramework\v3.5\Debugger\BCL