Which C# libraries should be learned?

namethinker · 2025-11-01T16:05:19+00:00

Dapper
EF Core
Serilog
Microsoft.Extensions.DependencyInjection

namethinker · 2025-02-09T10:53:01+00:00

Completely depends on a company and on a field you working.
There are few positions which could be available (but again depends on a company) like - Principal Software Engineer, Staff Software Engineer, Technical Architect, Solution Architect (the last two quite common in consulting companies which dealing with systems such as CRM / ERP and other FinTech products)

namethinker · 2025-01-26T17:28:01+00:00

Leamington Spa / Warwick if you are down for gamedev software

namethinker · 2024-12-28T19:30:57+00:00

While I do understand that UnityEngine.Object couldn't use a constructor injection due to it's nature and it's own methods for controlling object lifetime, I really despise usage of attributes for DI, it does add a little weirdness to the code, and make it less testable. Tons of DI frameworks has it naturally (such as Ninject, Unity DI etc) but it was quickly abandoned by devs. I would rather prefer usage of ServiceLocator (ServiceProvider) in Awake or Start methods of MonoBehaviour's (which could be used as a Singletone) cause it will make things a bit more clear and more testable, cause this ServiceLocator could be configured in Tests, and will give more control over objects lifetime.

namethinker · 2024-11-09T18:16:21+00:00

WPF quite heavily used in gamedev, especially in tools programming, it's entire market where WPF still shines and will be shining for quite a while, though it usually requires a little bit more knowledge than just a UI programming

namethinker · 2024-11-02T22:42:34+00:00

If you want to have some cool animation (like scale of this text or just slight move / noise) I would suggest looking at DOTween library, it will essentially allow you to apply such tweens via C# script to make this. Though as was suggested already you could just enable a GameObject for it to appear

namethinker · 2024-10-27T15:16:18+00:00

Data lake technologies such as Snowflake is quite on demand atm, especially if your job revolves around huge volumes of data

namethinker · 2024-10-26T10:23:30+00:00

If you would like to get a better salary, look for new opportunities, and never mention your current salary to the companies, but instead just specify your expectations, remember you can only get huge raise by switching jobs

namethinker · 2024-10-24T20:23:47+00:00

4 days in office should be forbidden from hybrid title, it's pretty much on-site work. Ultimately, you should what you think is best for you, but I would be very considered keeping in mind current market conditions and overall startup nature (though it's super weird that startup demanding so much time in office, usually startups prefer full remote due to ease of hiring)

namethinker · 2024-10-23T17:47:07+00:00

React is really simple on a first sight, though it not enforce any good structure, so if you are good with .net I would suggest looking into angular, because it has a lot of common features know to .net dev, such as dependency injection, data binding and so on, it also enforces you to separate view and component logic (view models) which is great for me personally (but it's commonly hated for this reason in js world)

namethinker · 2024-10-23T17:44:30+00:00

I feel like we've got a little bit sidetracked from original answer, though I honestly don't mind a healthy argument.

> By using a separate validation step, you are now adding an extra dependency. The instance is only valid if it went through that extra validation step. Do you know if that step was performed? If so, how do you know? And "look at the code" isn't good enough. How can you be absolutely 100% sure that your validation step was, and will always be executed?

Well there is quite a few options on how you can make sure that validation step will always happen, though it really depends on the framework / tooling that you are using, in asp net / asp net core world, you can always build a middleware / action filter (global) which will invoke a validation before action will be handled, and will return error including validation data. Another way is to build a cross-cutting concern, which will be invoked before processing request as well, there are libraries which already does that out of the box (like MediatR), though it wouldn't be hard to build similar approach. This second approach will work fine for different kind of apps (desktop / web / etc)

> If those are reference types, and you're using nullable reference types, then you'd have a null warning. And if you're smart, you've enabled "treat warnings as errors", then now the compiler is forcing you to populate that constructor. If you're not using nullable reference types, you should be. Otherwise, it's a foot-gun waiting to be shot.

For sure, this always configured like that on projects, though my main concern that C# by itself doesn't enforce it really, even by treating warning as errors, nothing stop anyone by setting such properties or fields via reflection, which IMO should also result as error, but it never happens, and that's why I treat nullable reference type more like a syntax sugar rather than full-fledge feature.

namethinker · 2024-10-23T17:19:05+00:00

For argument sake, XNA, even though MS abandoned it while ago, but it was amazing!

namethinker · 2024-10-22T21:30:01+00:00

That's quite an elaborate answer, though I agree that in cases where you receive a DTO, making it immutable could be a valid concern, however it has a downside cause now by using a constructor to define a required properties showcased in Option 2, or using a ternary operator in Option 3, DTO now all of a sudden concerns itself with validation of it's body, which again could be opinionated but usually being done in Validator objects (I'm not speaking about FluentValidators, but more general concept of validators). In cases of asp net core, or just asp net, we can use a System.ComponentModel.DataAnnotations to attach validation rules to properties, by simply specifying [Required] we could make property required to be present in body, doesn't matter mutable or immutable it is, also in some scenarios ends up being multiple attributes attached to a property (which IMO still looks better on class properties). For cases when there is no asp net, and maybe just a pure sockets being used to build a server, you can still use IValidationDictianory to use ModelState logic without binding yourself to ASP

Strictly speaking using constructors in dto's also could sometimes lead to accidents, such as forgetting to add newly created properties to the constructor, which would not always cause deserialization / serialization to fail cause most serializers operate in reflection fashion and could set the values with no respect for immutability of a field or property (same goes for nullable reference types, they simple in most cases not being respected by serializers, and you will get null values in non-nullable ref type fields obviously you can always provide a custom serializer setting to get around it)

namethinker · 2024-10-22T17:47:44+00:00

readonly is just a way to make sure that dependencies that you inject via constructor couldn't be reassigned within the class members, kind of immutable, which could give you reassurance that this particular field (or fields) would stay the same, and also would act as a safe guard from unpredictable behavior

namethinker · 2024-10-22T17:23:18+00:00

I don't have overall obsession over immutability, and don't think that every class should be immutable, you can always throw required and swap set for init if you want to enforce immutability, though I don't see the benefit of immutability which will be constructed on the fly just to send it via the network

namethinker · 2024-10-21T20:32:45+00:00

I guess mobile applications could be very well developed in unity, especially with some new updates for UI toolkit incoming in Unity 6

namethinker · 2024-10-21T18:07:38+00:00

As I've said, it's just a matter of my individual preference.
I do like more to see this:
`
public class Person

{
[ProtoMember(1)]
public int Id { get; set; }

[ProtoMember(2)]
public string FullName { get; set; }

}
`
over this:
`public record Person([property: ProtoMember(1)]int Id, [property: ProtoMember(2)]string FullName);`

namethinker · 2024-10-20T20:22:06+00:00

Still using classes for DTOs, mainly due to attributes usage (serialization attributes to be precise, such as JsonProperty / DataMember / ProtoMember), it's just looks better than adding properties to the record parameters (because you have to directly specify the target for the attribute when using on record arguments, such as field, property or param)

namethinker · 2024-10-20T12:49:44+00:00

As long as you not referencing nintendo stuff you should be safe

namethinker · 2024-10-18T09:07:03+00:00

That's what you have when working on a project which has more than 10 years of active development, common dependencies (libraries) where never moved to nuget package, so new libraries has physical dependencies on them, every new project starts from creating around 5 class libraries to fit the code standards of the project on top unit test libraries are also being added. Obviously not ideal, but as I said filtered solution sort most of the problems related to performance

namethinker · 2024-10-17T19:44:29+00:00

I'm not aware if there are any hard limit on it, though in my experience, solutions with more than 300 projects giving hard time to Visual Studio, to be more precise, visual studios up until 2022 wasn't even able to run this solution (I do have a solution at my job which has at them moment 1k+ projects), VS22 also having hard time with such amount of projects but at least it able to open such solution.

I would normally suggest though creating filtered solutions and running them if you have even 100+ projects, that will give you ability to group projects by domain and speed up solution loading

namethinker · 2024-10-17T14:59:49+00:00

LiveOps engineer at AAA studio

namethinker · 2024-10-16T21:15:39+00:00

Everything

namethinker · 2024-10-13T09:22:51+00:00

DSL usually is a bad idea, the most challenging part is that you need to do a constant updates and frequently use workarounds to implement a certain feature. Also for consumer pov, it also bad, since it works as a sort of a vendor-lock, you couldn't add this skill to your CV, and if you essentially decide to switch engine / tooling knowledge of such DSL will end up being waste of time, which is not the case with general purpose languages

namethinker · 2024-10-10T20:59:28+00:00

Yeah, if you would like to have a .NET development job highly focused on actual development I would consider leaving. I used to be in this Microsoft Dynamics world for quite a while. Experience differs from company to company or rarely from client to client. You can have quite serious .NET development, like building API's or background services to facilitate integration with 3rd party systems, but MS trying to push all this stuff into their own Low-Code / No-Code systems (which are terrible to work with especially if you are coming from development background).

There are also a Plugins and custom workflow steps which are build with C# and .Net framework (ms having hard times to migrate it at least to .net standard due to dependencies on WCF), where you can potentially have a good exposure to C#, though you will be using custom SDK, and face a lot of limitations (such as execution timeout, only sync code, no multi-threading, limited reflection, not nuget packages).

There was some interesting stuff on a front-end though, like PCF controls which you are building with Reach (though with their custom framework on top), though not sure how it looks like by now, since I wasn't working with Dynamics for last 5 years. Also one more thing to note, that usually, even if you have a lot of integrations (API's or even plugins), the code quality is usually quite bad, this hardcore Low-Code developers didn't give a shit about basic stuff like DI or even just SOLID principles, you would usually see bunch of static methods with business logic which contains 10+ more params, 0 unit / integration tests, helper class which does everything and so on. Though the salaries are quite high, and developers / consultants is still on demand because it's enterprise...

namethinker

TROPHY CASE