ljw1004 posted:

Could you go into more detail about that? TaskCancelledException (and the related OperationCancelledException) are fine in general, and they're what I expect to see if a CPU-busy-loop is listening to a CancellationToken, and on their own they do play fine with async/await and always have.

But if a web-related operation is ending in this way then it suggests to me the third party has implemented cancellation in a weird way. At best, I can imagine the third party API is leaving the web request open (i.e. consuming resources) even after it should have cancelled. At worst, well I have no idea what it's doing.

ljw1004 posted:

Please go into more detail about that, hopefully with a code snippet. I don't think what you're describing is even possible

ljw1004 posted:

I'd love to see a code sample. The general advice from the team behind HttpClient is to reuse the heck out of it since that's more efficient -- go ahead make a singleton global instance. And the only time you can't do that is when you're doing the per-instance customization of it (I forget which customizations are per instance). I wonder if the third party API is doing such customizations under your feed?

ljw1004 posted:

If you simultaneously fire off a large enough number of requests that they have to queue up, and one of them times out, then BY DEFINITION all the ones after it in the queue will also time out. (assuming that timeout is measured from the timepoint that the request was fired off until the timepoint that the request was delivered).

Are you sure you're observing that all pending requests are failing? (i.e. including the requests that were fired off prior to the one that timed out?)

Or are you merely observing that all requests issued after the timeout one and hence pending are failing?

B-Nasty posted:

Bad, at least how you described it. It sounds like you're trying to develop your way out of a cost/infrastructure challenge, and underestimating how much time and frustration that will involve for your dev team. Unless your app is fairly trivial, of course.

At this point in time, I don't see a ton of compelling reasons to switch a large, working ASP.NET 4.X application to Core, but I would consider anything green-field to be work taking a look.

Drastic Actions posted:

Have you tried running it on Mono? ASP.NET compatibility with Mono can be iffy but it might be worth trying that to see if what you have right now just works on Linux, rather than rewriting it at all.

ASP.NET Core is a not a simple upgrade from 4.6. It's going to probably require a bit of work to move it over, depending on how complex it is. If you want to run it on .NET Core, that would mean having to upgrade to EF Core (I think EF 6 can be run on ASP.NET Core, but only if you run with the full .NET Framework or Mono), and that would require a bit of refactoring too, and it's also not exactly production safe just yet IMO.

ljw1004 posted:

Red Mike, my team at Microsoft is the one dealing with adoption and migration of .NET and .NET Core. If you'd like to run over your handy list with us, or discuss in more depth, send me an email at lwischik@microsoft.com. Same goes for anyone else of course.

GameCube posted:

Looking at the code you suggested made me realize one more thing I don't understand yet - what actually happens when you call an async function without awaiting it? Does it get executed on a background thread? I'm coming from very multithreaded C++ projects where concurrency was a nightmare and I'm just now realizing that I might not have to worry about it at all now.

ljw1004 posted:

When you're writing library code which might be called from any synchronization context, you have to watch out for this. When you're just writing a UI or ASP.NET app, you can really take full advantage of the single-threaded timesharing nature where it only ever yields at "await" points. That liberates you to no longer have to use thread-safe datastructures

chippy posted:

I miss working with Dapper actually. Unfortunately the project I'm working on currently already used EF so I had to roll with it.

OK, another async question for me.

Why can't I do this?
[/code]

On the bolded call, I get the compiler error "Since this is an async method, the return expression must be of type 'Foo' rather than Task<Foo>'. I have to add an await to the return to make it 'return await DoARelatedThing(aBar, baz)'. I don't understand why. Both methods return the same type, so why can't DoAThing just return the result of DoARelatedThing?

Mr Shiny Pants posted:

So we are back to using plain old webrequests? There was someone in this thread who also had a weird problem with HttpClient killing all the outstanding requests on an Exception.

Furism posted:

How do I do that in a WebAPI project (the ASP.NET Core version, I guess that's technically ASP.NET5)? Won't the instance be destroyed as soon as the Action is done? Would it work is Dependency Injection?

Chamook posted:

If you create a class that implements IHttpControllerActivator you can use that instead of the default for creating your controllers on each request, you can then create a HttpClient on app start and pass that into the constructor of your ControllerActivator so you use a single shared HttpClient for the lifetime of your application.

chippy posted:

It's pretty great. You might want to consider adding DapperExtensions. It adds basic CRUD, async/await support and some other useful things, notably it makes mapping one to many queries to objects easier which, trust me, is a loving ballache in vanilla Dapper.

Bognar posted:

Does it still deserialize an object for every single row, then throw it away if it's a duplicate?

EssOEss posted:

When you say one to many query mapping in this context, what exactly do you mean?

KoRMaK posted:

I'm woring in C# (for a Unity game) and I have a bunch of boiler plate code that multiple objects need. Inheritence doesn't really seem to be a great solution, and I'd rather use a mixin (pulling from my Ruby programming day job here)

Well, those don't exist in C#, ok fine I'll do a macro. gently caress, those don't exist either. And Interfaces don't seem like they allow for the method to be defined on the interface - defeating the purpose because I'll have to redefine the same friggen method in every object.


Anyway, how do I do mixins-ish programming in C# so that I don't have to keep copy/pasting the same 3 line method over and over?

Duct Tape posted:

Yeah, this is my stance as well. I was just worried that I was unintentionally breaking the state machine for more-complex methods by not wrapping trivial results in Task.FromResult. Doesn't sound like that's the case, though.

Night Shade posted:

It makes exceptions throw immediately, instead of faulting the returned Task. This normally isn't a huge deal if all you're doing is

code:

try {
  await thing();
} catch (...) {}

but if you're doing something like using .Select() to turn a list of urls into a list of parallel downloads, having exceptions propagate immediately will interrupt iterating the list. This prevents assigning the result of .Select(), which will leave you with orphaned tasks that iirc will crash your app if they fault and then get collected.

Night Shade posted:

Setting the contrivance of .Select(DownloadParallel) aside, if you're kicking off parallel Tasks at some point in the call chain you need to not be awaiting them immediately regardless of how smart the Task-returning method is. This makes the difference in exception propagation significant. e: because i can trust that an async method won't throw until the Task is observed and is therefore safe to pass directly to .Select / Seq.map / whatever. I can't say the same about a non-async method that happens to return Task.

quote:

ljw1004 posted:

I don't think that's right...

Up to VS2012 (.NET4), a task that ended in the "failed" state and which was never observed (i.e. no one ever did .ContinueWith on it) would raise the global unhandled exception handler.

But as of VS2012 (.NET4.5), once async/await was introduced, that behavior didn't make sense. So we removed it. We specifically wanted to support patterns like this, which never signs up anything for after JonesAsync.

code:

try {
  var task1 = FredAsync();
  var task2 = JonesAsync(); // kick them both off at the same time
  await task1; // but imagine if this throws!!!
  await task2;
} catch (Exception e) {
  Console.WriteLine("oops"); // at this stage JonesAsync has never been observed
}

That's entirely unrelated to the question of exceptions thrown inside async void....

code:

async void Button1Handler() {
  await Task.Delay(1);
  throw new Exception("oops");
}

An exception here will cause the exception to be rethrown inside the current SynchronizationContext: https://referencesource.microsoft.com/#mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs,223b5f320d791728

What does that do? It varies. I remember trying it inside WPF, Winforms and UWP (each have their own slightly different synchronization context). I remember that there were different behaviors between the three -- ignored? pop up an error dialog? terminate the program? -- but I can't remember which. I think they all involve the unhandled exception filter first.

What does it do when there's no synchronization context, i.e. it hits the threadpool? I think that goes down the unhandled exception filter route and then terminates the program, but can't remember.

What does it do in the ASP.NET synchronization context? I don't know.

Night Shade posted:

e: actually if Select blows up you may well be left with work happening inside Tasks that you no longer have any way of dealing with unless you've got a CancellationTokenSource you can use to abort them.

Shy posted:

Is there a way to create publishing options for plain .net framework console applications that would copy build output to a predetermined ftp location or a local directory, like web apps? The only option VS offers me is ClickOnce which doesn't look good. I could simply copy it myself but the task is to simplify the process so that me and other developers could deploy different configurations without loving up configs and locations over and over again.

quote:

It is important to note that a method is not generic just because it belongs to a generic type, or even because it has formal parameters whose types are the generic parameters of the enclosing type.

quote:

The common language runtime considers nested types to be generic, even if they do not have generic type parameters of their own.

Rocko Bonaparte posted:

I'm still looking over what I can do to change the entire approach in the larger post. For one, I am seeing how I am currently looking up these static instances since I've lost track of it.

But about this particular mess: I'm trying to remember what made me wind up doing this. I think I was trying to make a compile-time binding to DefaultNew instead of trying to get it dynamically using GetMethod(). There's a few places where I gave up and used GetMethod() because the signatures were async and I couldn't use an expression tree for them. It ultimately hasn't turned out to be so bad; it's a simple one-liner versus this code salad. It's just I get kicked in the dick if I type the method binding wrong and I'm very good at making that particular kind of typo.

Edit: I might as well append on to here about my recall on the whole static Instance thing. The main place where I'm using that Instance is every time I create an instance of the actual object type. That's the TInst generic argument in my example. Every instance of an Pythonlike object needs to have an association with its class. If you are a Python person, you can see that as the __class__ dunder in any instance of an object. That becomes useful for issubclass() and isinstance(). This is looking like premature optimization, but I'd prefer to avoid a dictionary lookup in every constructor if I can avoid it. On the flip side, the alternative is that boilerplate garbage that I'm liable to copy-paste then forget to properly alter for the new class.

Mr Shiny Pants posted:

And if one of these errors out, it will take all your other outstanding requests with it if I am not mistaken. Or did they fix that?

epswing posted:

Lock vs Monitor.TryEnter

NihilCredo posted:

dotnet tool install dotnet-svcutil && dotnet dotnet-svcutil <url to WSDL file>

I invoke SOAP services from .NET Core on Linux by pointing to WSDLs. There are various flags for stuff like generating sync methods, implementing INotifyPropertyChanged, etc.

Mr Shiny Pants posted:

I don't really like the HttpClient to be honest, and I like that I can just create a HttpWebRequest from scratch using the "obsolete" APIs.

Is there any reason I need to switch? I mean, System.Net is pretty bulletproof by now right?

Mr Shiny Pants posted:

I get that, and some things it does well (Forms and the like) but for just getting a reply from an endpoint I really like just being able to create an async method from scratch and know where all the stuff is getting used.

I really like being able to do:

code:

let getAudio text = 
    async {
        let request = System.Net.WebRequest.Create(buildUrl(text)) :?> HttpWebRequest
        request.Method <- "GET"
        let! response = Async.FromBeginEnd(request.BeginGetResponse, request.EndGetResponse)
        return response.GetResponseStream()
    }

fuf posted:

Does anyone have big thoughts on Rider vs Visual Studio, especially for blazor development?

I keep flipping between the two and can't really settle on one.

Rider seems to be a lot faster and smoother than VS.

But one thing I really like about VS is the code suggestions. Not just normal intellisense but when it will suggest an entire line for you based on the previous lines. Sometimes I'm amazed how accurate and helpful it is. I can't figure out if Rider has something similar?

I use the vim extensions for both which adds some complications. I sort of half-learned vim about 15 years ago and now I'm stuck with it even though I'm not that good at it.