|
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.
|
# ? Jan 19, 2021 22:37 |
|
|
# ? Jun 8, 2024 08:25 |
|
mystes posted:Then get rid of task.run and just use .result?
|
# ? Jan 19, 2021 22:40 |
|
Can't you just go like this?code:
|
# ? Jan 19, 2021 22:55 |
|
Ola posted:Can't you just go like this?
|
# ? Jan 19, 2021 23:09 |
|
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 |
|
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. 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 |
|
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 |
|
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:
code:
|
# ? Jan 22, 2021 06:14 |
|
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 |
|
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. 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 |
|
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 |
|
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. 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:
C# 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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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? 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 |
|
Wait what now? MAUI is also XAML? And the same time they're working on WinUI, too?
|
# ? Jan 25, 2021 18:57 |
|
Combat Pretzel posted:Wait what now? MAUI is also XAML? And the same time they're working on WinUI, too? 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 |
|
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 |
|
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... 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 |
|
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 |
|
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 |
|
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'.
|
# ? Jan 25, 2021 22:26 |
|
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. 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 . 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, . 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 |
|
mystes posted:This isn't an issue. You can use WinUI from desktop apps. 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 |
|
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.
|
# ? Jan 26, 2021 00:24 |
|
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 |
|
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. mystes posted:Ah, that's unfortunate. Are they going to add it in version 3.1 or something then?
|
# ? Jan 26, 2021 18:19 |
|
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 |
|
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. 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.
|
# ? Jan 26, 2021 18:24 |
|
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 |
|
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 |
|
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 : https://github.com/NuGet/Home/issues/10491
|
# ? Jan 27, 2021 17:46 |
|
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 |
|
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.
|
# ? Jan 28, 2021 03:20 |
|
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 |
|
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. 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 |
|
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:
And with only a single object mapping method, you can still map collections via Linq: C# code:
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 |
|
|
# ? Jun 8, 2024 08:25 |
|
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 |