NuGet is like a virus at times
-
For small, well written packages, it's fine. But the latest horror story is that I installed Quartz against my better judgement, to test it out. Quartz is a general purpose "job runner" and my first warning sign was that it was ported from Java. Rule #1: Never install any package ported from Java. The next thing I discovered is that whoever maintains Quartz decided that every single API method should be async, including initialization. Which, because I'm not calling the initialization from an awaitable method, meant I had to wrap the call in a Task(async () => initialize) call. WTF. What made this worse was that the examples I found online were all written before this atrocity, so I had no idea what I was getting into. Rule #2: Never trust online documentation, even the documentation provided by the package. Furthermore, finding anything useful about why I have to do things "the Quartz way" was completely absent. Of course, the main reason for that is because it's a Java port. Rule #3: If you can't find good examples explaining "why" in the package's online documentation, run. Ultimately, yes, it worked. Seemed to work quite well. My coworker, who was pushing to use it (he loves packages rather than rolling-your-own) liked some of the features, but neither of us could figure out how to use those features, like error reporting / handling. Rule #4: If it isn't obvious, it isn't worth it. In the back of my mind, I kept wondering why I'm adding a package to our already bloated project that consists of thousands and thousands of lines of code, for 99% of features that I won't be using and can't figure out how to use, instead of writing my own KISS CRON job processor in about 200 lines of code, and one that is tailored to what I need in terms of querying what it thinks it should be doing, error handling, testing, etc. I'll post an article, BTW. Rule #5: The KISS principle should be the first consideration when evaluating a package. Which gets me to my point. After making the command decision to ditch it, I uninstalled the package. Unbeknownst to me, the NuGet package did not cleanly revert. I should have simply rolled back the entire set of commits to the branch. Stupid me. Instead, it left breadcrumbs in a config file that included various .NET framework packages, the most scary of which included a DLL for running unsafe code. WTF does Quartz need to use unsafe code for? Anyways, while everything worked fine on our development server, without my realizing what w
-
For small, well written packages, it's fine. But the latest horror story is that I installed Quartz against my better judgement, to test it out. Quartz is a general purpose "job runner" and my first warning sign was that it was ported from Java. Rule #1: Never install any package ported from Java. The next thing I discovered is that whoever maintains Quartz decided that every single API method should be async, including initialization. Which, because I'm not calling the initialization from an awaitable method, meant I had to wrap the call in a Task(async () => initialize) call. WTF. What made this worse was that the examples I found online were all written before this atrocity, so I had no idea what I was getting into. Rule #2: Never trust online documentation, even the documentation provided by the package. Furthermore, finding anything useful about why I have to do things "the Quartz way" was completely absent. Of course, the main reason for that is because it's a Java port. Rule #3: If you can't find good examples explaining "why" in the package's online documentation, run. Ultimately, yes, it worked. Seemed to work quite well. My coworker, who was pushing to use it (he loves packages rather than rolling-your-own) liked some of the features, but neither of us could figure out how to use those features, like error reporting / handling. Rule #4: If it isn't obvious, it isn't worth it. In the back of my mind, I kept wondering why I'm adding a package to our already bloated project that consists of thousands and thousands of lines of code, for 99% of features that I won't be using and can't figure out how to use, instead of writing my own KISS CRON job processor in about 200 lines of code, and one that is tailored to what I need in terms of querying what it thinks it should be doing, error handling, testing, etc. I'll post an article, BTW. Rule #5: The KISS principle should be the first consideration when evaluating a package. Which gets me to my point. After making the command decision to ditch it, I uninstalled the package. Unbeknownst to me, the NuGet package did not cleanly revert. I should have simply rolled back the entire set of commits to the branch. Stupid me. Instead, it left breadcrumbs in a config file that included various .NET framework packages, the most scary of which included a DLL for running unsafe code. WTF does Quartz need to use unsafe code for? Anyways, while everything worked fine on our development server, without my realizing what w
Now you get it! :-\
-
For small, well written packages, it's fine. But the latest horror story is that I installed Quartz against my better judgement, to test it out. Quartz is a general purpose "job runner" and my first warning sign was that it was ported from Java. Rule #1: Never install any package ported from Java. The next thing I discovered is that whoever maintains Quartz decided that every single API method should be async, including initialization. Which, because I'm not calling the initialization from an awaitable method, meant I had to wrap the call in a Task(async () => initialize) call. WTF. What made this worse was that the examples I found online were all written before this atrocity, so I had no idea what I was getting into. Rule #2: Never trust online documentation, even the documentation provided by the package. Furthermore, finding anything useful about why I have to do things "the Quartz way" was completely absent. Of course, the main reason for that is because it's a Java port. Rule #3: If you can't find good examples explaining "why" in the package's online documentation, run. Ultimately, yes, it worked. Seemed to work quite well. My coworker, who was pushing to use it (he loves packages rather than rolling-your-own) liked some of the features, but neither of us could figure out how to use those features, like error reporting / handling. Rule #4: If it isn't obvious, it isn't worth it. In the back of my mind, I kept wondering why I'm adding a package to our already bloated project that consists of thousands and thousands of lines of code, for 99% of features that I won't be using and can't figure out how to use, instead of writing my own KISS CRON job processor in about 200 lines of code, and one that is tailored to what I need in terms of querying what it thinks it should be doing, error handling, testing, etc. I'll post an article, BTW. Rule #5: The KISS principle should be the first consideration when evaluating a package. Which gets me to my point. After making the command decision to ditch it, I uninstalled the package. Unbeknownst to me, the NuGet package did not cleanly revert. I should have simply rolled back the entire set of commits to the branch. Stupid me. Instead, it left breadcrumbs in a config file that included various .NET framework packages, the most scary of which included a DLL for running unsafe code. WTF does Quartz need to use unsafe code for? Anyways, while everything worked fine on our development server, without my realizing what w
Hangfire is an alternative you might want to look at.
-
Hangfire is an alternative you might want to look at.
And as a bonus: it's available as a NuGet package! It needs a database to work however ... net-tools~hangfire[^]
-
And as a bonus: it's available as a NuGet package! It needs a database to work however ... net-tools~hangfire[^]
It has lots of storage options, wouldn't surprise me if there's a file-based one or you could just use the memory based one if you weren't too bothered about persistence.
-
For small, well written packages, it's fine. But the latest horror story is that I installed Quartz against my better judgement, to test it out. Quartz is a general purpose "job runner" and my first warning sign was that it was ported from Java. Rule #1: Never install any package ported from Java. The next thing I discovered is that whoever maintains Quartz decided that every single API method should be async, including initialization. Which, because I'm not calling the initialization from an awaitable method, meant I had to wrap the call in a Task(async () => initialize) call. WTF. What made this worse was that the examples I found online were all written before this atrocity, so I had no idea what I was getting into. Rule #2: Never trust online documentation, even the documentation provided by the package. Furthermore, finding anything useful about why I have to do things "the Quartz way" was completely absent. Of course, the main reason for that is because it's a Java port. Rule #3: If you can't find good examples explaining "why" in the package's online documentation, run. Ultimately, yes, it worked. Seemed to work quite well. My coworker, who was pushing to use it (he loves packages rather than rolling-your-own) liked some of the features, but neither of us could figure out how to use those features, like error reporting / handling. Rule #4: If it isn't obvious, it isn't worth it. In the back of my mind, I kept wondering why I'm adding a package to our already bloated project that consists of thousands and thousands of lines of code, for 99% of features that I won't be using and can't figure out how to use, instead of writing my own KISS CRON job processor in about 200 lines of code, and one that is tailored to what I need in terms of querying what it thinks it should be doing, error handling, testing, etc. I'll post an article, BTW. Rule #5: The KISS principle should be the first consideration when evaluating a package. Which gets me to my point. After making the command decision to ditch it, I uninstalled the package. Unbeknownst to me, the NuGet package did not cleanly revert. I should have simply rolled back the entire set of commits to the branch. Stupid me. Instead, it left breadcrumbs in a config file that included various .NET framework packages, the most scary of which included a DLL for running unsafe code. WTF does Quartz need to use unsafe code for? Anyways, while everything worked fine on our development server, without my realizing what w
Marc Clifton wrote:
various .NET framework packages, the most scary of which included a DLL for running unsafe code
Guess: Performance. I notice to my surprise that an open source .NET library I have used for certain jobs relies on unsafe code. Why? Performance on potentially large amounts of data. The author is a .NET expert. I am certain he wouldn't have done it unless it was critical. I was disappointed.