Blazorise VS Mono

I made a Blazor component library for one of my personal projects that failed, but the component library lived on as an open-source project called Blazorise [1].

In late 2019, I got a well-paid job in a large local company because of the project reference. Unfortunately, COVID happened, and I lost that same job after a few months. So again, because of Blazorise, I got several other gigs as a freelancer.

But after a while, it was hard to do all the work on the projects and do freelance jobs at the same time. Not to mention that family time was also very limited.

So I decided to commercially license Blazorise to companies, and keep it free for individuals. Hopefully, the decision paid off. Today I run a small company and continue to work on Blazorise full time. We're still fully bootstraped without any external funds.

[1] https://blazorise.com/

https://blazorise.com is fully done on Blazor. Also the support forum https://blazorise.com/support

Da, vidi https://blazorise.com/

I am working on form that run dynamic sql query in database and populates the results in datagrid. I don't know how many columns will return by the query. So I populate my resuts in DataTable, but unable to display on datagrid. Relevant issue [Feature] Full featured work with DataTable in DataGrid · Issue #701 · Megabit/Blazorise (github.com) . Does anyone know workaround for this.

Making Blazor run on Linux was a lot of hard work. Mainly because there is no official support from Microsoft (but even that doesn't always help, as you will see in the next section about macOS). I tried to make it work with 3 different community driven projects: Electron.NET, Chromely and Photino. Electron is very bloated and very slow - it takes for ever to start debugging from Visual Studio. I also hated that it first opens a console window and then the Blazor window. I don't want to see 2 windows open. Chromely also first opens a console window and then the Blazor window. I couldn't make it work in Linux. That leaves Photino. It comes with a Blazor sample that works in Linux without a problem. But my project didn't work in Linux with Photino. I found out that the problem was loading content for https://github.com/Megabit/Blazorise from the \wwwroot\_content folder. I sumbitted a GitHub issue and the problem was fixed in Photino.Blazor v2.5.0

I did something similar with Blazorise, a personal project of mine, https://blazorise.com/. It started as a hobby project. After some time it grew too large that it took most of my time, not to mention the time I could spend with my wife and son. Things changed during the Covid when I was laid off. Then I started freelancing for a while, and last year I finally took a big step and went full-time with Blazorise. Switched to dual licensing, where larger enterprises must purchase a commercial license. It is working, and hopefully, it will continue to work. Or otherwise, my wife will rage on me :/

My guess is that they're using component libraries (like Blazorise) rather than write components themselves.

> whereas Microsoft is actively sabotaging wine

Do you have a link to where I can read more about this? My understanding is that Microsoft saw Wine as inconsequential to their business, even offloading the Mono runtime to them [1] when they dropped support for it.

[1] https://www.mono-project.com/

So "mono.dll" exports a few symbols which we can use in our DLL. You can get the C++ SDK from here: Mono SDK On Github

Visual Studio mainly supports the Windows operating system and there is a version for macOS users called Visual Studio for Mac. There is no version for devices running Linux operating systems hence they access similar features like Visual Studio's through Mono . Note that Microsoft will soon be terminating VS for Mac by 31st August, 2024.

For everyone who is confused by what is going on, here's the explanation:

Today, there are 2.5 Mono's:

Mono that lives in https://github.com/mono/mono. This is the original Mono codebase that was written back then and was the .NET Framework for Linux, with corresponding compat. and such, pioneered by Miguel De Icana, who now seems to be happier in Swift land. At the present day, it was receiving very little maintenance and I don't believe was actively used. Please correct me if I'm wrong.

Mono that lives in https://github.com/dotnet/runtime/tree/main/src/mono. This is the mono that got "merged" into .NET, giving the basis for multiple components and becoming one of the official runtime flavours. It is actively maintained and is at relative feature parity with CoreCLR, predominantly serving mobile targets (iOS, Android) and WASM as well as exotic or legacy targets like ARMv6, LA64, s390x(?), ppc64. Note that you are not expected to use it for targets that support CoreCLR due to absolutely massive rift in performance between the two. When you are using it, you do so as a part of standard .NET toolchain - it is picked automatically for appropriate targets, or can be opted into with some configuration.

Mono that lives in https://gitlab.winehq.org/wine-mono/mono which is a Mono fork actively maintained by Wine for its own usage. Going forward, any possible ambiguities regarding ownership and stewardship are considered resolved and the ownership of mono/mono and everything related to it is transferred to WineHQ.

Honorable mention also goes to private Mono fork used by Unity which they are (painfully) trying to migrate from.

I'm not using the dotnet framework, just the clr, and for the use cases covered by Oberon+ security is of little concern. The project is still regularly updated, see https://github.com/mono/mono/commits/main/.

In the video you basically install .NET 7.0 SDK with the deb packages from Microsoft repos AND mono deb packages from repos laid out in https://www.mono-project.com/ apart from Unity and VS Code. And then you configure VS Code so that it always uses Mono installed in the system (not Unity Editor's own instance???)

4- Any user-side telemetry would be in the MS .Net framework, which is not used when you selfhost as .net based stuff like Jellyfin use Mono, which is fully open-source and independent (https://www.mono-project.com/)

Did they intentionally name it after a widely used, well known programming framework[1], or did they want to guarantee, I dunno, that they will fly way, way under the radar? I thought it was bad form to name a new programming language 'Cedar', but at least the other Cedar isn't actively developed, unlike the other Mono.

[1] https://www.mono-project.com/ for the few of you who didn't know.

.NET 4.8.1 and earlier do not install on Linux. Unless you want to play around with Mono (your mileage may vary): https://www.mono-project.com/

They have deceived you. https://www.mono-project.com/ I seriously don't know how well wine can deal with newer .NET winforms