Sounded like you were including linq to objects also in your second two sentences, but I misunderstood.
IIRC
.AsEnumerable() and .ToList() themselves execute a new query
yeah thats not ideal
I wonder if that's a Roslyn thing or if it's in the closed-source .NET Core debugger
if i recall at least 99% of the time that i run into this issue its because i want to just verify that some specific record is making its way through a piece of logic (as a means of troubleshooting for example), and hovering over the
IQueryable while stopped on a breakpoint, and attempting to enumerate the thing there and then, either takes an extremely long time, breaks, or there are so many records that scrolling through the little inspector window/widget to find the record is not feasible
Unrelated, but the new feature I use all the time now is https://docs.microsoft.com/en-us/visualstudio/debugger/autos-and-locals-windows?view=vs-2019#pin-properties-in-the-autos-or-locals-window
(also applies in the watch window and debugger tooltips)
without enumerating the object within the compiled source before debugging
i'll have to try to be sure
It enumerates all entities tracked as added, unchanged, or modified (https://docs.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.dbset-1.local?view=efcore-3.1)
So it would only contain entities that were loaded before you paused in the debugger.
https://www.nuget.org/packages/jnm2.ReferenceAssemblies.net35 is far and away my most popular NuGet package
It's probably going to speed up now that the msbuild repo is going to use it in its infrastructure: dotnet/msbuild#5621
(I found the decision not to include net35 in https://www.nuget.org/packages/Microsoft.NETFramework.ReferenceAssemblies deeply unsatisfying. It irked me into action. Over conference WiFi in Las Vegas even.)
Since July 8. That explains some things. dotnet/roslyn#45690
I'm still waiting for someone to be mad and come after me. I have a trick up my sleeve the moment that happens.
There is a list of people who appear not to be mad about it, so I'm still wondering who originated the directive that net35 should not be officially buildable by the .NET Core SDK. Especially given that net35 is a supported OS component, and net20 and net40 (which are buildable by the .NET Core SDK) are out of support. Hopefully we can still be friends.
126k very nice :o
126k should be compared to the 3.5m of the https://www.nuget.org/packages/Microsoft.NETFramework.ReferenceAssemblies that should have included it
s/folks/builds
class Program {
static void bar(Action<IComparable> f) => f(15);
static void Main(string[] args) {
// This cast can die at runtime, and that's ok.
bar(ic => {
int d = (int) ic;
Console.WriteLine($"Hello {d + 2}");
});
// This could be shorthand for the same thing.
bar((int d) => Console.WriteLine($"Hello {d + 2}"));
}
}is variable.
"If this would have failed, consider overloads with delegates where a single explicit cast to
int exists"
I don't like making the explicit cast implicit at all.
You could do
bar(Utils.CastAction<object, int>(d => ...))
Here’s a real example (from Java).
valueProperty.addListener(observable -> {
BooleanProperty b = (BooleanProperty) observable;
toggleButton.setSelected(b.get());
});or
valueProperty.addListener(observable -> {
toggleButton.setSelected(((BooleanProperty) b).get());
});or
valueProperty.addListener(BooleanProperty observable -> {
toggleButton.setSelected(observable.get());
});