We have a #dotnet based framework (a bunch of #nuget packages) that can be used to build desktop executables that control and visualize machine data with a very simple and easy to use #MVVM based API. It is based on #WPF and we want to rewrite/redesign it to make it cross platform.
What UI technology should we base it on?
Customers will have to learn the basics of that chosen technology.
@bitbonk@w0ger@sjkilleen
Yeah, that's probably a fair comment. As a dev working on a Windows machine it's very frustrating, but I need my apps to work on mobile too (but a very cool advantage here is I can develop and test my app on Windows, and then deploy it to Android just to see if there's any Android-specific issues. The first time I did this I only had to change about 6 lines for Android, and that was mostly around different defaults, which now I just cater for up-front).
@SmartmanApps@w0ger@sjkilleen Ah yes, mobile. In the future we might also want to provide the possibility to build mobile apps with our SDK. It would be nice if the programming model is very similar to the one for desktop. I suppose both #AvaloniaUI as well as #UnoPlatform would provide that and when (if) #dotnetmaui has proper desktop support (we need #linux), it would also be an option.
Are you aware of a simple INI file parser for #dotnet that does not require an additional dependency (DLL) but rather could be added as a source code file (development dependency).
@nblumhardt We have a type that does not override ToString(). But we always want it to be serialized as a specific string in #Serilog. Does Serilog have means to achieve that?
I know about Destructure.ByTransforming but that will require the @ operator in the log template, which is easy to forget. We would prefer that it is not required for that type. #dotnet
@bitbonk@esg yeah, the non-@ path is very inflexible unfortunatley; is the type one that you can't modify? Curious about the scenario, have had this on the radar for a long time...
@nblumhardt@esg The type in our case is called LocalizableString. We own this type and *can *modify it. But we cannot override ToString() because this leads to weird behavior when used in bindings in WPF.
I know this is a bit of an edge case but generally, I think it is unfortunate that only the log invoker gets to decide whether there should be destructuring (by adding the @ or not).
This issue is related: https://github.com/datalust/seq-extensions-logging/issues/54 The @ does not place nice with the "new way" of logging.
The "new" minimal SDK style csproj file format in #dotnet minimizes the potential of merge conflicts. But the solution file is still as cumbersome and nerve-racking as always.
Is there a German word for „trying to press the right button combination and waiting for the LED to start flashing in the right way and then trying to connect the other thing with this thing wirelessly“ ?
I honestly can’t think of a reason why anyone who tried both #VisualStudio and #JetBrainsRider would prefer VS.
Except maybe: „VS is what I‘m used to, don’t move my cheese“.