.NET Megathread 3.5: await GetGoodPosts()

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›300 »

mystes: May 31, 2006

CapnAndy posted:

Okay, but what am I supposed to do about it? I don't even want to be calling the dang website asynchronously in the first place, the code's not doing anything until it gets that data, but HttpClient only frigging has GetAsync for reasons that are certainly beyond me.

Then get rid of task.run and just use .result?

# ? Jan 19, 2021 22:37

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 22:05

CapnAndy: Feb 27, 2004; Some teeth long for ripping, gleaming wet from black dog gums. So you keep your eyes closed at the end. You don't want to see such a mouth up close. before the bite, before its oblivion in the goring of your soft parts, the speckled lips will curl back in a whinny of excitement. You just know it.

mystes posted:

Then get rid of task.run and just use .result?

Tried that first, it still merrily busts the try/catch because the error's in the async thread. Task.Run is me trying to force the entire thing onto one thread so I can catch the errors that sometimes come up during GetAsync, because I have no idea what's even triggering them, let alone how to prevent it, because it's outside the error handling.

# ? Jan 19, 2021 22:40

Ola: Jul 19, 2004

Can't you just go like this?

code:

try
{
	result = await client.GetAsync(url);
}
catch (Exception ex)
{
	//error handling
}

The calling function becomes async which may bubble up and cause some headaches.

# ? Jan 19, 2021 22:55

CapnAndy: Feb 27, 2004; Some teeth long for ripping, gleaming wet from black dog gums. So you keep your eyes closed at the end. You don't want to see such a mouth up close. before the bite, before its oblivion in the goring of your soft parts, the speckled lips will curl back in a whinny of excitement. You just know it.

Ola posted:

Can't you just go like this?
code:
try
{
	result = await client.GetAsync(url);
}
catch (Exception ex)
{
	//error handling
}
The calling function becomes async which may bubble up and cause some headaches.

It does bubble up, but I think it's worth trying and I'll risk the headaches. Good idea, thanks.

# ? Jan 19, 2021 23:09

rarbatrol: Apr 17, 2011; Hurt//maim//kill.

CapnAndy posted:

Task.Run is me trying to force the entire thing onto one thread so I can catch the errors that sometimes come up during GetAsync, because I have no idea what's even triggering them, let alone how to prevent it, because it's outside the error handling.

Task.Run really only forces execution onto a thread pool thread. Anything async inside of that may very well be on a different thread from that one once you await something. I'm surprised that the direct .Result call doesn't catch the issue, since .Result and .Wait are the equivalent of opening the box and finding out whether Schr�dinger's cat is still alive or threw and exception.

# ? Jan 20, 2021 00:16

Xik: Mar 10, 2011; Dinosaur Gum

CapnAndy posted:

I'm at my wit's end, can anyone explain to me how this is escaping error handling and what I can do to corral it? I have tested it with async code that does nothing but throw an exception and it can catch that, but when I do the HttpClient.GetAsync and it exceptions out, it's busting straight through.
code:
try
{
	Task.Run(async () =>
	{
		result = await client.GetAsync(url);
	}).Wait();
}
catch (Exception ex)
{
	//error handling
}

Have a peak at this post: Understanding Async, Avoiding Deadlocks in C#

Also this guy has a blog which is full of async/thread related posts.

Taking the time to learn async/task/thread related behaviour is well worth it if you're going to dev in the .NET world for anything non-trivial. I've worked with devs that are more senior and genuingly more skilled than I am, but also just completely botch writing basic async related code. It's a category of code that devs seem to be extremely confident in their incorrect knowledge, really bizarre because most of the assumptions I've heard can be easily disproven with <20 loc in LinqPad.

# ? Jan 20, 2021 06:54

Cold on a Cob: Feb 6, 2006; i've seen so much, i'm going blind
and i'm brain dead virtually; College Slice

Stephen Cleary also has a library named AsyncEx that�s useful when you have to do things with async that aren�t supported by default like locking or lazy loading.

# ? Jan 20, 2021 13:20

bobua: Mar 23, 2003; I'd trade it all for just a little more.

I've been running through this series trying to add authentication to a blazor client side app, with web api + asp.net identity(NOT identity server).

Seems like everything is working as far as login and getting a jwt token, but I absolutely cannot get blazor to attach the token to the requests. In the sample files, it seems to all be handled by blazors authentication system, configured as so

code:

	    builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) }); <----
            builder.Services.AddScoped<IProductHttpRepository, ProductHttpRepository>();
            builder.Services.AddFileReaderService(o => o.UseWasmSharedBuffer = true);
            builder.Services.AddScoped<IAuthenticationService, AuthenticationService>(); <----

            builder.Services.AddBlazoredLocalStorage();
            builder.Services.AddAuthorizationCore();    <-----
            builder.Services.AddScoped<AuthenticationStateProvider, AuthStateProvider>(); <----

The big difference in my method, is that I inject my http clients using this method

code:

builder.Services.AddHttpClient<IClientDataService, ClientDataService>(Client => Client.BaseAddress = new Uri("https://localhost:5001"));

I suspect that's why the authentication system never attaches, but no amount of googling or trying anything is getting me anywhere. Anyone have any ideas?

# ? Jan 22, 2021 06:14

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Is there any good reading on the do's and don'ts of microservices? I suspect that some day I'll get flung into the deep end with that and I would want to work responsibly.

WPF question: How do I establish a selection order for keyboard control across different controls? I have a ListView and two buttons underneath in the bottom corners of my control.

I figured there's some chaining I have to do establish an up/down/left/right precedence to everything. This is being put into Unity with NoesisGUI where I'd expect a lot of keyboard and gamepad use. Everything I've done for keyboard control so far has correlated with standalone WPF--to the point that sending a generic "GamepadAccept" or "GamepadCancel" event to Noesis translates to Space/Escape respectively in the handlers as if it were a regular .NET app. The strange things I see with selection are also consistent between Unity and a standalone build.

I has hoping to set up something like I had with the previous GUI I had hard-coded into Unity. That would be something like:
1. Pressing up at the top of the list would go to the bottom-left button.
2. Pressing down from the bottom of the list would (also) go to the bottom-left button.
3. Pressing up from the bottom-left/right buttons would go to the bottom of the list.
4. Pressing down from the bottom-left/right buttons would go to the top of the list.
5. The bottom buttons could be switched between using left/right. The only way to get to the bottom-right button is from the bottom-left button, but I intend to map a special key to reach it directly.

I also think I have a similar selection issue with a popup I defined. It's not a real popup since I can't use window controls but more like a box defined into the XAML that I enable or disable as needed. So I'm not surprised selection and precedence is screwed up with it. How do I send keyboard control there and suppress it elsewhere most elegantly? I'm hoping I don't have to make all the other controls aware of that popup's existence.

I have a secondary keyboard control question there of how to get keyboard control established by default. I have to hit tab to get the ListView to even start selecting anything, but then I can work with it using the PreviewKeyDown handler. If I further hit tab, it looks like I can get a dotted selection box around the buttons but their handlers don't go off. I'm not sure it's fully selected; I get a similar thing in my ListView where it looks like the first button is selected and I should have keyboard control, but up/down doesn't work. If I hit up/down on these buttons, I just lose my selection completely.

I might be served by a good article on keyboard control and precedence for a bit if somebody has one.

# ? Jan 22, 2021 18:06

EssOEss: Oct 23, 2006; 128-bit approved

CapnAndy posted:

I'm at my wit's end, can anyone explain to me how this is escaping error handling and what I can do to corral it? I have tested it with async code that does nothing but throw an exception and it can catch that, but when I do the HttpClient.GetAsync and it exceptions out, it's busting straight through.
code:
try
{
	Task.Run(async () =>
	{
		result = await client.GetAsync(url);
	}).Wait();
}
catch (Exception ex)
{
	//error handling
}

This code is fine and an exception being thrown does hit the catch. You must be doing something different in your real code than in your pasted example. Post a full sample project that demonstrates the issue you are facing.

As an aside, while the code is fine in the sense of it achieving what you asked about, I am unsure why you are starting an asynchronous operation only to run it synchronously. The whole point of asynchronous code is that you can go and do other stuff at the same time. More typical would be to either by async all through the stack or to just do result = clien.GetAsync(url).Result.

# ? Jan 22, 2021 22:47

ThePeavstenator: Dec 18, 2012; Establish the Buns

DO:
Not build microservices. Instead build monoliths with independent, configurable, well-tested components that are injected as services. Your app will scale and be perfectly performant as a monolith and will have a simple development process, simple CI/CD pipeline, and simple architecture.

Let's say you somehow get enough users to where the IComponentThatDoesShit service starts to become the majority of the load on your monolith, and it's affecting overall performance including the performance of other services. Or an alternative situation might be your app is performing fine but you're somehow making enough money to grow a dev team that's getting too large to work on a single monolith, and the IComponentThatDoesShit service is the most complex service in your system. In situations like these, you take the IComponentThatDoesShit implementation, make it into it's own webservice, and then take the existing implementation of IComponentThatDoesShit that has all the business logic and replace it with an implementation that makes HTTP calls to the new webservice.

Keep repeating as needed.

DON'T:
Build monoliths and not follow IoC practices. Starting with a greenfield monolith and understanding that at some point some services will need to be broken into separate microservices is the way to go, but this becomes a huge PITA when there's no dependency mapping and all your services have a hellish web of dependencies where you can't break off a module without affecting anything else.

e:

Basically don't think about writing microservices, think about writing code in modules and being in a tree-like dependency structure. You make choices that certain chunks of the tree should be running in a separate service for either ease of development or performance reasons. These chunks are microservices. Unless you are psychic, you will not know which chunks need to be running in separate services until an obvious need arises, so don't break anything up until you actually need to. Pre-maturely creating separate services is how you get into resume jerk-off land where everything gets put in a queue and for some reason there's still a single "database access" microservice that can't be broken up because everything is coupled to it.

ThePeavstenator fucked around with this message at 23:53 on Jan 22, 2021

# ? Jan 22, 2021 23:04

ThePeavstenator: Dec 18, 2012; Establish the Buns

EssOEss posted:

This code is fine and an exception being thrown does hit the catch. You must be doing something different in your real code than in your pasted example. Post a full sample project that demonstrates the issue you are facing.

As an aside, while the code is fine in the sense of it achieving what you asked about, I am unsure why you are starting an asynchronous operation only to run it synchronously. The whole point of asynchronous code is that you can go and do other stuff at the same time. More typical would be to either by async all through the stack or to just do result = clien.GetAsync(url).Result.

I just want to clarify something for people who might be new to async/await and not fully understand what "do other stuff at the same time" means. Take this example:

C# code:

void DoSync() {
    DoLongRunningThing1Sync(); // Takes 5 seconds
    DoLongRunningThing2Sync(); // Takes 10 seconds
}
async Task DoAsync() {
    await DoLongRunningThing1Async(); // Takes 5 seconds
    await DoLongRunningThing2Async(); // Takes 10 seconds
}

If you're debugging in Visual Studio, both of these methods will take 15 seconds to run. If Thing 1 and Thing 2 are able to run in parallel, you can write parallel code with or without async/await:

C# code:

void DoSyncParallel() {
    var task1 = Task.Run(() => DoLongRunningThing1Sync());
    var task2 = Task.Run(() => DoLongRunningThing2Sync());

    Task.WaitAll(task1, task2); // Takes 10 seconds because Thing 2 is the longest operation, Thing 1 runs in parallel
}
async Task DoAsyncParallel() {
    var task1 = DoLongRunningThing1Async();
    var task2 = DoLongRunningThing2Async();

    await Task.WhenAll(task1, task2); // Takes 10 seconds because Thing 2 is the longest operation, Thing 1 runs in parallel
}

Async/await is not about writing parallel code.

Let's say that these can't be run in parallel, Thing 1 has to be called, and then Thing 2 can only be called after Thing 1 completes. More often than not I find all my async/await code looks pretty much the same as if it were sync, which is where I think a lot of people who are new to async/await get tripped up since they don't really see the point of using it.

The difference between the Sync and Async examples is that in the DoAsync code, .NET can do other stuff with that thread, even if you don't write any parallel code yourself.

Let's say this is some method used by a ASP.NET webservice. With async/await, in the 5 and 10 seconds it takes for Thing 1 and Thing 2 to run, the calling thread can execute other work rather than sit there and wait for the operation to finish. That single operation still takes 15 total seconds, but the thread isn't sitting there waiting and being blocked.

In the DoSync example, the operation also takes 15 seconds, but 1 request calling the DoSync method also eats up the thread for 15 seconds.

In the DoAsync example, 1 request will eat up the thread for as long as it takes to invoke the task and register the callback (which is basically just a few sync method calls and some object allocations), but in the 5 and 10 seconds of waiting, other work can be done by the thread (such as servicing multiple requests). Your code all still looks sync, but the .NET runtime can more efficiently assign work to threads that are just sitting there waiting for long-running calls to finish when they're awaited. This is why using async/await for long-running calls in the UI thread is desirable. If you await an HTTP request call in the UI thread, the UI thread isn't locked up waiting for the long-running HTTP request operation to complete. The UI thread can do things like update the view and respond to user input instead of being eaten up by the long-running HTTP call while it waits to finish.

I think this is part of what confuses a lot of people about async/await. It's not a parallelization syntax, it's a continuation syntax. Your series of awaited calls still take the same total amount of time and execute in sequence, but they don't make the actual thread that they're executing on sit and wait for them to finish.

# ? Jan 22, 2021 23:50

NoDamage: Dec 2, 2000

What is the standard way of deploying ASP.NET Core apps on Linux these days? Are people mostly using Docker?

# ? Jan 23, 2021 01:56

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

NoDamage posted:

What is the standard way of deploying ASP.NET Core apps on Linux these days? Are people mostly using Docker?

Containers are easily the most popular approach, yeah, for a variety of reasons.

If I had to deploy to Linux and couldn't use container, I'd just run "dotnet publish" with the flags that ships a single file for a particular architecture with the dotnet runtime embedded inside.

# ? Jan 23, 2021 03:12

Mr Shiny Pants: Nov 12, 2012

NoDamage posted:

What is the standard way of deploying ASP.NET Core apps on Linux these days? Are people mostly using Docker?

Docker works well. .Net core with NGinx in front of it is quite a nice combination.

# ? Jan 23, 2021 08:44

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

I just found out about Avalonia, which is an open-source and cross-platform XAML framework. Anyone using that? Is it good?

# ? Jan 25, 2021 18:00

mystes: May 31, 2006

Combat Pretzel posted:

I just found out about Avalonia, which is an open-source and cross-platform XAML framework. Anyone using that? Is it good?

I don't think anyone's actually using it but it does look pretty polished now. It was missing some stuff that I needed but 0.10 looks like it may have fixed that enough that I'll probably try using the f# elmish wrapper when it's updated for it. (If you're using c# and don't like wpf I think someone is also making a winforms style wrapper for it although I don't know what the status is.)

Of course it's typical that it's starting to become more or less production ready around when Microsoft is announcing the MAUI stuff which will probably kill whatever momentum it had.

mystes fucked around with this message at 18:40 on Jan 25, 2021

# ? Jan 25, 2021 18:38

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

Wait what now? MAUI is also XAML? And the same time they're working on WinUI, too?

# ? Jan 25, 2021 18:57

mystes: May 31, 2006

Combat Pretzel posted:

Wait what now? MAUI is also XAML? And the same time they're working on WinUI, too?

I think MAUI is supposed to be a more cross platform version of WPF similar to Avalonia, but I've mostly been ignoring it since it doesn't seem to actually exist yet. Also there has been talk of maybe community linux support but I'm not sure if that will really happen and I really don't care about MAUI if it's not going to support linux. My impression is that the main reason for MAUI is just that xamarin forms is completely different from winui right now which is dumb and they want to integrate them somehow but I'm not totally convinced.

Honestly it would probably be better if they just used Avalonia or something but I guess that's not the microsoft way.

mystes fucked around with this message at 19:09 on Jan 25, 2021

# ? Jan 25, 2021 19:03

Drastic Actions: Apr 7, 2009; FUCK YOU!
GET PUMPED!; Nap Ghost

Combat Pretzel posted:

Wait what now? MAUI is also XAML?

MAUI is a fork of Xamarin.Forms, but with the namespaces changed. The idea is that you can port your existing Xamarin.Forms projects over to MAUI and keep using XAML, same as you have before...

MAUIs (potential) big addition is a C# based MVU framework. It would be entirely code-based. In terms of what that will actually look like, it will probably be based on Comet.

Combat Pretzel posted:

And the same time they're working on WinUI, too?

mystes posted:

My impression is that the main reason for MAUI is just that xamarin forms is completely different from winui right now which is dumb and they want to integrate them somehow but I'm not totally convinced.

MAUI is being worked on by the .NET/Xamarin teams, WinUI is by the Windows team. FWIW, I think their targets are quite different: While WinUI is decoupled from Windows, the likelihood of it actually hitting other platforms, IMO, is slim to none. MAUI is already built with multiple heads in mind.

Although it isn't at the current moment, MAUI will most likely use WinUI as a target for desktop Windows.

# ? Jan 25, 2021 20:49

mystes: May 31, 2006

Drastic Actions posted:

MAUI is a fork of Xamarin.Forms, but with the namespaces changed. The idea is that you can port your existing Xamarin.Forms projects over to MAUI and keep using XAML, same as you have before...

MAUIs (potential) big addition is a C# based MVU framework. It would be entirely code-based. In terms of what that will actually look like, it will probably be based on Comet.

MAUI is being worked on by the .NET/Xamarin teams, WinUI is by the Windows team. FWIW, I think their targets are quite different: While WinUI is decoupled from Windows, the likelihood of it actually hitting other platforms, IMO, is slim to none. MAUI is already built with multiple heads in mind.

Although it isn't at the current moment, MAUI will most likely use WinUI as a target for desktop Windows.

Looking at comet, what's the point of even forking xamarin for this? There's already the "Xamarin Community Toolkit C# Markup" stuff and couldn't they just make an optional MVU library on top of xamarin? I just don't understand why Microsoft seems to be trying to make all this stuff as confusing as possible.

Edit: Seriously Microsoft needs to pull its head out of its rear end and come up with some sort of coherent ui framework strategy.

mystes fucked around with this message at 21:03 on Jan 25, 2021

# ? Jan 25, 2021 20:56

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

All this poo poo certainly doesn't help me argue out of my position with that Java fuckwit of an IT boss and his hard-on for SWT and Jasper. I guess I'll try to go with WPF on .NET 4.8 and some WinUI theme like ModernWPF.

I need to (re)learn MSBuild tho, to get going on my own via VSCode, since they're also dragging their balls in giving me admin rights, so I can maintain (i.e. install) my own toolchains.

(--edit: Apparently it takes three months to set up a loving Git account on their server, because they're "busy" with god knows what. I haven't really started out on the coding part of this job, and I already hate it.)

Combat Pretzel fucked around with this message at 21:23 on Jan 25, 2021

# ? Jan 25, 2021 21:15

Canine Blues Arooo: Jan 7, 2008; when you think about it...i'm the first girl you ever spent the night with; Grimey Drawer

Does WinUI have the absurd restrictions that UWP does? I was luke warm on UWP until I learned that you didn't have first-class access to pretty anything useful in the OS. File System access, Registry access, meaningful hardware access - it's all locked off. I don't write software to look pretty. I need it do stuff. UWP doesn't not do stuff and I give negative fucks about 'Touch Support'.

A high level glance looks like WinUI is making the same mistakes. I'm not moving off of WPF/Win32 until MS can actually deliver a feature set that makes a computer work like a computer.

# ? Jan 25, 2021 22:19

mystes: May 31, 2006

Canine Blues Arooo posted:

Does WinUI have the absurd restrictions that UWP does? I was luke warm on UWP until I learned that you didn't have first-class access to pretty anything useful in the OS. File System access, Registry access, meaningful hardware access - it's all locked off. I don't write software to look pretty. I need it do stuff. UWP doesn't not do stuff and I give negative fucks about 'Touch Support'.

A high level glance looks like WinUI is making the same mistakes. I'm not moving off of WPF/Win32 until MS can actually deliver a feature set that makes a computer work like a computer.

This isn't an issue. You can use WinUI from desktop apps.

# ? Jan 25, 2021 22:26

Drastic Actions: Apr 7, 2009; FUCK YOU!
GET PUMPED!; Nap Ghost

mystes posted:

Looking at comet, what's the point of even forking xamarin for this? There's already the "Xamarin Community Toolkit C# Markup" stuff and couldn't they just make an optional MVU library on top of xamarin? I just don't understand why Microsoft seems to be trying to make all this stuff as confusing as possible.

Edit: Seriously Microsoft needs to pull its head out of its rear end and come up with some sort of coherent ui framework strategy.

Funny enough, the community toolkit markup stuff was part of Forms for a hot minute, but then they pulled it out because pulling in an entire third party addition to your platform without plans on, say, maintaining it, wasn't the best idea :v:

.

Now, I should be more clear, MAUI isn't just a fork of Forms, that's more of where it is at the moment. It's about making it more a part of .NET itself and removing its dependencies on the IDE (Namely, VS and VS for Mac). It's getting VS Code support, support for single projects (meaning, one project targeting multiple platforms, rather than separate app projects with a shared Forms project), and in general, making it easier to keep your projects simpler without having to load up tons of custom renderers and boilerplate code.

I mention Comet not because it's going to be added straight to MAUI, but that the MVU implementation is probably going to look a lot like it (Mostly because the person working on it works at Microsoft and is fighting pretty hard for it). And you don't need to use it: XAML (and its C# markup) are fully supported too! The feeling I get around it among those I talk with here (and again, my opinions here, not my team nor who I work with) is that MVU will attract people who normally wouldn't use a .NET UI Framework. XAML and MVVM isn't where the market is heading, where new developers are learning to build apps with: it's too confusing with too much boilerplate. MVU is seen as a simpler approach that will help get new people in.

Do I think that's true? Well, :shrug:

mystes posted:

Edit: Seriously Microsoft needs to pull its head out of its rear end and come up with some sort of coherent ui framework strategy.

Buddy, I wish. It would make my meetings so much easier.

The Windows team is getting behind WinUI and React Native.

.NET has MAUI and Blazor with Mobile bindings (Which are basically tackling dev tasks from opposite approaches. MAUI wants to have a Blazor head for websites, Blazor + Mobile is deploying Blazor app to your phone.)

There's also Webview2 for hybrid web applications with a shared Edge core and instance.

I'm sure there's more I'm missing.

Canine Blues Arooo posted:

Does WinUI have the absurd restrictions that UWP does?

No. WinUI is totally independent from platform. If you want, you can make a UWP application and includes WinUI (and, by extension, target platforms UWP supports), but you don't have to.

# ? Jan 25, 2021 22:55

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

mystes posted:

This isn't an issue. You can use WinUI from desktop apps.

Still can't do xcopy deployments. That one missed the 3.0 GA window. Being required to do a full install via AppX in the past and now MSIX is what still pisses me off.

I just want to be able to compile a bunch of things and drop everything with the WinUI runtime on a network drive.

# ? Jan 25, 2021 22:56

mystes: May 31, 2006

Combat Pretzel posted:

Still can't do xcopy deployments. That one missed the 3.0 GA window. Being required to do a full install via AppX in the past and now MSIX is what still pisses me off.

I just want to be able to compile a bunch of things and drop everything with the WinUI runtime on a network drive.

Ah, that's unfortunate. Are they going to add it in version 3.1 or something then?

# ? Jan 26, 2021 00:24

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Can anybody think of any cute WPF ListBox tricks that lets me change the focused item in a ListBox without toggling the SelectedItem? I previously had the ListBox invoke some code as if a commitment on a choice in the ListBox was made when SelectedItem changed. That worked with a mouse, but is screwing up with a keyboard. I'm trying to left/right between the choices, but it'll immediately callback to the SelectedItem binding in my view model and commit as if I had actually made a selection.

My plan is to define my own buttons with their own command binding, but I hoped there was something else I could do that wouldn't require so much more typing and maintenance.

Edit: I think what's more abstractly getting me in WPF is the difference between focusing stuff versus selecting it. I can easily bind to a selected item in these List* controls but I can't have a separate thing tracking focus directly. I have to hit the code-behind and get cute.

Rocko Bonaparte fucked around with this message at 17:28 on Jan 26, 2021

# ? Jan 26, 2021 09:13

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

Since when did Visual Studio become such an annoyance? I remember it being fast and nimble, and easy to mess around with, around the Windows 8 times when I tried to earn some money with useless apps. Haven't really used it since then.

But now it takes ages to start, because of background tasks, always some nuget poo poo fetching stuff, project property pages take ages to load, and this 19 day old release of a WPF project from Github doesn't load properly, puking out tons of MSBuild issues about missing methods and what not, despite the proper .NET SDK and targeting packs being installed. What the hell.

:sigh:

mystes posted:

Ah, that's unfortunate. Are they going to add it in version 3.1 or something then?

In some webcast they called it a pain point, so I guess it will happen for that release. Hopefully.

# ? Jan 26, 2021 18:19

Cold on a Cob: Feb 6, 2006; i've seen so much, i'm going blind
and i'm brain dead virtually; College Slice

It's the circle of visual studio life. Every few major releases they fix a shitload of performance issues and then just let performance slowly go to poo poo for a few versions before starting again.

# ? Jan 26, 2021 18:22

raminasi: Jan 25, 2005; a last drink with no ice

Combat Pretzel posted:

Since when did Visual Studio become such an annoyance? I remember it being fast and nimble, and easy to mess around with, around the Windows 8 times when I tried to earn some money with useless apps. Haven't really used it since then.

But now it takes ages to start, because of background tasks, always some nuget poo poo fetching stuff, project property pages take ages to load, and this 19 day old release of a WPF project from Github doesn't load properly, puking out tons of MSBuild issues about missing methods and what not, despite the proper .NET SDK and targeting packs being installed. What the hell.

In some webcast they called it a pain point, so I guess it will happen for that release. Hopefully.

I�ve found VS to have gotten consistently snappier and cleaner as time goes on :confused:

I don�t use WPF as much these days though, maybe that part has gotten worse.

# ? Jan 26, 2021 18:24

Drastic Actions: Apr 7, 2009; FUCK YOU!
GET PUMPED!; Nap Ghost

raminasi posted:

I�ve found VS to have gotten consistently snappier and cleaner as time goes on I don�t use WPF as much these days though, maybe that part has gotten worse.

With the way VS is built and run (as modular as it is), your experience with it versus someone else's can be vastly different depending on what types of projects you're working on and whose extensions under the hood are loaded and being used. In my experience, SDK style projects right now are slower than the original project types at loading from startup. Not "unusable" or super annoying but "you notice" kind of slow.

# ? Jan 26, 2021 18:30

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

Now I can't start a project build because VS is reloading all the Intellisense stuff, and it's taking its sweet time with it. Plus there's 140(?!) low priority tasks in the queue. 16 cores and a NVMe SSD, and I feel like I'm working on a 486 again. At least over at work I'd get paid to sit on my hands.

--edit: I'm messing with ModernWPF currently.

--edit: I think the printing stuff in WPF is only half thought through, re: trying to make a print preview of a FlowDocument.

Combat Pretzel fucked around with this message at 21:58 on Jan 26, 2021

# ? Jan 26, 2021 18:39

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Microsoft left an expired cert in their default (Debian-based) .NET 5 Docker image and now you have to switch to the Ubuntu variant or your project won't build :yarg:

:

https://github.com/NuGet/Home/issues/10491

# ? Jan 27, 2021 17:46

WorkerThread: Feb 15, 2012

Certificate expiration is such an interesting problem to me (a simple caveman developer). Will we be contending with it forever, constantly breaking pieces of the internet?

# ? Jan 27, 2021 20:20

NoDamage: Dec 2, 2000

NihilCredo posted:

If I had to deploy to Linux and couldn't use container, I'd just run "dotnet publish" with the flags that ships a single file for a particular architecture with the dotnet runtime embedded inside.

Thanks, I'm leaning towards this for simplicity. One more thing: does ASP.NET Core have an equivalent of defining command line utilities along with your project similar to Rails' custom rake tasks or Django's custom admin commands? Do I need to build a separate console application to do this?

# ? Jan 28, 2021 03:20

User0015: Nov 24, 2007; Please don't talk about your sexuality unless it serves the ~narrative~!

Hey nerds, what's your goto method of mapping data from the backend? We're behind the times and still running EF6, so we have a lot of DB objects full of lazy-loading proxies that are attached to every object. Sometimes we need to map all that data, sometimes not. Our current method is mapping data by hand, and we use extension methods to quickly map results from the repository. The end result, though, is we end up mapping way to much data when we don't need to, but we're tightly coupled to those mappings so just changing them breaks poo poo that does rely on that fully mapped data.

I think AutoMapper is way to slow (and complicated) for our uses, but I'm open to suggestions that include it if the case is made. Obviously I'm also all ears for any other case to be made to. I thought about building some abstracted pipeline to map data, but it's also so easy to overengineer mapping code, and I don't want to do that either.

# ? Jan 30, 2021 19:15

Mr Shiny Pants: Nov 12, 2012

User0015 posted:

Hey nerds, what's your goto method of mapping data from the backend? We're behind the times and still running EF6, so we have a lot of DB objects full of lazy-loading proxies that are attached to every object. Sometimes we need to map all that data, sometimes not. Our current method is mapping data by hand, and we use extension methods to quickly map results from the repository. The end result, though, is we end up mapping way to much data when we don't need to, but we're tightly coupled to those mappings so just changing them breaks poo poo that does rely on that fully mapped data.

I think AutoMapper is way to slow (and complicated) for our uses, but I'm open to suggestions that include it if the case is made. Obviously I'm also all ears for any other case to be made to. I thought about building some abstracted pipeline to map data, but it's also so easy to overengineer mapping code, and I don't want to do that either.

Petapoco is nice, just one file and from what I've seen and used it for it does a pretty good job.

# ? Jan 31, 2021 17:23

ThePeavstenator: Dec 18, 2012; Establish the Buns

I use these for mapping POCOs

Alternatively these are also good (especially .NET 5 with init-only properties)

For real though, auto-mapping libraries give you 5 minutes of convenience and a lifetime of pain. They're great when they work with 0 additional code because all of your objects have identical fields, but you're presumably using different object types and mapping between them to decouple data at different layers. That implies that there's a good chance that the shape of the data at those different layers can diverge. Once that happens you now have to write mapping code, except the compiler isn't able to do as much work to help you anymore because now that's all being done at runtime via reflection. It's not a huge deal to write and maintain these:

C# code:

public YourPostApi Map(YourPostDb yourPostDb) =>
    new YourPostApi
    {
        AreBad = true,
        AreSigned = yourPostDb.AreSigned,
        Content = yourPostDb.Content
    };

...and then vice-versa if you need to map the other way. Now there's no risk of Automapper blowing up at runtime when it hits an edge case you didn't anticipate, and you can set breakpoints and debug your actual mapping code when needed (and it's really easy to write tests for these).

And with only a single object mapping method, you can still map collections via Linq:

C# code:

IEnumerable<YourPostDb> postsRetreivedFromDatabase = GetPostsFromDb();
List<YourPostApi> listOfPostsToReturnToCaller = postsRetreivedFromDatabase.Select(Map).ToList();

e:

Also re: performance - constructors and object initializers are pretty dang fast compared to reflection!

ThePeavstenator fucked around with this message at 02:52 on Feb 1, 2021

# ? Feb 1, 2021 02:50

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 22:05

Mr Shiny Pants: Nov 12, 2012

Whenever I read posts regarding something like object mapping I always think of Clojure and the way it makes everything a Map or Dictionary.

It seems very elegant.

# ? Feb 1, 2021 07:23

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›300 »