|
Cuntpunch posted:Sure - but if FooViewModel *requires* an IBarService, that starts to get messy.  Of course, hadn't considered that.I'm liking the Locator idea more and more. It solves the question of where to put the initialization code - it goes in the constructor of the Locator. And if I put my VMs into DI, I can use constructor injection to pass any services needed. Looks very clean. Thanks for that idea.
|
#
?
Jul 26, 2019 18:21
|
|
|
|
| # ? May 23, 2024 06:55 |
|
|
LongSack posted:
Protip: Start a side WPF project, add the MVVM Light package to it, it'll bootstrap the couple of files/changes that you can look at. It also includes its own tiny SimpleIOC implementation for registration, which may well suit your needs as well.
|
|
#
?
Jul 26, 2019 20:08
|
|
|
LongSack posted:Oh, and if you’re wondering why use Expression<Func<foo, bool>> rather than just Func<foo, bool>, it’s because Where with the latter returns an IEnumerable<foo>, so you can’t add, say, an .AsNoTracking(). Where with the former returns an IQueryable<foo>, so you can. Expression<Func<foo, bool>> is an expression tree, which means it's a declarative set of instructions that are interpreted at runtime. Your Linq code on an IQueryable is really just adding more instructions to the expression tree. Then at runtime something like EF can interpret the expression and turn it into something like a SQL query and send it to a database. AsNoTracking() is just an extension method on Expression<> that adds to the tree and be interpreted at runtime. Func<foo, bool> is an imperative function that gets compiled and executed as a part of your program. Which means that it can only operate on .NET types, which means you need actual data structures in memory (or IEnumerables emitting them). So going from Expression to Func (or IQueryable to IEnumerable) means that your expression tree gets interpreted and executed and anything chained after that will be ran in your program. beuges posted:Just so you know, there are .AsQueryable<T> and .AsEnumerable<T> methods that are available from entity framework that will transform from one to the other. Converting from IEnumerable to IQueryable just means that your expression tree will get interpreted by the CLR and invoke methods as if your IQueryable was an enumerable. It won't tack your Linq on to the upstream expression tree.
|
|
#
?
Jul 26, 2019 22:15
|
|
|
Figured this was a good place for a visual studio question. In some web based projects, visual studio will create a hierarchy for files with a . naming convention, like javascript.part2.js will become a sub file of javascript.js. Is there a way to get it to do that for wpf apps?
|
|
#
?
Jul 27, 2019 16:41
|
|
|
bobua posted:Figured this was a good place for a visual studio question. You can use this vs extension to do it. https://marketplace.visualstudio.com/items?itemName=MadsKristensen.FileNesting
|
|
#
?
Jul 27, 2019 17:08
|
|
|
raminasi posted:Oh, Powershell closures apparently capture by value. One way around this is something called a reference object (apparently, I don't really know Powershell):
|
|
#
?
Jul 27, 2019 17:18
|
|
|
Once you're doing sufficiently complicated stuff, PowerShell quickly becomes more complicated than just using c#.
|
|
#
?
Jul 27, 2019 17:33
|
|
|
spaced ninja posted:You can use this vs extension to do it. thank you!
|
|
#
?
Jul 27, 2019 19:19
|
|
|
mystes posted:Once you're doing sufficiently complicated stuff, PowerShell quickly becomes more complicated than just using c#. And the bar for "sufficiently complicated" is surprisingly low
|
|
#
?
Jul 28, 2019 00:54
|
|
|
I'll admit that I have a few preprocessors for files we ingest that are PowerShell scripts with C# source code in them that performs all the work. It made it easier to make changes without having to build an executable in VS, copy and paste into a VM, then copy into an RDP session. It also prevents me from having to repeatedly Google how to do basic things since I write PowerShell scripts so infrequently that I forget most of it.
|
|
#
?
Jul 28, 2019 01:05
|
|
|
LongSack posted:DAL.Initialize() No!
|
|
#
?
Jul 28, 2019 11:55
|
|
|
mystes posted:Once you're doing sufficiently complicated stuff, PowerShell quickly becomes more complicated than just using c#. The AD, IIS and Exchange modules all make PS an awesome tool, but outside of environment management at a MS heavy enterprise I've never really thought "oh I know, PowerShell would be a good tool to solve this problem". I've gone as far as to import custom DLL's and use reflection, but only in the context of environment management. If you're doing practically anything else then there will be a better way that doesn't involved PowerShell.
|
|
#
?
Jul 29, 2019 02:30
|
|
|
I make multiplatform software and PowerShell is pretty sweet for making OS-independent scripts. Doesn't matter what OS the software is deployed on, just run this PowerShell script to make stuff happen! That being said, I agree that it is a major pain in the rear end to work with, mostly due to syntax/language rear end-backwardness in many areas. It has so much promise to be a great tool but all of this promise is squandered by a design that just has the wrong bells and whistles. You can do cool things in 5-line snippets with those language warts but for real world use, I want consistency and clarity. Also, it sort of manages but never really reaches interoperability with non-powershell executables. I never want to wonder "why does piping input to this command suddenly not work?" and reach the conclusion "microsoft magic, gently caress it, it works for some user accounts so just switch accounts" after 3 days of investigations. Unrelated, "Exit code failure is an error" should be an automatic behavior, not something I have to implement manually on every command (oops, missed one in the pipe!).
|
|
#
?
Jul 29, 2019 05:46
|
|
|
Literal clueless idiot baby speaking here, but what is the cross platform scripting situation like now that windows has the Linux subsystem thing? Does this kind of make bash scripts cross platform now? (at least Linux, Mac and Windows?)
|
|
#
?
Jul 29, 2019 09:39
|
|
|
You can do some things but definitely not everything with WSL. I wouldn't try to depend on it for system configuration. The point where PowerShell really scores on Windows is the built-in capabilities for scripting WMI objects and loading and use pretty much any .NET assembly, and those are basically required for any non-trivial configuration on Windows. A much better cross-platform bet (but would still require special-casing for Windows) would be Python or Perl, except those obviously require installation.
|
|
#
?
Jul 29, 2019 11:32
|
|
|
I have not encountered anyone brave enough to use Windows Subsystem for Linux (WSL) in production so far. Also, WSL just got re-written from a "native" implementation to a VM-backed implementation, in the form of WSL2, completely changing the architecture. Windows Server 2019 does apparently support WSL1 but now that WSL2 is completely different, WSL1 seems to just be a technology that graduated from beta verision to legacy garbage, without ever entering the "production" phase. WSL2 is still beta release and will not be seen in a production release of Windows Server for a few years yet, I expect. You could still use 3rd party Bash builds like Cygwin (eww) but the extent of what you can do is still limited (and indeed, might still be limited in WSL). Hence why I use PowerShell.
|
|
#
?
Jul 29, 2019 11:35
|
|
|
I use LinqPad for shell-like things fairly often because it's generally easier to write some throwaway C# with LP's fairly decent code completion features than it is to figure out how to do complex things in PS. I even have a bunch of helper functions to expand environment vars, read/write files, search directory structures and work with file/directory objects.
|
|
#
?
Jul 29, 2019 16:41
|
|
|
I'll generally do PowerShell for quick and easy but usually it's because I have to access an mssql database and its real fast and easy and winnt 3.51 odbc left my brain with scars.
|
|
#
?
Jul 29, 2019 22:38
|
|
|
Question about EF Core and navigation properties. My Character class has 4 navigation properties: Category, Gender, Native Language, and Race. When I create a new character, those values are chosen from combo boxes. When I go to insert the new character, EF tries to create each navigation property as if it were new (probably related to the state). Since they already exist, this fails. The Insert method looks like C# code:
|
|
#
?
Jul 31, 2019 00:48
|
|
|
Anyone ever had the displeasure of working with XpsDocumentWriter? Getting anything out of it that isn't just 8.5x11 portrait? I have what I thought was a fairly simple idea, taking the output of my third party control as three separate XPS files that are long and skinny, and then combine them into a single XPS - which sort of works except the page size is always the default no matter what I try. I'm adding the FixedPage I find inside each of the XPS files the third party DLL renders out for me into a System.Windows.Media.ContainerVisual then using the System.Windows.Documents.Serialization.SerializerWriterCollator I created from the System.Windows.Xps.XpsDocumentWriter - now the collator has some options for a System.Printing.PrintTicket object, both when you create it and when you write to it, but it doesn't seem to do anything for me. code:
|
|
#
?
Aug 2, 2019 15:08
|
|
|
Anyone have any Azure Pipelines experience? I'm trying to get a pipeline to build against a .NET Core 3.0 preview SDK, and it's not working. I had this exact problem:code:code:
|
|
#
?
Aug 4, 2019 22:08
|
|
|
raminasi posted:Anyone have any Azure Pipelines experience? I'm trying to get a pipeline to build against a .NET Core 3.0 preview SDK, and it's not working. I had this exact problem:
|
|
#
?
Aug 4, 2019 23:06
|
|
|
Nth Doctor posted:Are you using azure-pipelines.yml? If so what does that look like? There are more steps after this, but this is as far as it's getting: code:
|
|
#
?
Aug 4, 2019 23:40
|
|
|
I'm trying to make a Azure webjob handle failure/restart a bit more gracefully for batch processing. In an ideal world, I'd convert to Azure Durable functions to leverage fan in/fan out. But I don't think I'll have the time to properly convert all the webjobs (it does some funky stuff with caching that I'll need to re-architect to move over to functions) Currently - the webjob gets a message to process 50 documents at a time from an Azure SQL database. It performs 1 SELECT to retrieve all the records, and then generates and emails the documents. After it's processed the whole batch it performs 1 UPDATE to mark all the records as complete. I think it's hitting some memory limits and the webjob dies, or it terminates unexpectedly. I lose track of which of those 50 documents were actually sent (0, 10, all 50?) and can't gracefully recover. I can't do individual record updates one by one in SQL as this can run into 200k documents at a time and the DB is under a fair bit of load as it is. I'm thinking when I send the document, I could either write to Azure Table storage, Azure Storage Queue or Azure Redis. then if a webjob fails it will move the message to the poison queue. I can then read the temp storage (Table, Queue or Redis) to identify which documents were sent and recover (update the SQL db and then requeue the batch) I just need a simple key storage e.g. <tenant-name>-<batch-id>-<document-id> = SENT. If I used queues I would create a queue per batch and just the messages into that queue. Any recommendations as to Table, Queue or Redis for this scenario? Performance is key - aiming to send 200k documents per hour. I would lean towards Redis, but I'm worried about potential data loss as it's not persisted - or is this something not really to be concerned with? For it to be an issue the webjob would have to fail, and both Redis nodes would have to fail / be restarted before the webjob recovered.
|
|
#
?
Aug 5, 2019 02:10
|
|
|
Humor my shenanigans a bit here with IEnumerator and coroutine madness. I am toying around with integrating some scripting into Unity and I was trying to maintain scheduling for it separate from Unity's own schedulers. A lot of that is just trying to decouple, but also because I don't know what Unity is doing with synchronization contexts. That right there has kept me away from using async-await, although I'm about to poke the synchronization context with a stick and see what happens. Anyways, I wound up trying to use IEnumerator coroutines because of that. Internally, that means a lot of calls are returning IEnumerators because the things they invoke might yield. But then sometimes I need to recover a return value and conclude the coroutine. This is leading to a very common copy-paste, and I don't like that. I'm not in front of the code but it's basically a foreach against the invocation of the subordinate code. If it's not a return value, I end up yielding it up a layer--usually to another foreach block. I'd use a macro for this if I wasn't working in C#. I can't write a helper function because then I'd have to wrap that in the same foreach. So I'm pondering out loud here how I might be able to maintain the IEnumerator model while not having to do this foreach stuff. I'm actually starting to bank on overriding the synchronization context to defer all my own generated awaiters to my own scheduling because I think it would ultimately look cleaner, so please don't X instead of Y me on using async-await here. I'm starting to look into that too. This gets particular ugly if any scripts are written recursively. I don't plan to do that. However, I wonder if switching to async-await would make that any better. Internally, does the .NET runtime manage that better?
|
|
#
?
Aug 8, 2019 19:15
|
|
|
Only semi-related to .NET but... We need to purchase a Visual Studio Pro 2017 license (standalone) for a new developer, but I'm only seeing Visual Studio Pro 2019 in the MS Store. It looks like they make it really hard to (a) download and (b) buy a license for older VS versions. I've spoken to a couple clueless MS Store and VS Site reps (via in-browser chat), and they don't know what's up. One told me to physically go to a brick/mortar MS Store at a nearby mall. I might actually try this, but drat...really? Just take my money already and give me a license for some slightly older software! In the last few years there generally haven't been any must-have features, so we tend to upgrade to the latest VS after it's been out for a while, and the rest of the world has worked out the obvious bugs. Usually "Update 1", "Update 2", etc has been released by then.
|
|
#
?
Aug 8, 2019 21:14
|
|
|
Removing older versions sounds like a good idea because some people may try to buy them.
|
|
#
?
Aug 8, 2019 21:22
|
|
|
Rocko Bonaparte posted:Humor my shenanigans a bit here with IEnumerator and coroutine madness. I am toying around with integrating some scripting into Unity and I was trying to maintain scheduling for it separate from Unity's own schedulers. A lot of that is just trying to decouple, but also because I don't know what Unity is doing with synchronization contexts. If you're doing your own co-routines, I'd expect you to use your own tasklike objects instead of tasks: you'll write "await myCoroutineFunction()". The C# compiler translates this into "myCoroutineFunction().GetAwaiter()". Therefore it's entirely up to you how you implement your GetAwaiter method. The stuff about synchronization contexts lies solely within from Task.GetAwaiter(), i.e. the default awaiter for task objects. If you do your own coroutines, then your work will be unrelated to synchronization contexts. (sticks or otherwise...). It'll be solely up to you where coroutines get scheduled. Rocko Bonaparte posted:This gets particular ugly if any scripts are written recursively. I don't plan to do that. However, I wonder if switching to async-await would make that any better. Internally, does the .NET runtime manage that better? Note that async+await is fundamentally doing the same thing as an enumerator. With async+await it ends up calling ".MoveNext()" on the AsyncStateMachine object. This is conceptually no different from calling ".MoveNext()" on an enumerator object. (For the first prototype of async+await I actually implemented it with IEnumerator and tried to persuade the rest of the C# language design team that this would be a good idea. Anders Hejlsberg was having none of it, so we abandoned it in favor of introducing a new family of types. IEnumerator came with too much inefficiency baggage; the async types allow for vastly less memory allocation.) I don't know what is the source of your ugliness with recursive scripts. If you post some code, maybe that would clarify. The .NET runtime (CLR) isn't at all involved in async+await. It's entirely accomplished in libraries which can be written by you, or by the framework designers. They are the ones that implemented Task.GetAwaiter and decided to make it use synchronization contexts. When you say "ugliness" I instead assume you're talking about language-level ugliness, i.e. is your paradigm for coroutines compositional in the same way that async+await is. Again it's too hard to speculate without seeing your code. I'm sorry to "X instead of Y" you here, but I'm 100% sure that async+await is the right way to do co-routines. Here's some co-routines I wrote which use async+await to hibernate a method and resume it at a later date. This isn't what you're doing, but it might help familiarize you with how to play around with coroutines. https://blogs.msdn.microsoft.com/lucian/2016/04/20/async-workflow-2/
|
|
#
?
Aug 9, 2019 00:50
|
|
|
Downloaded VS2019 preview today, and started messing around with WPF on .NET Core 3.0. It’s going surprisingly well, with one glaring exception: Properties.Settings.Default is gone. I use settings extensively for things that the user can change and that they would expect to stay changed the next time they run the app. Things like most recent Foo, application colors, sort directions and orders, etc. I liked settings because they were strongly typed and were read-write (unless you made them otherwise). I’m currently using an appsettings.json file for connection strings, but they’re read-only, right? I’m currently thinking about putting all these user-configurable items into a Settings table, then at app startup loading up a singleton class that offers them as properties and knows how to persist changes back to the database. Better ideas? TIA
|
|
#
?
Aug 9, 2019 00:56
|
|
|
I'd be curious if you find the current Microsoft blessed replacement for settings/profile. That said your solution is totally fine, you can even do something simple like using a Sqlite database to store the settings locally. I again recommend against explicit singletons.  Why not just write an IProfileService and inject it where needed?
|
|
#
?
Aug 9, 2019 03:00
|
|
|
WorkerThread posted:I'd be curious if you find the current Microsoft blessed replacement for settings/profile. I’m already using MSSQL for the rest of the app, so that’s fine for the settings. As for the Singleton, there’s no need for multiple instances of a Settings class, and instantiating one wherever needed seems like wasteful and unnecessary database hits. Granted, on my desktop with it’s I9 processors and SSD drive, it’s probably moot, but why not strive for efficiency? I put my MainViewModel in as a singleton, since there should only ever be one (the other view models are transients). I thought that was what singletons were for.
|
|
#
?
Aug 9, 2019 03:24
|
|
|
LongSack posted:I’m already using MSSQL for the rest of the app, so that’s fine for the settings. This returns to your earlier questions about dependency injection. What he is saying is that at the same point at the start of the app that you're standing up your dependency graph, either via an IOC container or manually, you can simply register a single instance of IProfileService, rather than the type itself, to ensure that a single instance is the 'same instance' that gets used by all consuming classes.
|
|
#
?
Aug 9, 2019 11:23
|
|
|
Cuntpunch posted:This returns to your earlier questions about dependency injection. What he is saying is that at the same point at the start of the app that you're standing up your dependency graph, either via an IOC container or manually, you can simply register a single instance of IProfileService, rather than the type itself, to ensure that a single instance is the 'same instance' that gets used by all consuming classes. Oh, that's what I was going to do anyways - register the concrete class as an implementation of an Interface. I probably misstated what I intended. At least, that's what I think I'm doing. It looks something like this: C# code:
|
|
#
?
Aug 9, 2019 15:26
|
|
|
raminasi posted:Anyone have any Azure Pipelines experience? I'm trying to get a pipeline to build against a .NET Core 3.0 preview SDK, and it's not working. I had this exact problem: Quoting myself because I fixed this problem - dotnet appears to get stupid when either a preview or 3.x SDK is installed. I had to explicitly install it next to the rest of my SDKs, and provide a global.json naming it. dotnet pack still isn't working though, so I'm not done yet!
|
|
#
?
Aug 10, 2019 21:05
|
|
|
epalm posted:Only semi-related to .NET but... VS 16.2 is out I think, give it a try
|
|
#
?
Aug 12, 2019 06:12
|
|
|
brap posted:VS 16.2 is out I think, give it a try His entire question is predicated on needing a VS 15.x version - presumably owing to wanting to keep the entire development team in-sync. To the OP's question - am I confused? For years now hasn't Visual Studio been effectively a subscription based license? And per https://visualstudio.microsoft.com/wp-content/uploads/2017/11/Visual-Studio-2018-Licensing-Whitepaper-November-2017.pdf p.12 posted:For Visual Studio Professional 2017 standalone licenses, the software included in the license is the current version of the If you have an active subscription for VS 2019, you should be just fine to install 2017 side-by-side.
|
|
#
?
Aug 12, 2019 06:39
|
|
|
Yeah, when I log into my account I can download at least VS 2010, 2013, 2015, 2017, and 2019, and also a few even older versions.
|
|
#
?
Aug 12, 2019 07:28
|
|
|
nielsm posted:Yeah, when I log into my account I can download at least VS 2010, 2013, 2015, 2017, and 2019, and also a few even older versions. Yeah, I think that the only oddity would be going back to 2013 or older - where there was a 4-tier model. If you've got an Enterprise sub you're fine, but if you're on Professional I wouldn't know whether that would be considered Pro or Premium.
|
|
#
?
Aug 12, 2019 15:41
|
|
|
Rocko Bonaparte posted:Humor my shenanigans a bit here with IEnumerator and coroutine madness. I am toying around with integrating some scripting into Unity and I was trying to maintain scheduling for it separate from Unity's own schedulers. A lot of that is just trying to decouple, but also because I don't know what Unity is doing with synchronization contexts. That right there has kept me away from using async-await, although I'm about to poke the synchronization context with a stick and see what happens. You can grab Unity’s UnitySynchronizationContext by querying for the current synchronization context anywhere you’re guaranteed to be on the main thread (any lifecycle function or a coroutine). You can then use that synchronization context to synchronize back to the unity thread when you’re off the unity thread. If you just use coroutines, everything is running on the main thread.
|
|
#
?
Aug 13, 2019 00:06
|
|
|
|
| # ? May 23, 2024 06:55 |
|
|
Thanks leper khan and ljw1004. I think I was talking to myself for awhile there. I'm still experimenting.ljw1004 posted:I don't know what is the source of your ugliness with recursive scripts. If you post some code, maybe that would clarify. The .NET runtime (CLR) isn't at all involved in async+await. It's entirely accomplished in libraries which can be written by you, or by the framework designers. They are the ones that implemented Task.GetAwaiter and decided to make it use synchronization contexts. When you say "ugliness" I instead assume you're talking about language-level ugliness, i.e. is your paradigm for coroutines compositional in the same way that async+await is. Again it's too hard to speculate without seeing your code. Edit: Okay, so to maybe explain more of what's going on. If you haven't tuned in before, I've been nibbling on a supposedly scaled-down Python interpreter in .NET here so I can write pseudo Python NPC scripting and stuff for Unity. Well, that and also study Python internals for potential job application stuff. A major requirement for me is something like half-sync/half-async; I want blocking calls on other parts of the engine for things like prompts without making the scripts re-entrant in clumsier ways like with state machines. So that's left me with a lot of shenanigans for doing coroutines. Right now every callable thing returns an IEnumerator and blocking calls like this would just drift up and out of the current frame. Not every such call does this; a lot of stuff just returns immediately. However, I can't always tell that and it's always possible for something to get overridden. I mean, I'm the main rear end in a top hat using this so I don't think I'd override __add__ for the base integer class, but it's theoretically possible and I currently support it. Side fact: doing it this way was easier than some of the alternatives after implementing a certain amount of Pythonism. I didn't really expect that. Anyways, this leaves me with foreaching on IEnumerators all the time with a fairly boilerplate block that I can't do much about but clone and clone and clone. So I'm thinking that maybe I don't need to bother with it? I need something to deal with code that might yield before producing its final value. I'm not yielding in the sense of a classic generator but instead of trying to use it to punch out of the current frame and have something else run for awhile. So I need to pass those up before I get the one that represents the stuff I actually care about. Note that this is all going on under the hood so some messiness is acceptable, but the replication of that boilerplate is getting ridiculous. For example, every arithmetic opcode will defer to a dunder in Python and those are all callables that are getting this treatment. The synchronization context came up when I was looking up what I might be getting into if I wanted the coroutines generated by the interpreter to be managed and scheduled by it instead of the hosting system directly. A big reason for that is to moderate how much some of the scripts run and interfere with them if a script is being naughty. Some of that is I just don't want the rest of the system to have to mess with it in general. What I thought from a cursory reading of SynchronizationContext is that there's a global one and I'd have to create my own implementation of something for it, replace the default one with mine, and use it to whittle out the ones I don't want to go on to normal processing. Between some stuff I read the other day and some comments here, I think I really didn't get it right with that. The synchronization context goes beyond basic coroutine task scheduling and into regular multithreaded stuff. So I'd prefer if I could do that interception without dealing with that. So some of the requirements I'm balancing is: 1. Trying to avoid boilerplate. 2. Shuffling paused/yielded coroutines to a separate scheduler. Rocko Bonaparte fucked around with this message at 08:07 on Aug 13, 2019 |
|
#
?
Aug 13, 2019 00:32
|
|