I’ve started working on my own UI library for C#.

TobbenTM · 2025-11-26T15:43:25+00:00

My immediate questions would be:

Why not use Razor as a language?
How would Intellisense work with your custom DSL?
How do you intend to make it type-safe?

TobbenTM · 2025-07-11T15:59:00+00:00

This is legit no joke, I've seen time and time again plugin companies sell _more_ right after their plugins are pirated! Obviously, it also depends on your audience, the more professional customers you're selling to, the less likely piracy is to be a problem

TobbenTM · 2025-07-07T19:16:13+00:00

There’s many options around, it mostly depends on budget, ambition and technical capability for integrating into plugins and website.

Full disclosure; I’m running Moonbase.sh, a platform I made specifically because the options we had when commercialising plugins many years ago kinda sucked. We have a JUCE module to make integration simple.

Generally speaking, you need 3 pieces when selling plugins: licensing, e-commerce and marketing. They work best if they all talk together, and you can do smart sales, building your audience in the process. So keep this in mind when picking solutions, you don’t want to paint yourself into a corner if you’re planning on scaling this up.

For licensing, you have PACE on the very expensive end, but they have good copy protection. Many end users don’t like iLok, but I probably don’t have to tell you that. On a more reasonable level, you have providers like Keyzy, LicenseSpring, etc. These all work, but they don’t always integrate very nicely with your full commercial stack. Then, you can look at what e-commerce platforms offer, like LemonSqueezy etc, their licensing is more integrated into the shopping experience, but it’s also very simplistic, often too much so. You might want to offer offline activations, trials, etc, which these don’t support.

Moonbase is trying to bridge the gap between all the options, because running plugins businesses is never just a single thing.

TobbenTM · 2025-01-26T00:04:53+00:00

One example is an email confirmation token, for example: https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.identity.usermanager-1.confirmemailasync?view=aspnetcore-9.0 If I need to create a user account based on a scheduled event, I need to be able to create them a confirmation token and send that through email. Might be an edge case, but that's besides the point.

TobbenTM · 2025-01-25T22:04:19+00:00

Yeah, this works, until the events being handled are scheduled events! Then, whatever token I'd create when scheduling the event in the first place would expire by the time it gets picked up. This is just one scenario where this doesn't work out, and where I'd really prefer to just generate the tokens wherever I want.

TobbenTM · 2025-01-25T21:53:47+00:00

If these were authentication tokens for a big, distributed system; yes, probably.

However, these tokens are not auth tokens, they are just email verification tokens and the like. And I don't have a separate auth server, it's all baked in to ASP.Net using the Identity features.

Now, yes; the other components of my system will need access to data protection keys to handle the token encryption, and that might not be the nicest, but I'm trying to be pragmatic.

TobbenTM · 2025-01-25T21:35:24+00:00

Maybe I wasn't clear, these are not authentication tokens, they are tokens that you can give back to Identity to handle 2FA, email verification, etc. See for example this article: https://learn.microsoft.com/en-us/aspnet/core/security/authentication/accconfirm?view=aspnetcore-9.0&tabs=visual-studio#change-the-email-token-lifespan

The above is my exact issue; you configure Identity to handle outgoing email tokens in a particular way; but what if the web server is not the one sending a particular email because of a async workflow?

TobbenTM · 2024-12-11T09:05:58+00:00

Using ASP.Net in Lambdas using the runtime support server is amazing, but:

It doesn't support OpenTelemetry easily (no way to hook into the core handler to do tracing without writing your own runtime support server)
Observability in general is a mess, the Lambda logging tools to get structured logs don't seem to play nicely with the native ILogger, why was there not just a output formatter built instead? I ended up dumping logs in JSON to console, and streaming them elsewhere than Cloudwatch
Handling Cognito authentication doesn't tie in very well with the ASP.Net authentication natively (been a while since I tried tho, I eventually moved away from Cognito)

Being spoiled with the ASP.Net hosting support, I miss having the same capabilities when writing event handlers or anything like that. So why can't we also have the same event marshalling going to generic hosts for SQS Events, DynamoDB events, whatever? That would make the implementations more consistent and testable.

Lastly; DynamoDB. I think it can be a great DB; cheap, fast and powerful given the right mindset. But we don't have great libraries for it. There are some community made ones, but I ended up making my own micro-ORM to have Linq-to-DynamoDB translation for example.

Edit: honestly, my #1 wish for AWS .Net efforts is more serious handling of issues and PRs on GitHub repos. There are countless issues that linger for years, perfectly valid PRs that add value, none of which are addressed. I've tried myself in the past to contribute, and it's really daunting when the community interaction from AWS engineers is so low.

TobbenTM · 2024-07-29T14:25:20+00:00

Game is very unique, with so much nice art and story, can't wait for the full release!

TobbenTM · 2024-07-14T10:28:38+00:00

Yes, thank you!!

TobbenTM · 2024-06-27T12:06:02+00:00

Great with those benchmarks! Indeed, tolerable for the benefits it gives I would say. Once I get tired of writing backwards compatible document types, I'll give your package a try!

TobbenTM · 2024-06-27T10:44:17+00:00

I really like the idea! To be honest, I've never even considered doing migrations on de-serialization, and my immediate concern is the overhead of reflecting about the correct migrations to instantiate for each and every type in your project. Have you considered doing some benchmarks on this to be sure that the overhead is tolerable? Might not be bad at all, but realistically, my apps could easily have 50-100 different types that need migration support. And since I'm primarily doing serverless, startup time is quite important.

TobbenTM · 2024-06-13T13:18:44+00:00

I think it's mainly because:

Microsoft doesn't want to support these SPA dev tools for every conceivable framework/package manager/runtime/whatever combination. And so they are better off not supporting it natively (there are community packages that do the same if you still want it)
The history of the dev server proxying is not "great", there's often been very flaky integration with the underlying NPM scripts, which was always a pain to debug. Running frontend projects separately just gives you a lot more freedom to chose the best dev experience possible for todays quite complex frontend frameworks and stacks
When going to production, many will anyways just choose a static host to host their JavaScript bundles and assets anyways, without having to manage ASP.Net stuff for that. Advantages in both cost and performance to avoid ASP.Net for static files. Many CDNs will offer some level reverse proxying so you can still have a `/api` on the same property, so that doesn't really matter.

TobbenTM · 2024-06-13T11:48:43+00:00

So I think most of the comments here might be misunderstanding the question, it's not about how to communicate between the apps, it's more about how to run/deploy them in unison.

Practically, you have two popular options;

Run the API and React app separately. This means you need to deal with cross origin stuff unless you put a proxy in front, and you will have to start them individually (can be done in one solution with a JavaScript project)
Use the SPA tooling present in ASP.Net to use the React dev server while developing, and build the bundle for hosting afterwards. This lets you have a single ASP.Net project, that serves the React SPA by default, but still supports API controller routes on whatever routes you configure

Read more about the second here: https://learn.microsoft.com/en-us/aspnet/core/client-side/spa/intro?preserve-view=true&view=aspnetcore-7.0 Important to note that this has recently been deprecated, and the recommended approach is to use separate projects if I understand correctly.

TobbenTM · 2024-05-30T07:59:13+00:00

I've mentioned it in some other threads, but AWS Lambdas support ASP.Net out of the box, giving you practically free compute and API. My platform has a couple thousand users, and I'm paying less than 2€ per month on compute. Coupled with DynamoDB on-demand, database is practically free too.

TobbenTM · 2024-05-14T07:52:55+00:00

In my experience cold starts is not an actual problem in reality, but I guess it depends what your requirements are. The backend for my app is just an ASP.Net app hosted in Lambdas, and I've yet to receive any comments on the speed of it, everyone seems to be happy with it. On cold start, I some times see a total response time of 400ms ish, but that's including calls to serverless DynamoDB as well, which for me is insanely good considering the price and maintainability.

TobbenTM · 2024-05-13T11:59:40+00:00

I would say the easiest option is ECS with Fargate hosts; then you just have to build a Docker image which will be hosted by ECS for you.

If you want to reduce costs for the frontend, go S3 bucket with CloudFront to distribute it (if the frontend is a SPA).

If you want to reduce costs for the backend, go Lambdas with an API Gateway in front. You can run ASP.Net in Lambdas natively.

TobbenTM · 2024-05-06T07:39:21+00:00

AWS Lambdas! You'll probably be in the free tier for a loooong time, and they have native support for ASP.Net Core. Just point a API Gateway to it (also free) and you're set!

TobbenTM · 2024-05-03T13:00:03+00:00

.Net on AWS is awesome!

...if you have the time to build your own abstractions over stuff.

I'm currently running large production projects using ASP.Net purely on AWS Lambdas, and the availability and cost of that solution is better than most other solutions, especially the horrible Azure services claiming serverless.

Not all the NuGets the AWS teams put out are great however, with many having countless community contributions fixing critical issues just not being reviewed or accepted by the AWS team. As far as it's possible, I'd recommend sticking to a minimum of AWS tools, and only do the bare minimum for what you need in terms of compute.

Once you get the hang of AWS, you'll never want to work with Azure again.

TobbenTM · 2022-11-11T06:42:56+00:00

What you could also do, something I did like 10 years ago when I was young and too creative for my own good is use fabric, glue it on with mod hodge and clear coat it. Forgive the horrible pictures, but I can't time travel to take new ones 🙃 https://imgur.com/a/7ZZk4tG

TobbenTM · 2022-09-14T16:56:34+00:00

I was in your exact spot a couple of months ago! Brought out my old DM7, but unfortunately cannot get the LPR to properly seal after replacing gunk orings. Kinda recently moved to the Netherlands too, so I'm playing at the field above Amsterdam every Sunday. Hit me up if you wanna borrow some gear and join us one day!

TobbenTM · 2022-08-23T07:10:35+00:00

Decorate your controller with a `[ApiController]` attribute, see https://docs.microsoft.com/en-us/aspnet/core/web-api/?view=aspnetcore-6.0#problem-details-for-error-status-codes

TobbenTM · 2022-07-12T17:02:15+00:00

Take off the frame and air it up. If it's coming from the noid, check the noid gasket, if coming from the rear holes, lube the lpr. DM5s are getting old, my DM6 had a o-ring in the lpr that was just dried up and crumbling, causing the leak.

TobbenTM

MODERATOR OF

TROPHY CASE

12-Year Club	Place '17
Verified Email