Gauging interest on a .NET project/article
-
I recently created several demonstrations of message queues, and demonstrations of custom async/await scenarios. Some time ago I created self-hosting service executable, which presented a neat way to control your service, install/uninstall it as a service, or simply run as a normal console application that blocks until it receives a kill signal. I've been thinking of combining them into a kind of inherently asynchronous service framework where you can create these little self hosting hybrid service/CLI apps and then your code inside them can do things like spawn background workers that report back to your primary thread like they do on winforms so everything is synchronized between threads. The trouble is, I think most services people are writing these days are internet facing and on the ASP.NET, node.js or similar platform rather than being like daemons. I'm not even sure if this would be that valuable. And if it is, do you have any ideas you'd like to see in it? Thanks for your thoughts!
Real programmers use butterflies
-
I recently created several demonstrations of message queues, and demonstrations of custom async/await scenarios. Some time ago I created self-hosting service executable, which presented a neat way to control your service, install/uninstall it as a service, or simply run as a normal console application that blocks until it receives a kill signal. I've been thinking of combining them into a kind of inherently asynchronous service framework where you can create these little self hosting hybrid service/CLI apps and then your code inside them can do things like spawn background workers that report back to your primary thread like they do on winforms so everything is synchronized between threads. The trouble is, I think most services people are writing these days are internet facing and on the ASP.NET, node.js or similar platform rather than being like daemons. I'm not even sure if this would be that valuable. And if it is, do you have any ideas you'd like to see in it? Thanks for your thoughts!
Real programmers use butterflies
-
Any well written article is worth publishing. Even if you think the subject is somewhat specialised it may still contain things that people can use elsewhere. You will only really know if it's worth it by the votes and feedback.
True. I guess I'm just curious if people write service executables like this anymore. :)
Real programmers use butterflies
-
I recently created several demonstrations of message queues, and demonstrations of custom async/await scenarios. Some time ago I created self-hosting service executable, which presented a neat way to control your service, install/uninstall it as a service, or simply run as a normal console application that blocks until it receives a kill signal. I've been thinking of combining them into a kind of inherently asynchronous service framework where you can create these little self hosting hybrid service/CLI apps and then your code inside them can do things like spawn background workers that report back to your primary thread like they do on winforms so everything is synchronized between threads. The trouble is, I think most services people are writing these days are internet facing and on the ASP.NET, node.js or similar platform rather than being like daemons. I'm not even sure if this would be that valuable. And if it is, do you have any ideas you'd like to see in it? Thanks for your thoughts!
Real programmers use butterflies
I have 'inherited' some services and have to create new ones using the same design as the inherited ones. They consist of a service project (which consists mainly of internal scheduling and the doing bit [as a separate class in the later ones but intertwined in with the scheduling parts in the older ones]) and a console project for testing that (in the better ones) calls the 'doing' bit. I usually forget about switching the startup from running the console project to running the service project when I publish it. So your article could help me.
-
I recently created several demonstrations of message queues, and demonstrations of custom async/await scenarios. Some time ago I created self-hosting service executable, which presented a neat way to control your service, install/uninstall it as a service, or simply run as a normal console application that blocks until it receives a kill signal. I've been thinking of combining them into a kind of inherently asynchronous service framework where you can create these little self hosting hybrid service/CLI apps and then your code inside them can do things like spawn background workers that report back to your primary thread like they do on winforms so everything is synchronized between threads. The trouble is, I think most services people are writing these days are internet facing and on the ASP.NET, node.js or similar platform rather than being like daemons. I'm not even sure if this would be that valuable. And if it is, do you have any ideas you'd like to see in it? Thanks for your thoughts!
Real programmers use butterflies
honey the codewitch wrote:
I'm not even sure if this would be that valuable.
I learn with your articles, even if I afterwards don't use it. So yes, I think it will be worth.
honey the codewitch wrote:
The trouble is, I think most services people are writing these days are internet facing and on the ASP.NET, node.js or similar platform rather than being like daemons.
Not me
honey the codewitch wrote:
Some time ago I created self-hosting service executable, which presented a neat way to control your service, install/uninstall it as a service, or simply run as a normal console application that blocks until it receives a kill signal.
I have lately done something that could have used some bits of that, at the end solved in a less fancy way ;)
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
honey the codewitch wrote:
I'm not even sure if this would be that valuable.
I learn with your articles, even if I afterwards don't use it. So yes, I think it will be worth.
honey the codewitch wrote:
The trouble is, I think most services people are writing these days are internet facing and on the ASP.NET, node.js or similar platform rather than being like daemons.
Not me
honey the codewitch wrote:
Some time ago I created self-hosting service executable, which presented a neat way to control your service, install/uninstall it as a service, or simply run as a normal console application that blocks until it receives a kill signal.
I have lately done something that could have used some bits of that, at the end solved in a less fancy way ;)
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
Thanks for your consideration of this. I really appreciate your input! :)
Real programmers use butterflies
-
I have 'inherited' some services and have to create new ones using the same design as the inherited ones. They consist of a service project (which consists mainly of internal scheduling and the doing bit [as a separate class in the later ones but intertwined in with the scheduling parts in the older ones]) and a console project for testing that (in the better ones) calls the 'doing' bit. I usually forget about switching the startup from running the console project to running the service project when I publish it. So your article could help me.
Thanks for your input! :)
Real programmers use butterflies
-
I recently created several demonstrations of message queues, and demonstrations of custom async/await scenarios. Some time ago I created self-hosting service executable, which presented a neat way to control your service, install/uninstall it as a service, or simply run as a normal console application that blocks until it receives a kill signal. I've been thinking of combining them into a kind of inherently asynchronous service framework where you can create these little self hosting hybrid service/CLI apps and then your code inside them can do things like spawn background workers that report back to your primary thread like they do on winforms so everything is synchronized between threads. The trouble is, I think most services people are writing these days are internet facing and on the ASP.NET, node.js or similar platform rather than being like daemons. I'm not even sure if this would be that valuable. And if it is, do you have any ideas you'd like to see in it? Thanks for your thoughts!
Real programmers use butterflies
honey the codewitch wrote:
Some time ago I created self-hosting service executable, which presented a neat way to control your service, install/uninstall it as a service, or simply run as a normal console application that blocks until it receives a kill signal.
tl;dr - yes please long version - I think they are still 'needed' - Having previously written services with TopShelf, Quartz, when I was 'cut loose due to Covid-19' I started experimenting with self-hosting, DI & IOC, plus async/wait etc so I'm always looking for better/different ways of doing things - oh, plus logging of course .. if someone comes to me with an issue in a 'service' but no logging etc, my response is 'yes, you have an issue, come back when you really understand what at a minimum services should have' (I think Topshelf & Quartz are still good, but would re-arrange the Quartz jobs for example using DI/IOC)
Quote:
normal console application that blocks until it receives a kill signal.
I've always hated the 'press any key to exit program' and much favoured the Control-C/Break trap/handler to send a quit signal looking forward to seeing what you have - an old dog who does learn new tricks :)
-
honey the codewitch wrote:
Some time ago I created self-hosting service executable, which presented a neat way to control your service, install/uninstall it as a service, or simply run as a normal console application that blocks until it receives a kill signal.
tl;dr - yes please long version - I think they are still 'needed' - Having previously written services with TopShelf, Quartz, when I was 'cut loose due to Covid-19' I started experimenting with self-hosting, DI & IOC, plus async/wait etc so I'm always looking for better/different ways of doing things - oh, plus logging of course .. if someone comes to me with an issue in a 'service' but no logging etc, my response is 'yes, you have an issue, come back when you really understand what at a minimum services should have' (I think Topshelf & Quartz are still good, but would re-arrange the Quartz jobs for example using DI/IOC)
Quote:
normal console application that blocks until it receives a kill signal.
I've always hated the 'press any key to exit program' and much favoured the Control-C/Break trap/handler to send a quit signal looking forward to seeing what you have - an old dog who does learn new tricks :)
I initially thought dev time would be a day or two with the article, but I ran into an issue wherein the service class doesn't give me access to the main message loop (
ServiceBase.Run()blocks likeApplication.Run()does) That means either my message queue or the service class itself must run on an auxiliary thread. This is complicating things, because it means postawaitcode itself may fire on the main thread like it's supposed to, but things likeOnStart()andOnStop()fire from an auxiliary thread, and that's even if I can callServiceBase.Run()from a different thread thanMain()'s but i think it will let me. As far as the console mode it terminates on Ctrl+C or running it again elsewhere with the command switch /stop :) Edit: having to articulate the problem helped me work through it. :) I just need to figure out what to do about the original OnStart() method. HmmmReal programmers use butterflies
-
I initially thought dev time would be a day or two with the article, but I ran into an issue wherein the service class doesn't give me access to the main message loop (
ServiceBase.Run()blocks likeApplication.Run()does) That means either my message queue or the service class itself must run on an auxiliary thread. This is complicating things, because it means postawaitcode itself may fire on the main thread like it's supposed to, but things likeOnStart()andOnStop()fire from an auxiliary thread, and that's even if I can callServiceBase.Run()from a different thread thanMain()'s but i think it will let me. As far as the console mode it terminates on Ctrl+C or running it again elsewhere with the command switch /stop :) Edit: having to articulate the problem helped me work through it. :) I just need to figure out what to do about the original OnStart() method. HmmmReal programmers use butterflies
Quote:
having to articulate the problem helped me work through it
you need a teddy bear to articulate to - it doesn't need to solve the issue (and likely won't), but as you've discovered, just articulating forces clarification (most times) in your head good luck, I'm sure you'll figure it out
-
Quote:
having to articulate the problem helped me work through it
you need a teddy bear to articulate to - it doesn't need to solve the issue (and likely won't), but as you've discovered, just articulating forces clarification (most times) in your head good luck, I'm sure you'll figure it out
Teddy bear? The traditional debugging aid is a rubber duck. Rubber duck debugging - Wikipedia[^] ;P ;P ;P Years ago (40-some) I used to pace up and down the cube farm muttering to myself. Eventually, my boss (who occupied the cube nearest the escape route) would call me in and ask me to explain the problem to him. I usually got about 3 sentences out before the lightbulb went on. RKI, wherever you are, thanks again! Cheers, Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
Teddy bear? The traditional debugging aid is a rubber duck. Rubber duck debugging - Wikipedia[^] ;P ;P ;P Years ago (40-some) I used to pace up and down the cube farm muttering to myself. Eventually, my boss (who occupied the cube nearest the escape route) would call me in and ask me to explain the problem to him. I usually got about 3 sentences out before the lightbulb went on. RKI, wherever you are, thanks again! Cheers, Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
:laugh:
-
I recently created several demonstrations of message queues, and demonstrations of custom async/await scenarios. Some time ago I created self-hosting service executable, which presented a neat way to control your service, install/uninstall it as a service, or simply run as a normal console application that blocks until it receives a kill signal. I've been thinking of combining them into a kind of inherently asynchronous service framework where you can create these little self hosting hybrid service/CLI apps and then your code inside them can do things like spawn background workers that report back to your primary thread like they do on winforms so everything is synchronized between threads. The trouble is, I think most services people are writing these days are internet facing and on the ASP.NET, node.js or similar platform rather than being like daemons. I'm not even sure if this would be that valuable. And if it is, do you have any ideas you'd like to see in it? Thanks for your thoughts!
Real programmers use butterflies
I'd be interested - it would be a lot better than the inherited setup I'm supporting now, which basically starts a process, sleeps for a random time (2-7 minutes), then looks to see if the process it started is still running so take another nap, or if it should send an email saying it's done. I'd love a better control process than the "it's running, I guess it's OK" or "it's not running, I guess it finished successfully" that I have now.
-
True. I guess I'm just curious if people write service executables like this anymore. :)
Real programmers use butterflies
In my last job I wrote several of them. Many solutions to the projects we were working on were solved using Windows Services. I developed a template (not a Project Template, just a chunk of code to start from as it didn't work right for me) and started off all my Services from that. It was basically a stub Service with a DLL that did all the real work. This way I could easily run it in debug via a debug stub. I always wanted to expand the "template" to handle all cases but I never had the time. My new job never seems to use Services and does everything via web-initiated console programs. This is a culture thing mostly -they could do a lot of this stuff with Services but it seems I am the only person here who has had any experience with them and no-one else wants to touch them with a barge pole. oh well.
- I would love to change the world, but they won’t give me the source code.
-
In my last job I wrote several of them. Many solutions to the projects we were working on were solved using Windows Services. I developed a template (not a Project Template, just a chunk of code to start from as it didn't work right for me) and started off all my Services from that. It was basically a stub Service with a DLL that did all the real work. This way I could easily run it in debug via a debug stub. I always wanted to expand the "template" to handle all cases but I never had the time. My new job never seems to use Services and does everything via web-initiated console programs. This is a culture thing mostly -they could do a lot of this stuff with Services but it seems I am the only person here who has had any experience with them and no-one else wants to touch them with a barge pole. oh well.
- I would love to change the world, but they won’t give me the source code.
Thanks for your input! :) Today I half decided I might take a break from programming for a bit, so I might delay the project but we'll see
Real programmers use butterflies
-
Thanks for your input! :) Today I half decided I might take a break from programming for a bit, so I might delay the project but we'll see
Real programmers use butterflies
When I was about 10 years old, through until about 16, I made models. Airfix aircraft kits and Tamiya tanks. It was fun! Recently my wife suggested I had another go as it was something entirely different to programming - although it still needed attention to detail and a lot of patience. It is fun! :-) Why didn't I think of this before? Sometimes a change is what we need to move forward. Actually, after having a model buying binge on eBay and Amazon, I found I had a lot of fun building a model-making bench in the basement. I refreshed a lot of woodworking skills I used to have and finally made use of nearly every power tool I owned (some hadn't been used for ten years, but I thought I needed them at the time). ;-) Ahh... the smell of polyurethane in the morning! Anyway, it's up and running and is the best thing I have done for simple relaxation for years. My personality does not enjoy drinking for it's own sake, or sunbathing on a beach (a stupid thing to do right now anyway), or any of the more outgoing, traditional things. I have to be doing something - and model-making does the trick. I am also learning new techniques via YouTube videos that just didn't exist when I was young. :cool:
- I would love to change the world, but they won’t give me the source code.
-
When I was about 10 years old, through until about 16, I made models. Airfix aircraft kits and Tamiya tanks. It was fun! Recently my wife suggested I had another go as it was something entirely different to programming - although it still needed attention to detail and a lot of patience. It is fun! :-) Why didn't I think of this before? Sometimes a change is what we need to move forward. Actually, after having a model buying binge on eBay and Amazon, I found I had a lot of fun building a model-making bench in the basement. I refreshed a lot of woodworking skills I used to have and finally made use of nearly every power tool I owned (some hadn't been used for ten years, but I thought I needed them at the time). ;-) Ahh... the smell of polyurethane in the morning! Anyway, it's up and running and is the best thing I have done for simple relaxation for years. My personality does not enjoy drinking for it's own sake, or sunbathing on a beach (a stupid thing to do right now anyway), or any of the more outgoing, traditional things. I have to be doing something - and model-making does the trick. I am also learning new techniques via YouTube videos that just didn't exist when I was young. :cool:
- I would love to change the world, but they won’t give me the source code.
� Forogar � wrote:
When I was about 10 years old, through until about 16, I made models. Airfix aircraft kits and Tamiya tanks. It was fun!
I was a weird kid. I didn't talk coherently until i was 5, but i was reading at 3, and making little circuits at 6. Computers (at 8) gave me the instant gratification I loved. At my core, I like building things - and taking them apart. Software gives me that. But I recently ordered an Arduino and a starter kit for it so I could revisit that childhood hobby. I might be able to make something useful my father in law has in mind for his pumphouse too. :) When I was a teen, I was kind of bike punk and I built lots of frankenstein machines on two wheels including a 10 speed BMX which was one of the coolest bikes around - like a tiny mountain bike before mountain bikes were popular. A few years ago hubby and I mounted a 2-stroke gas engine on mountain bike, and we used it as a grocery getter. It's growing weeds around it in the side yard now but i've been thinking about getting it road ready again. It was pretty fun. You sounds like we have the similar passion and love of your different pursuits - reminds me of me where we have to be engaging with our hobbies or we're just not living.
Real programmers use butterflies