|
EmmyOk posted:The guy has a follow up video and he explained why starting a new thread was a bad idea even if you knew the workarounds to make everything work as intended. I think he says the final version that "works" is basically pure look that in this case it works as you want. The label will get updated, but then the UI will immediately freeze and turn into a grey block until the blocking operation finishes.
|
#
?
Nov 14, 2017 17:20
|
|
|
|
| # ? May 18, 2024 00:28 |
|
|
EmmyOk posted:The guy has a follow up video and he explained why starting a new thread was a bad idea even if you knew the workarounds to make everything work as intended. I think he says the final version that "works" is basically pure look that in this case it works as you want. Because the text update actually involves asynchronous operations at the OS level, which are completely invisible to you in most circumstances and usually occur so fast they're effectively synchronous. When it answers back to the framework code with, say, the window handler for the textbox that the framework has been asked to update, the framework is too consumed with doing your long running operation to process that interrupt and perform the update, so it gets processed once the long running operation completes, then immediately gets updated again with the "it's complete now" message.
|
|
#
?
Nov 14, 2017 17:28
|
|
|
Right, it's just easier for me to think of it that way because I'm way more used to process/thread-level separation, but sometimes there is so assume the worst and hope for the best.
|
|
#
?
Nov 14, 2017 17:43
|
|
|
I'm trying to mess around with libsodium before I add it to our main product's project, so I made a console project, added the libsodium-net package, wrote two lines to see what the default output of an Argon hash looks like and now the project won't build because something in the package's Baseclass.Contrib.Nuget.Output.targets is trying to load a nonexistent DLL  Who the hell do I even report this to? Full error in case I'm not reading this right: C:\LiveFireProvingGround\Sodium\packages\Baseclass.Contrib.Nuget.Output.2.1.0\build\net40\Baseclass.Contrib.Nuget.Output.targets(73,5): error MSB4175: The task factory "CodeTaskFactory" could not be loaded from the assembly "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Tasks.v15.0.dll". Could not load file or assembly 'file:///C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Tasks.v15.0.dll' or one of its dependencies. The system cannot find the file specified. Microsoft.Build.Tasks.Core.dll does exist and is what I assume it's supposed to use, but maybe that other one is missing? gently caress IDK. Can't get the stupid thing to run in LinqPad, either 
|
|
#
?
Nov 14, 2017 19:18
|
|
|
Munkeymon posted:I'm trying to mess around with libsodium before I add it to our main product's project, so I made a console project, added the libsodium-net package, wrote two lines to see what the default output of an Argon hash looks like and now the project won't build because something in the package's Baseclass.Contrib.Nuget.Output.targets is trying to load a nonexistent DLL Try sodium.core package instead. The packaging on the sodium-net is kinda lovely.
|
|
#
?
Nov 14, 2017 19:37
|
|
|
Dietrich posted:Try sodium.core package instead. The packaging on the sodium-net is kinda lovely. Exactly the same error, so at least that rules out the library maintainers  Baseclass.Contrib.Nuget.Output is a libsodium-net dependency and VS doesn't bother to delete unused dependencies when you remove a package. I was thinking it was a normal part of NuGet.Packaging on Core sucks, too, turns out! Or maybe copying a file to the output directory is just a really hard problem to solve in the context of a package manager 
Munkeymon fucked around with this message at 20:46 on Nov 14, 2017 |
|
#
?
Nov 14, 2017 20:02
|
|
|
Munkeymon posted:Exactly the same error, so at least that rules out the library maintainers Try Paket? I've heard good things about it.
|
|
#
?
Nov 14, 2017 22:13
|
|
|
Mr Shiny Pants posted:Try Paket? I've heard good things about it. I think it's a problem with the package itself because there's a closed bug about basically the same issue but I'm thinking maybe they weren't diligent in their testing.
|
|
#
?
Nov 14, 2017 23:26
|
|
|
i solved my problem, I made a snk instead of a pfx and just replaced the references to the pfx and it works fine 
|
|
#
?
Nov 15, 2017 05:38
|
|
|
Munkeymon posted:I think it's a problem with the package itself because there's a closed bug about basically the same issue but I'm thinking maybe they weren't diligent in their testing. Not a lot a packagemanager can do if the package itself is broken.
|
|
#
?
Nov 15, 2017 06:58
|
|
|
NuGet packaging has turned into a buggy overcomplicated mess to such an extent that I am thinking back to manually managed DLL files in "lib" directories with fondness.
|
|
#
?
Nov 15, 2017 08:13
|
|
|
When the Nuget packages are small and self-contained (i.e. no dependencies), it works great. As soon as the packages start referencing others, it becomes DLL hell of the highest order. If you haven't had to deal with: "conflicts between different versions of the same dependent assembly" yet, consider yourself lucky. The binding redirect thing is a total hack, and I wish Nuget was smarter about warning you when you try to install a package that references a package you have installed, but a different version. Nuget should assume that I do not, under any circumstances, want to break what I have when I install a new package.
|
|
#
?
Nov 15, 2017 15:16
|
|
|
Essential posted:Thanks for the info! Yeah I have the same question as Opulent Ceremony, can you elaborate on what that means? What exactly is "sql as function parameters" referring to? Are you talking about passing in a connection object, command object, something else? I may be missing the mark here entirely but the db side of this is quite the mystery to me right now. Sorry for the delay guys! Yeah, I was talking about specific bindings. I'm not at work right now, I may be mis-remembering using bindings for Azure Sql. I can check in the morning and post back  We definitely had issues coding directly at Cosmos DB, and we solved that by using the provided bindings.
|
|
#
?
Nov 15, 2017 20:06
|
|
|
dick traceroute posted:Sorry for the delay guys! Yeah, I was talking about specific bindings. I'm not at work right now, I may be mis-remembering using bindings for Azure Sql. I can check in the morning and post back No sweat and thanks for any info you can provide! Yes, please post back when you can 
|
|
#
?
Nov 15, 2017 21:08
|
|
|
B-Nasty posted:When the Nuget packages are small and self-contained (i.e. no dependencies), it works great. As soon as the packages start referencing others, it becomes DLL hell of the highest order. If you haven't had to deal with: "conflicts between different versions of the same dependent assembly" yet, consider yourself lucky. I had a crash in production that was caused by an update to a dependency of a dependency that was incompatible (they had broken their API contract and only changed a minor version number, yay semantic versioning) So now I use Paket and pin down the version of all packages I use, then grab all of their dependencies (from the paket.lock file) and pin those versions down too. If you're using nuget and are having problems with transitive dependencies, I recommend switching to paket. Unless nuget has had an update that I'm not aware of, it is total poo poo for managing conflicting dependencies.
|
|
#
?
Nov 15, 2017 21:29
|
|
|
Looks cool. I had heard of it before, but never really dug into the documentation. I really like the transitive dependencies all listed, hierarchically, in a single file. Half the issue with what I'll dub NugetHell is that it doesn't give you readily actionable error messages. You do (sometimes) get a compiler warning, but to dig into what happened, you have to compile at a high verbosity and try to interpret what dependencies are in conflict and then manually look at what they reference. I'm so beaten down that I typically commit between individual Nuget package updates/additions so I can quickly isolate the offender and compare diffs to see why it's ruining my day.
|
|
#
?
Nov 15, 2017 22:04
|
|
|
So I've run into two really annoying problems with Entity Framework and lazy loading this morning that I can't believe are still an issue in EF 6. 1. You can't just null out a navigation property, you have to have accessed it first, triggering lazy loading, before you can set it to null. 2. A navigation property with the [Required] attribute fails validation on calling SaveChanges(), if it hasn't been accessed (i.e. lazy loaded) at some point. Does anyone know of any nice, clean solutions for these, other than to manually access the getters, or to use Include() when accessing them? For point 1, I've just implemented custom setter logic that access the property first if the value is null, but I can't find a nice solution to problem 2 at all. According to the top answer on https://stackoverflow.com/questions/6038541/ef-validation-failing-on-update-when-using-lazy-loaded-required-properties , #2 is symptomatic of how the change tracker works. Which is really annoying. The weird thing is, MSDN explicitly states that #1 shouldn't be a problem in EF 6: quote:To delete the relationship, set the navigation property to null. If you are working with the Entity Framework that is based on .NET 4.0, then the related end needs to be loaded before you set it to null. For example: I think exposing the foreign key properties on the classes would help, but unfortunately someone set a precedent of not doing that on this project, and I don't really want to break the pattern. chippy fucked around with this message at 12:25 on Nov 16, 2017 |
|
#
?
Nov 16, 2017 12:23
|
|
|
The Libsodium.Core guys told me they don't really support not-Core, but Baseclass.Contrib.Nuget.Output fixed their poo poo so there's no build error when using libsodium-net. Yay! I did have to delete my whole test project and start over, though, because somehow it got stuck on the wrong Sodium wrapper DLL (I'm guessing here) when I switched NuGet packages. ~just NuGet things~ I guess, but I'm glad I did this experimentation in a throwaway solution.
|
|
#
?
Nov 16, 2017 15:32
|
|
|
Given a list of IP addresses, I'm using the following to determine the first address to response with a valid HTTP responsecode:
|
|
#
?
Nov 17, 2017 23:20
|
|
|
fankey posted:Given a list of IP addresses, I'm using the following to determine the first address to response with a valid HTTP response
|
|
#
?
Nov 18, 2017 01:29
|
|
|
fankey posted:Given a list of IP addresses, I'm using the following to determine the first address to response with a valid HTTP response Break it down into an easier problem: First write that WhenAnyEqual method, then you can use it. It should be easier to write if you're only thinking about Tasks, not http requests and so on. I'm thinking that you could call Task.WhenAny in a loop. Each time Task.WhenAny completes, you check if the returned Task passes the condition. If it does, you're done. If it doesn't, remove it from the collection of Tasks and call Task.WhenAny again.
|
|
#
?
Nov 18, 2017 02:55
|
|
|
Couldn't you just ips.First(ip => DownloadCheck(client, ip) != null) ?
|
|
#
?
Nov 20, 2017 15:12
|
|
|
Munkeymon posted:Couldn't you just ips.First(ip => DownloadCheck(client, ip) != null) ? That would just return the first IP in the list because the function would return a non-null Task<string>, no?
|
|
#
?
Nov 20, 2017 15:43
|
|
|
NihilCredo posted:That would just return the first IP in the list because the function would return a non-null Task<string>, no? right, async. So I guess you could strip out all the sync stuff and return ips.AsParallel().First(etc) but maybe there's a way to keep it all async/await?
|
|
#
?
Nov 20, 2017 16:24
|
|
|
Would the TCP timeout of 21 seconds not be long enough to not worry about this?
|
|
#
?
Nov 20, 2017 17:13
|
|
|
I'm still kinda fighting NuGet trying to get the unmanaged libsodium DLL into my output. It works fine in a toy project with one Project, but we have multiple solutions that all have a different consumer of the user service and I'd prefer it if I didn't have to add a NuGet reference to libsodium-net for them all to work*. I found https://stackoverflow.com/questions/15816769/dependent-dll-is-not-getting-copied-to-the-build-output-folder-in-visual-studio which I'm alright with except that I don't think that's possible with the DLL being loaded dynamically based on architecture as it is in the .Net wrapper. Am I stuck doing copies in every consumer project's pre-build? *note: I have not tested that, so it might not work, either
|
|
#
?
Nov 20, 2017 19:31
|
|
|
Munkeymon posted:
AsParallel doesn’t reorder anything, so that won’t work either. There may be some clever construct in Rx that will help you (“here’s a collection of things to do, give me an observable stream of the results as they come back”) but I’m not sure. The repeated Task.WhenAny suggested upthread is probably the first thing I’d try; the second would involve using a BlockingCollection and manually spawning a consumer.
|
|
#
?
Nov 22, 2017 14:20
|
|
|
fankey posted:Given a list of IP addresses, I'm using the following to determine the first address to response with a valid HTTP response. Untested, coding in my text editor... code:Note: in case of timeout, I thought it'd be cleaner to throw a Cancelled exception rather than to return null. That's how all other async APIs work. Note: if all of the urls fail, then it would have been nicer for GetBestUrlAsync to fail immediately rather than wait until the cancellation expires. I didn't bother doing that. It would be easy enough: first, each CheckAsync would have to "try / catch (Exception ex) {}" to swallow all exceptions. Second, you'd need to "await Task.WhenAny(tcs.Task, Task.WhenAll(allUrlTasks))" and then "return tcs.Task.IsCompleted ? await tcs.Task : new OperationCancelledException()". Note: it would have been nicer to cancel all pending requests the moment we get our first answer (rather than, as in this code, just letting each one eventually timeout). I didn't bother doing that. It would be easy enough: you'd create your own CancellationTokenSource that you can signal as soon as you get an answer, and then you'd create "CancellationTokenSource.CreateLinkedTokenSource(...)" and pass this on to all the tasks. Note: the .ToList() is there just as standard LINQ practice. If you omitted it, then the .Select() call would return a lazy IEnumerable that would only invoke CheckAsync upon demand. We call .ToList() to make that demand. Note: it felt really sketchy to do this upon IPs, and to do string concatenation with "http://" and the IP. I figured URLs would be more general and meaningful. What if "http://1.2.3.4" was served by one dead webserver but "http://1.2.3.4/path" was served by a different responsive webserver? I guess I don't know what you're going to do with the information about quickest-IP-to-respond, so it's hard to say. But my suspicions are raised... Edit: the HttpClient team at Microsoft say it's best practice to have as few instances of HttpClient as possible, even down to sharing a single static instance across the whole app. They say this works better because it can cache or something like that. I vaguely remember a few bug reports a couple of years ago where folks said this wasn't working for them, but I'd hope those have been fixed by now. ljw1004 fucked around with this message at 18:43 on Nov 22, 2017 |
|
#
?
Nov 22, 2017 16:01
|
|
|
NiceAaron posted:Break it down into an easier problem: First write that WhenAnyEqual method, then you can use it. It should be easier to write if you're only thinking about Tasks, not http requests and so on. Since people are still discussing this (and I'm bored) I'll provide a more concrete code example of what I was thinking of (also untested and coding in the forum post text editor) code:
|
|
#
?
Nov 23, 2017 01:53
|
|
|
Today I learnt about the FirstChanceException event. So many lines of logging code...
|
|
#
?
Nov 23, 2017 13:06
|
|
|
Question for the EF experts. I’ve searched (maybe I’m not using the correct keywords) and looked I’m my EF book without much luck. How do I “back out” or revert any unsaved changes? Given this situation - user right-clicks on an item in a listbox/listview and chooses “Edit” ... new window pops up with the details of the object, with data-bound fields. User makes changes, then realizes that they have the wrong item, and presses the Cancel button. Since the data bindings are two-way, the object has been changed. If the user instead clicked the OK button, I would call the SaveChanges() method, but they clicked Cancel. How do I tell EF to discard any changes? I haven’t found a good answer to this question, but it seems like something that would have to be there, so maybe I’m just not looking in a way that reveals the answer.
|
|
#
?
Nov 24, 2017 03:39
|
|
|
dbContext.Entry(obj).ReloadAsync() - note that this is not actually a reset changes, it's a refetch from database so if the DB has updates the object will get them. You might also be able to wire up something to splat from dbContext.Entry(obj).OriginalValues if you don't want to update from the DB but it doesn't look like there's an easy way to do that.
|
|
#
?
Nov 24, 2017 04:54
|
|
|
Night Shade posted:dbContext.Entry(obj).ReloadAsync() - note that this is not actually a reset changes, it's a refetch from database so if the DB has updates the object will get them. Thanks. Refetch is fine, I’m not doing any apps with multiple users accessing the database. It just seems weird to me that there’s not a method like RevertChanges() to go with SaveChanges()
|
|
#
?
Nov 24, 2017 05:02
|
|
|
First time I've used async methods in a long time and I don't know which of two alternative approaches is better. I have two operations to do: read a file from disk, and deserialize it from JSON. Reading the file can potentially be done asynchronously, but AFAIK deserializing with Newtonsoft.JSON is only synchronous. C# code:C# code:
|
|
#
?
Nov 24, 2017 05:56
|
|
|
chmods please posted:First time I've used async methods in a long time and I don't know which of two alternative approaches is better. I have two operations to do: read a file from disk, and deserialize it from JSON. Reading the file can potentially be done asynchronously, but AFAIK deserializing with Newtonsoft.JSON is only synchronous. BTW, Newtonsoft.JSON used to have asynchronous methods, but they were wrappers similar to method 1. When designing a public API, the method shouldn't lie about being asynchronous. If it's doing a significant amount of synchronous processing, keeping the method signature synchronous will allow the caller to decide whether they'll want to use a separate thread or not.
|
|
#
?
Nov 24, 2017 08:41
|
|
|
LongSack posted:Given this situation - user right-clicks on an item in a listbox/listview and chooses “Edit” ... new window pops up with the details of the object, with data-bound fields. User makes changes, then realizes that they have the wrong item, and presses the Cancel button. Since the data bindings are two-way, the object has been changed. If the user instead clicked the OK button, I would call the SaveChanges() method, but they clicked Cancel. How do I tell EF to discard any changes? I would use a separate DataContext for the Edit dialog and throw away this DataContext (along with any data) once the dialog is closed (regardless of whether with a save or cancel action). If you are currently using a mechanism of "one data context for the entire app" I suppose this might be foreign but I would recommend you move away from that into "one data context per operation" because your life will generally be much easier this way.
|
|
#
?
Nov 24, 2017 10:52
|
|
|
EssOEss posted:I would use a separate DataContext for the Edit dialog and throw away this DataContext (along with any data) once the dialog is closed (regardless of whether with a save or cancel action). I would go further that if you find any re-use of a DataContext, stop what you are doing right now and eliminate it and make sure you have a new one per operation, that is one for read (and hopefully, you map to a ViewModel), and a separate one for writing. Otherwise you are introducing a multitude of potential issues.
|
|
#
?
Nov 24, 2017 15:08
|
|
|
chmods please posted:My intuition from last time I heavily used C# was that method #2 is preferred, because everything should be made async as far down as possible. But method #1 was what I first came up with and it seems to work fine so far. Does #1 have potential for deadlock even if the synchronous I/O is wrapped in an asynchronous block? hirvox covered why #2 is preferred, but I’ll add that the async deadlocking footgun that I think you’re referring to manifests when you try to jam asynchrony into a synchronous workflow by using Result or Wait, rather than the opposite, which is what you’re doing here.
|
|
#
?
Nov 24, 2017 16:31
|
|
|
Funking Giblet posted:I would go further that if you find any re-use of a DataContext, stop what you are doing right now and eliminate it and make sure you have a new one per operation, that is one for read (and hopefully, you map to a ViewModel), and a separate one for writing. Otherwise you are introducing a multitude of potential issues. I'm all for one per request but what's the rationale behind separate contexts for reading and writing? Disclaimer: I've only used EF with MVC/WebApi apps, oh, and a couple of Windows services, but not WinForms or WPF, so maybe this is some difference I'm not aware of. chippy fucked around with this message at 18:39 on Nov 24, 2017 |
|
#
?
Nov 24, 2017 18:37
|
|
|
|
| # ? May 18, 2024 00:28 |
|
|
EssOEss posted:I would use a separate DataContext for the Edit dialog and throw away this DataContext (along with any data) once the dialog is closed (regardless of whether with a save or cancel action). What’s the overhead for this? I only went with one long-lived context because I assumed that there was a lot of overhead with context creation. Using multiple short-lived contexts would solve a couple other problems as well, like this: I go to add a new ticket, the window pops up, I enter the task and work order numbers, hit the drop-down for the Requester, and realize that it’s a new one so it isn’t in the list. No problem, I click the “...” button next to the combo box which pops up the window to maintain requesters. I add the new person, click ok and ... oops, the view model in the Requester maintenance window calls SaveChanges() when the I click “Done” so now the partially entered Ticket is saved. Now, if I click Cancel on the “Add Ticket” window, I have to delete the ticket and catch (and ignore) any exceptions.
|
|
#
?
Nov 25, 2017 01:31
|
|