Not that I would recommend it, but you can also try something like extension methods on Func.

public static RunAndLog(this Func<T> f) {
 LogStart(f);
var x = f();
LogEnd(f);
return x;
}

I think you may have enough diagnostic info with reflection to write something meaningful, and you can add overloads with generic parameters for the func params, and/or Action.

You may also create an IDisposable that logs a start and end statement around a function call:

using var _ = CallLogger(“func name”) {
f();
}

Personally, I wouldn’t do either of these. This level of logging produces an enormous amount of noise, making finding signal very difficult. I would focus more energy on writing unique and helpful messages where they are important, and using git grep to find the related source code when they show up in production logs (assuming you don’t log a stack trace). This level of call logging can be temporarily useful while debugging or reasoning through an app, but rarely belongs in production.

You should probably report this as an issue on the dotnet runtime GitHub repo: https://github.com/dotnet/runtime

I would also suggest you include information on the hardware you’re using for this (architecture, ram, cpu, etc).

Your call, there are plenty of “define arbitrary entity” CMSes out there, and especially if you’re mainly using this as a configurable data store (hence headless), the amount of UI customization should be limited. I’d definitely try to flesh out the actual customization you expect to do in the longer term vs. how stuff works out of the box.

Even as a dotnet person, my general experience is that the stuff that’s built over NodeJS tends to get a lot more love and maintenance, and if you’re eventually going to build web pages, you’ll probably end up in Typescript/JavaScript pretty quickly, anyway.

I’m mostly a dotnet person, but another important factor in making this choice (and limiting your options to only dotnet), is how much customization you think you’ll do to the cms.

If you’re deploying it as a container and it’s backed by your preferred data store, you may not ever really do much with the headless CMS code.

I’d be looking at options written in go, or js/typescript.

https://jamstack.org is probably a good resource for surveying the options.

We had about 10-15 lambda “Microservices” each of these packaged up a service/contracts library to be consumed by other services that used them. We also had an MVC API and a few windows services that were built for a “distributed monolith”.

We built all all branches on every push, we tried to deploy updates multiple times a week.

We had 4 devs working on .net

The main thing with sleet is that I made zero effort to prune anything from the feed, so eventually it might cost a few dollars per month for S3 storage, but it was literally zero maintenance after we got it set up.

At my last job, we used sleet in combination with S3 and a cloudfront distribution with an authorization lambda for pulling packages. I think the whole setup took about 2 hours and it was rock solid.

This was necessary because we were using Octopus Deploy and were bumping into storage limits with their built in feed.

We were a relatively small team, and relatively slow package publish rate (10x a day, probably).

Biggest issue with sleet is that it’s not going to support “pull through” so you’ll need to have multiple nuget feeds configured.

I know almost nothing about machine learning, but I think you want to look into Text Transformers or Large Language Models. What you’re describing looks like you’re trying to build a model that would typically be used for classification, which is not how generative text systems work.

I know almost nothing about machine learning, but I think you want to look into Text Transformers or Large Language Models. What you’re describing looks like you’re trying to build a model that would typically be used for classification, which is not how generative text systems work.

When there is ambiguity in the behavior of something like this, it’s usually easier to just construct a unit test and see what happens.

Make a class with some deeply nested members and then do an assignment.

See what happens.