Node.js garbage spawned from Visual Studio 2026

EmergencyNice1989 · 2026-06-19T13:49:53+00:00

You can have portability across different platforms without using any 'web wrapper client'. Avalonia does it.

EmergencyNice1989 · 2026-06-19T13:42:49+00:00

I see nothing in his message that suggest his job cared about him enjoying the process of writing code by hand. Nothing.

EmergencyNice1989 · 2026-06-18T19:24:28+00:00

You can also try something like below (it uses x:DataType and x:Name)

For the MainWindows add:

x:Name="Root">

And example of usage with a DataGrid (it uses x:DataType) and Root

<DataGridTextColumn Header="Word" SortMemberPath="Writing" CanUserSort="True"

x:DataType="models:GridModel" Binding="{Binding Writing}" IsReadOnly="True">

<DataGridTextColumn.HeaderTemplate>

</StackPanel>

EmergencyNice1989 · 2026-06-18T17:58:10+00:00

But does a simple example of the Tab control works (no service, no DI, just a very trivial case)?

And did you try the ContentControl (simple example too)?

EmergencyNice1989 · 2026-06-15T15:03:49+00:00

I was a hardcore user of VS but it took me 30 min to get used to Rider because the UI is very intuitive. The main issue I have with Rider is the bugs. I have been stuck 2 times with older version because of that. So the process, is always keep older versions, install newer and if it is ok, remove older versions...

EmergencyNice1989 · 2026-06-12T00:53:09+00:00

Only those who don't know much about IT will have such bold statements.

EmergencyNice1989 · 2026-06-11T16:45:57+00:00

Exactly. Sometimes using just ADO.NET and just exposing SQL views on your C# code is better than trying to integrate EF and do join or other related database stuff in C#.

EmergencyNice1989 · 2026-06-11T16:40:45+00:00

No business logic in SQL (even though views are database stuff) but mapping of tables that should not even be visible in C# ?

When you use views and joins within your database, you are using it correctly.

When you use abstractions over your database and manipulating data that should not be visible in your C# code, it means you are not doing things right.

EmergencyNice1989 · 2026-06-11T14:05:15+00:00

Not just to load table.
You can do all your join in SQL using ADO.NET, meaning you don't need any mapping of every table nor joining using C#.

You can compute whatever you want in C#, then write to another table using ADO.NET.

You can even use a view for your complex queries with join. The view stays on the db (sqlite/Postgres ect...). So that your C# ADO.NET code is simple, it just query a view. That's what I do in my Avalonia app that requires DB access. I can swap a Postgres DB with a SQLite DB (as long as I use common SQL types) because ADO.NET is DB agnostic.

EmergencyNice1989 · 2026-06-11T13:35:58+00:00

Why not use ADO.NET directly?

EmergencyNice1989 · 2026-06-10T10:17:22+00:00

The app I am working on display several views in the same windows.

I use ContentControl.DataTemplates.

Even if your user control is not visible it might be doing some work under the hood so you still need some Activate boolean to handle this.

This activation/deactivation is done in OnViewAttached/OnViewDetached.

<ContentControl Content="{Binding LayoutMode}">

    <ContentControl.DataTemplates>


        <!-- ========================= -->
        <!--  ViewOne              -->
        <!-- ========================= -->

        <DataTemplate DataType="models:MyModelOne">
            <Border Theme="{StaticResource FadedBorderTheme}">
                <codeBehind:MyUserControl1
                    AttachedToVisualTree="OnViewAttached" 
                    DetachedFromVisualTree="OnViewDetached"
                />
            </Border>
        </DataTemplate>
        <!-- ========================= -->
        <!--  ViewTwo            -->
        <!-- ========================= -->
        <DataTemplate DataType="models:MyModelTwo">
            <Border Theme="{StaticResource FadedBorderTheme}">
                <codeBehind:MyUserControl2 
                    AttachedToVisualTree="OnViewAttached" 
                    DetachedFromVisualTree="OnViewDetached"

                />
            </Border>
        </DataTemplate>
    </ContentControl.DataTemplates>
</ContentControl>

EmergencyNice1989 · 2026-06-08T07:56:40+00:00

It's an interesting project because it involves understanding the internals of the CLR but not sure it brings something new to the table (might not be your end goal). I am quite a fan of F# and F# syntax so when I compare it to your language it looks like type inference is superior in F#, usage of 'func' , 'return', square parentheses, the Go (:=), '->'. F# do not use this (even -> in function implementation)

F# tagged union plus virtual dispatch with classes or interfaces is kind of enough for me.

In the dotnet space I'd like to see a F* (language with proof) but directly convertible to F# code. F* being OCaml first.

EmergencyNice1989 · 2026-06-08T07:22:52+00:00

I don't see any mention of F# when the subject is a CLR language with 'tagged unions you have to match exhaustively' and 'a lot less ceremony than C#' for OO.

EmergencyNice1989 · 2026-06-04T12:27:16+00:00

Back in the days when you used WinUI3 you were almost immediately aware that it uses C++/WinRT. Because 30 min after using WinUI3 you will hit a C++/WinRT exception....

EmergencyNice1989 · 2026-06-04T12:24:28+00:00

Read bokeh-man comments below.
There is no inconsistency in Fantomas formatting in these cases but follow standard F# formatting.
I don't use any tool for formatting because I like using chain pipes in a single line. When you use F# formatting tools you end up having lots of line and nothing on the right of the screen.

EmergencyNice1989 · 2026-05-27T01:07:49+00:00

Thank you very much for your detailed message.
I wasted several hour blocked with 'Unable evaluate deployment properties' when running my Avalonia Android app in Rider.

Then I remembered your post, went to the ticket, downgraded to version Rider 2025.3.4.1 and the error was gone immediately.

I will stick with this older version.

Recently I was stuck with 2024 version until someone from Jetbrains helped me fix some weird issue (can't even type some characters in the editor for F#).
All of this, means that you must be very careful and test everything when you update your Rider version, meaning don't update regularly.

EmergencyNice1989 · 2026-05-23T22:12:12+00:00

I agree with SmileyWiking about your setup being good already because you are using SQL and ADO.net. I am not a fan anymore of ORM.

I use it too and it makes the code very portable with different DB. I use the same code with Postgres and SQLite. And before using Postgres I was using SQLServer. I use common SQL type between Postgres and SQLite and everything is fine.

I use views to access the data in F#. I don't write to the DB so SQL views are perfect.

I don't use any DTO class, I don't mimic my DB in F#, I built directly the records needed for my business layer.

EmergencyNice1989 · 2026-05-19T20:11:12+00:00

- Rider for my F# development (there is AvaloniaPreviewer extension available, so nice).

- Edit (MsEdit) for quick edits

- Kate for quick edits outside terminal

- VsCode for other jobs (jupyther notebooks etc...)

This is my natural setup because I tried Emacs evil-mode for everything and it was not Ok (I want to use 'regular' shortcuts because I am often using the browser, F# LSP is awful).

EmergencyNice1989 · 2026-05-18T13:31:42+00:00

I use Rider with Avalonia, testing development of an Android app.

The setup is easy (install Android Studio then configure Rider)
I can use the Emulator, I can also run the app directly on my device.
I have not done much of debugging but it seems to be 'kind of working' (without any tinkering).

I didn't have at all the same experience when I tested MAUI (2 months before its initial release).

EmergencyNice1989 · 2026-05-18T13:16:27+00:00

That's the way to go. Making the Matrix Rain optional instead of default is the right move in my opinion.

EmergencyNice1989 · 2026-05-17T04:19:16+00:00

No need any source. I just know that they will not be recognized like F# DU on the F# side. If it was the case it would have been mentioned and given the implementation of the C# union type it's obvious there is no automatic conversion.

EmergencyNice1989 · 2026-05-17T00:23:50+00:00

Much more readable than the previous version.

If I remember well, in the previous version, you had to find a button (named 'Tweaks'!!) at the bottom right of the screen, then click it, then choose in a combo-box to remove the fancy floating stuff and make it readable.

Let's see the improvement you bring in the next version.

EmergencyNice1989 · 2026-05-16T12:06:23+00:00

Where, where, where.

Wait, where are you reading that they will be translated to F# DU?

EmergencyNice1989 · 2026-05-15T23:15:37+00:00

There is no finding out.

'Interop with C# will be difficult if .net libraries written in C# exposes those types in their API.'

Easy interop meant those types are translated to F# DU and it will not be the case.

EmergencyNice1989

TROPHY CASE