Current plugin examples are all in a single directory with no CI or CD script

[FreedomFaighter]

To keep current plugins with their pull requests able to build a github workflows script with a .NET Environment and msbuild action can be implemented and a solution and project structure implemented for each plugin

[FreedomFaighter]

Each plugin can be moved to it's own feature branch and given a build script to check that it is buildable on the GitHub actions

[FreedomFaighter]

The plugin sample may be best remaining the master branch

[FreedomFaighter]

The plugins can have a feature branch for each plugin, I have created feature branches for each in my personal repository and can open pull requests for each if this is accepted

[EQAditu]

I thought I had responded to this, but clearly I had not. I'll try to remember all of the points that I meant to write previously. (I think I had a power outage or something stupid)

The main purpose of the given plugins are to act as code examples. Sometimes people use gists for this, but those are harder to find and I wanted them to be easy to find. Putting them in project folders complicates browsing these files and putting them inside of other branches makes that worse. I thought about static wiki pages as well, but this is far superior for browsing code.

They are not really meant to be worked on by anyone but myself... and some of the examples are so basic that they serve no real purpose but to be examples.

These files are not meant to be pre-compiled. They are meant to remain as *.cs files that are given to ACT directly. ACT uses a Microsoft compilation API that unfortunately is not as good as msbuild or rosyln, etc. I want these files to remain usable by ACT directly and having GitHub try to compile them misses this purpose. ACT will only be able to use a sub-set of what other compilers think is working.

The bottom line is I believe this misses my intended purpose of these files and makes them harder to get to.

[FreedomFaighter]

I understand but in their current context I would have to use them a certain way when the other methods such as a compiled dll do not have full instructions. What I had mentioned was placing these all into feature branches that describe the delta information between each example, currently with git mv command you are essentially giving some sort of information of a rename. with the delta information a new developer whom may not have the ability to contact you can see how to get from one change to the others which is essentially the whole purpose of the git application

Placing these into projects within feature branches would allow for both approaches a source file dropped in and a method for compilation from a project

[FreedomFaighter]

example of commit history