FreedomFaighter
commented
1 year ago With the updated project examples and their corresponding csproj files, differences and references of how to structure a project such as relative paths to the ACT application for references and launch during debugging can be looked at. One of the issue I ran into was constant copying of dll files on the disk after a code change and build. Addressing each projects needs so they can be built and tested individually is another example of how to as plugin.
Combined with a GitHub actions script the changes committed are able to be compiled outside a developer's local system to confirm error free compilation which normally requires a more extensive command given to the yml file if these are just 'loose files'
As for directly loading a C# source file into ACT that can still be done, however, when writing a new plugin for development and automated release msbuild action in the yml file will normally look for a solution or project file during a Release and testing
I guess I don't understand why you're putting in this extra effort for the standalone plugins. Most of these *.cs files are not meant to be put into a project and worked on. They're also not meant to be pre-compiled, so they don't need a project?
Primarily they are here as examples and hints for others to develop their own plugins. Putting them in sub-folders makes it harder to browse through them. Pre-compiling them defeats the purpose of their distribution method: which is for ACT to load the .cs file directly, instead of using a pre-compiled .dll.
I sort of feel like these files are like GISTs or references for documentation instead of something more substantial, like you're treating them.