Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 13 07:46
    bbrewder closed #12
  • Jul 13 07:46
    bbrewder commented #12
  • Jul 13 01:25
    jazmatician commented #12
  • Jul 13 01:13
    bbrewder commented #12
  • Jun 04 02:43
    jazmatician closed #11
  • Jun 04 02:43
    jazmatician commented #11
  • Jun 04 02:43
    jazmatician opened #12
  • Jun 04 02:38
    jazmatician opened #11
  • May 23 16:18
    jazmatician commented #9
  • May 22 01:52

    bbrewder on master

    Reduced the lines of code in Co… Merge pull request #1 from sidm… Merge pull request #10 from sid… and 1 more (compare)

  • May 22 01:49

    bbrewder on develop

    Reduced the lines of code in Co… Merge pull request #1 from sidm… Merge pull request #10 from sid… (compare)

  • May 22 01:49
    bbrewder closed #10
  • May 22 00:55
    bbrewder commented #9
  • May 22 00:55
    bbrewder closed #9
  • Apr 27 04:11
    sidm1983 opened #10
  • Feb 20 23:20
    jazmatician opened #9
  • Dec 19 2018 03:42
    bbrewder closed #8
  • Dec 19 2018 03:42
    bbrewder commented #8
  • Dec 19 2018 03:18

    bbrewder on master

    Updated release notes. (compare)

  • Dec 19 2018 03:08

    bbrewder on master

    Fixed issue with null options. Added unit test for null option… (compare)

Brian Brewder
@bbrewder
I'm thinking of delaying releasing BizArk 3 until we update it to .Net Platform Standard 1.0 (.Net Core). This will allow developers to use BizArk in new .Net core applications, such as ASP.Net core, which allows support for multiple operating systems. I want to delay in case updating it causes breaking changes in BizArk. Any thoughts on this?
Brian Brewder
@bbrewder
What about creating a services framework for BizArk? I've been working on one for work and realized that there really isn't anything decent out there (at least not that I've found). The services framework would provide tooling for installation, scheduling, configuration, logging, and monitoring of services. I know that my company has dozens of services spread out over many machines throughout the organization. Up until recently, they each handled these tasks independently and monitoring was not practical (since they all handled logging differently). The framework I've been building at work seems to be very effective for us, but it is very specific to our company. I've got some ideas that I think will make this work in most businesses that require back-end services to do essential business tasks. As a note, this framework will not be handling any kind of message queuing or anything like that. There are plenty of tools available for that kind of stuff.
Boris Modylevsky
@borismod
@bbrewder in general, I believe it's a great idea to make BizArk cross-platform by compiling it against .NET core. I don't have any experience with it. I've read a few blog posts on this topic and I am not sure .NET Core is mature enough and won't present any breaking changes in the future. So it's up to you when to make this transition. Here is a detailed post by Hadi Hariri: http://hadihariri.com/2016/05/27/rc-means-something/
Boris Modylevsky
@borismod
Regarding building services framework - it's an interesting idea. I would double check whether something similar exist on the web before developing something similar. I am sure you already did it.
Brian Brewder
@bbrewder
Unfortunately we won't be able to support .Net Standard in BizArk3. However, I have created a new project called BizArkStd (also under BizArk) that supports the standard. Currently I've only ported BizArk.Core to .Net standard 1.6. I'm planning on porting BaCon to .Net Standard next. We have lost some functionality, which is one of the reasons why it is a separate project. I'll document the lost functionality in the GitHub readme file once I am able to port BaCon.
Brian Brewder
@bbrewder
I was able to get BaCon into GitHub with no real compromises. In fact, I think the biggest compromise for moving BizArk to .Net standard was that BaObject no longer supports being a dynamic object (the required interface isn't available). This should be resolved in .Net Standard 2.0.
I don't have easy access to Linux or Mac. If somebody could run the unit tests and sample app on those to make sure they work, I would appreciate it.
Brian Brewder
@bbrewder
BizArk3 is about ready for release. The big question remaining is whether it should be a new package on NuGet or simply a new version for the existing package (https://www.nuget.org/packages/BizArk.Core/). Both have pros/cons. If we create a new package, people with the old package might not know about it and it might be confusing which one to use. On the other hand, this is such a major update that getting the latest version in an existing project will definitely break it. Opinions?
Boris Modylevsky
@borismod
Is BizArk 3 presents breaking changes? If so it can be released as the same package with increasing the major version number, i.e. 3.0.0.
Brian Brewder
@bbrewder
Yeah, I realize that, but the changes are probably more substantial than even a typical version upgrade. But I am thinking I'll just do that in order to keep things simpler long term. Hopefully people have a backup of their code before trying to upgrade.
Boris Modylevsky
@borismod
I assume there is a large customer base of users that consume BizArk 2.x I assume we should maintain a living copy of source code of that version. My suggestion in that case would be migrating Bizark from CodePlex to github and publishing it in the same repo under relases/2.0 branch. What do you think?
Brian Brewder
@bbrewder
That's the plan. Basically it will be under BizArk\BizArk2 (vs BizArk3 for the latest release). I'm planning on working on this tonight.
Brian Brewder
@bbrewder
They had some decent tools that made it super easy. Just need to migrate the documentation now.
Brian Brewder
@bbrewder
Documentation is migrated now. It's not great (some of the links are broken), but hopefully it's good enough.
Brian Brewder
@bbrewder

I have figured out a way to extend the BaCon command-line parser to support creating a CLI tool using a simple command pattern and have started coding a solution.

This update might include some breaking changes to BizArk 3. Hopefully breaking changes will only effect those that have deep integration (I might have to change the way arguments are parsed internally). Anybody following the sample code should be fine.

CLI integration will have the following features:

  1. Support for a complex, multi-level command hierarchy.
  2. Help will (can?) include a "graphical" representation of the command hierarchy.
  3. Each command will have it's own help displayed.
  4. Each command will essentially be it's own console app (inherits from BaseConsoleApp). The hierarchy is defined by inheritance.
  5. Command-line parsing will support all of the same features as the basic BizArk command-line parser, except default arguments will not be supported (they are used to identify the commands).

Please let me know if you have any ideas to make this work well.