|
Is there a free licensing solution for .NET?
It can be hosted on the cloud or self-hosted.
Requirements: works with C# and unlimited licenses.
Can be hosted anywhere, except in the app or in a website (Only the app can access the product keys)
Thanks!
|
|
|
|
|
Why would someone not charge if it had all those features?
This is simply Google legwork and has nothing to do with "programming in C#".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Cloud-hosted will always cost money because cloud doesn't come free.
You host find a solution that you can host on your own servers, but that's not going to be free either. Power to run servers and ISP costs money.
"Can be hosted anywhere, except in the app or in a website", well, where the hell else are you going to host the servers that hold the licenses?
Basically, a "free" license server doesn't exist.
|
|
|
|
|
I am working on an app that uses a Service Locator. Then, someone above me decided that a service locator is "an anti-pattern". I'm guessing they read this or some other bright spark's blog.
There's another excellent discussion here.
I've been using a service locator for a long time with no issues. I'd like to hear what everyone else thinks. Is there any reason NOT to use a service locator?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
The "service" is still just an object. It's object-oriented programming with a nod to component-based programming. You write more code (interfaces). Pointless when the caller deals with only one type; i.e. is not of the switchboard variety. It then become a chore adding to everything, because that's the "standard".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
While I agree with you, I'm not sure if you answered my question. Any real reason NOT to use them?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Gerry Schmitz wrote: You write more code (interfaces). Pointless when the caller deals with only one type
I assume you never write unit tests then? 
(Yes, I'm aware it's possible to generate a mock of a class for a test. But it's generally easier to generate a mock for an interface, since you don't have to worry about inheriting from a class which might produce undesirable side-effects in your tests.)
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
From the top of my head:
Dependency injection makes it a bit easier to write unit tests - you do not have to mock the service locator and you can see straight from the constructor what the dependencies are.
It is also better failing early. It can often detect missing dependencies when you spin up the app, instead of when some obscure case happens 3 weeks after deploying to production. It's not guaranteed for complex registrations (factories) but the simple stuff it will do.
I would always use DI for new projects, but it's unlikely I would spend time refactoring old SL based code. I can say from the code base I have inherited: If you use both in the same application everything becomes a mess. 
Edit: Followed the link and read his "summary" - which is basically identical to my reply.
|
|
|
|
|
That link suggests that DI has the same issue of service locator with regard to runtime discovery of failure.
That is only true if you equate "app will not launch runtime" with "app conditionally crashes/errors runtime".
Those are not the same beast. The OA at the link wraps up with that, and lots of people chime in with similar reasons.
I think the question should be is there any reason NOT to use DI? There are clearly drawbacks to SL even if someone doesn't care about them. "Anti-pattern"? That's probably a bit of hot air blown hard. But DI is better.
|
|
|
|
|
It's been weeks of searching everywhere but couldn't find any help and finally i'm posting my query here.
I'm not finding a way to integrate Skype Personal (Not Skype Business/Lync) in my c# application. I just want to receive Skype messages on my application. I have tried using Skype4com Library but it has discontinued and does not support the latest Skype and LYNC API also works only with Skype for business and same with Skype Web SDK as it does not work with Skype personal. I also tried the method to fetch the details through Skype local database but latest version of Skype doesn't store anything locally.
Note: There are still some applications with Skype integration that I know but I don't know how they do that.
|
|
|
|
|
I guess that's the difference between "free" and "not free". You can spend (waste) more time looking for free than paying for not free. And, who is the ultimate customer.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
What do you mean with free and not free?
|
|
|
|
|
I guess the "not free" means one must pay some mony for it. 
|
|
|
|
|
There aren't any paid api's too.
|
|
|
|
|
Integration for the personal (free) version is not supported, you need to be using the business (not free) verion to be able to extend/integrate its functionality. I recall spending many hours searching for a solution before the bank gave up and forked over the money to MS for the business version.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
I appreciate your comment but there are still applications manage to track skype personal messages. I'm so curious to find how they do that.
|
|
|
|
|
Hi,
Why Sample #2 is "Bets Practices". Second sample include "await" keyword on the same line with Async Method. Both codes are blocking Thread. Any idea? thanks...
Sample #1
var products = _context.Products.ToList();
Sample #2
var products = await _context.Products.ToListAsync();
|
|
|
|
|
It gets a complicated, but basically the await call spins off a second thread to execute the long running task, and effectively suspends the method until it's complete. But ... the thread that executed await can continue as if the method had finished.
This is handy if you want to run a long task from the main (UI) thread while the UI remains responsive.
For example, if you run this code:
private void MyOtherButton_Click(object sender, EventArgs e)
{
Debug.WriteLine("Before Sleep");
Thread.Sleep(10000);
Debug.WriteLine("After Sleep");
}
Your console will print "Before Sleep", wait ten seconds and print "After Sleep" - but your user can't do anything else with your app in the mean time.
But this code:
private async void MyOtherButton_Click(object sender, EventArgs e)
{
Debug.WriteLine("Before Sleep");
await Task.Run(() => Thread.Sleep(10000));
Debug.WriteLine("After Sleep");
}
Prints the same things, but your user can carry on working - your UI remains working.
Have a look here: https://www.pluralsight.com/guides/understand-control-flow-async-await[^] - it explains it pretty well, and shows examples.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: the await call spins off a second thread to execute the long running task
A common misconception. 
await is almost nothing to do with multi-threading; it's more about using IO-completion ports to avoid keeping a thread spinning whilst it waits for an external resource to respond.
OriginalGriff wrote:
private async void MyOtherButton_Click(object sender, EventArgs e)
{
Debug.WriteLine("Before Sleep");
await Task.Run(() => Thread.Sleep(10000));
Debug.WriteLine("After Sleep");
}
Aside from the fact that you should avoid async void wherever possible[^], spinning up a background thread just to make it sleep seems like a bad idea.
private void MyOtherButton_Click(object sender, EventArgs e)
{
_ = MyOtherButton_Click_Async();
}
private async Task MyOtherButton_Click_Async()
{
Debug.WriteLine("Before Sleep");
await Task.Delay(10000);
Debug.WriteLine("After Sleep");
} See David Fowler's explanation of the _ = SomeTaskReturningMethod(); construct under the "Timer callbacks" heading: AspNetCoreDiagnosticScenarios/AsyncGuidance.md at master · davidfowl/AspNetCoreDiagnosticScenarios · GitHub[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
modified 20-Sep-22 11:11am.
|
|
|
|
|
The second code example doesn't block the thread; it blocks the rest of the method until the call has completed. The low-level thread is freed up to deal with other work until the ToListAsync call completes.
Think of it like a car journey: in the first sample, your kids (the thread) spend the whole time yelling "Are we there yet? Are we there yet? Are we there yet?" until you reach your destination; with the second sample, they get on with reading a book quietly until you tell them you've arrived. One of those scenarios makes for a much nicer journey. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
A beautiful example, thank you for that.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
I got my answer, thanks.
I have one more question. You said "it blocks the rest of the method" yes the following codes will not be executed until the job is complete, what exactly is waiting here? I guess it was a deep question 
|
|
|
|
|
Behind the scenes, your async method will be rewritten into a state machine. Whenever you await something, so long as that operation doesn't complete immediately, the rest of your method will be signed up as a "continuation" to run when that asynchronous operation completes.
As a simple example:
public async Task Foo()
{
Console.WriteLine("Start...");
await Task.Delay(1000);
Console.WriteLine("Done.");
} would (logically) turn into something more like:
public Task Foo()
{
Console.WriteLine("Start...");
return Task.Delay(1000).ContinueWith(_ => Console.WriteLine("Done."));
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
Hello there!
I am new to this forum and I am also a beginner C# coder. I am trying to make a paid app but I will need to make a license key system. Do anyone know any tutorials I can use for this?
It should check the Realtime DB for the license key and check get the processor ID (or any other unique identifier) then it will check your device for the unique id and boom! you are in.
Or if there are any other tutorials please do link them in the comments below thanks!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
