I KNOW USING DIRECT CONNECTION TO DATABASE WAS A DUMB IDEA. TAKEN INTO ACCOUNT, WILL BE REPLACED WITH HTTP API IN NEXT VERSIONS. PLEASE DON'T LEAVE FEEDBACK ABOUT IT.

Publicly accessible? Well, if you share the database username and password, maybe yes.

The credentials can be taken from the disassembled source code, but I've already taken it into account. The next versions will use an HTTP API.

It doesn't need a database on the client side. It can connect to a server-side DB.

Same things will happen with other licensing libraries (or I'm dumb). BTW, you have to disassemble the client app first! I think non-free apps are almost always obfuscated.

Obfuscation isn't all that good when out to the real test.

Any .net app not compiled to native code can be disassembled if one is prepared to put any time to it.

Back when the .net Framework first came out, I was all over using the full Dotfuscator app thinking it would protect my apps. I was even more excited when I observed reflector giving up on it.

Right up until a friend of mine used a different app and showed me the deobfuscated code. I gave up at that point and realized it wasn't worth the effort.

Whilst your willingness to tip a toe in these waters is a good thing, I'd not hold out much hope of this library being used by many, if any people when there are some far better, more resilient and battle hardened versions out there.

I don't really think, either, anybody will use a library that is almost in the state of initial development. It's the first.

Secondly, what do you want? I could inject the license check into multiple parts of the library, but this is a dubious way.

Herein lies the issue.

Your library addresses issues that you personally have perceived exist with licensing software.

What you haven't done is ascertain what issues actually exist.

For example, what problem does your library alleviate?

There are other examples out there that can also be used for free, so it's not that.

There are examples that work natively across multiple environments, like Mac, Linux and Windows. Again, your library doesn't help there.

Java, C++, Swift etc.? Nope.

Centralized auditing? Cryptographically secure? Battle tested?

Sadly your local library strikes out everywhere - it's very core sadly let's it down because you didn't actually identify a problem to address, so your "solution" isn't really going to move a needle.

Multiple questions have been asked of you but nowhere have you really identified the audience for this library.

Why should someone use it over something else?

There's 100s of similar packages available on Nuget - many of them seemingly unmaintained.

For your library to be of use, you need to offer value over the cruft and crud.

Open source is a blessing and a curse. I've multiple packages out there that I thought were pretty neat at the time - and filled a niche spot. Few folk felt the same but that's fine by me as well.

Rather than try to iterate on this, I'd step back and ask yourself the hard question: what does your lib do better (or at least equally as well) as the competition?

And be severely critical. Given the stated purpose of this library, put yourself in the mind of an adversary: how quickly could you defeat it? If it's mere minutes then it's not good enough.

Look for all the weaknesses, look how other libraries fix the weaknesses.

In the end you may decide to give up. That's fine as well. Don't treat it as failure though, just use it as a stepping stone and try, try again.

Firstly, I don't think it's fine to give up.

I'll tell you how, I think, my library can be cracked. Of course, disassembling and deobfuscating. Then, I (adversary) have to find the is-license-valid method. Then make it return... not true, but an entity containing the corresponding information. (Which means I have to examine the structure of library.)

It's all, in the current version. I don't think it's enough, so I have a task to inject license validity checks into multiple places of the library. It'll cause headache after patching the is-license-valid method because there are other checks.

(Oh, yes, after patching I have to recompile the library.)

But in other licensing libraries the process is the same! My lib (at least when I'll "split" the license check) is not worse. Do you agree?

What does my lib do better than others? Let's start with the fact I couldn't find any "others" on GitHub. All licensing libraries I saw there work with "license files" (JSON/XML/something). I challenge you to find a competitor of mine there!

Then, what does it do better than the libraries working with license files? Such libs have one serious weakness. Someone payed for a license and got a signed file. Then he gives it to 10 friends, and they have activated program with no pay. This can't occur with my lib because each license activation is registered on the remote server, and it doesn't allow you to activate a license when there are too many previous activations.

What about "I didn't identify the audience of my library" — maybe I didn't catch it? Isn't it obvious?

I see no need to continue this discussion since you apparently feel your simple library built without understanding about actual real-life need, is better than the various battle tested ones out there.

I'd suggest you focus less on hubris and more and understanding.

Goodbye.

If you can't find arguments against what I said, say it directly. However, goodbye.

I know. It's another kind of licensing. I've created a library specifically for activation keys.

Please note it's only the first major version! Do you want a perfect, bug-free library in releases 1.x.x?! Your feedback was taken into account, though.

Our concern is in the core design of the product offering that shows some big weaknesses. Nobody is being deliberately critical here.

Taken into account. Maybe an HTTP API will be introduced in version 2.0.0. Thanks for leaving your feedback!

Currently working on the new API.

Great! But what's the difference between "play with dad" and "play with ai"? Is your dad really sitting all the time and playing Scrabble on this site?! :D

Well, isn't it just another post about unsafety of PINs like 1234?

This library is also available on NuGet under ID "SNBS.Licensing.ActivationKeys" and on its website: https://snbslibs.github.io/Licensing.ActivationKeys/