Standalone Mason produces this result when it is ran. Bugged in every version since 1.0.0.

error at .(0,0): [S0] An unhandled exception occured: System.IO.FileNotFoundException: Could not load file or assembly 'CommandLine, Version=2.8.0.0, Culture=neutral, PublicKeyToken=5a870481e358d379'. The system cannot find the file specified.

File name: 'CommandLine, Version=2.8.0.0, Culture=neutral, PublicKeyToken=5a870481e358d379'
   at Mason.Standalone.Program.MainSafe(String[] args)
   at Mason.Standalone.Program.Main(String[] args) in /home/runner/work/Mason/Mason/Mason/Program.cs:line 24

Config and project files barely use and file size and may benefit new users trying to learn Mason by pre-existing mods, or users that wish to modify the mod. For these reasons, the files should be included in the package zip generated by the pack verb.

Currently, plugins whose loaders are used can be omitted from dependencies. This may cause an error while running assets, as the plugin's presence is not checked prior to loading.

To prevent failure, plugins used within assets should require that a hard dependency exists for that plugin. If it does not exist, it should produce an error.

Projects that have been disabled via r2modman, i.e. contain a bootstrap.dll.old file, are rebuilt. BepInEx loads the rebuilt DLL, effectively causing the mod to stay enabled.

Assembly references of the bootstrap DLL should be specifiable through the project file, through a syntax such as

assemblies:
  - FileInSameFolder.dll
  - some/subfolders/OtherCode.dll

This would allow people to bundle custom code used by items, as BepInEx would not otherwise load them because they do not have a BepInEx plugin in them.

Platform:

Windows 10 Pro build 19042 x64
Mason 1.0.4

Summary:

When running mason pack, the manifest.json placed in mod.zip is empty and does not have the contents of the manifest.json inside the project folder.
Expected behavior: The manifest.json inside the mod.zip should match the manifest.json inside the project folder.

Steps to reproduce:

1. Set up project folder as in image.
   
2. Insert contents of manifest.json, like so:

  "name": "BB_ModulAR18",
  "version_number": "1.0.0",
  "website_url": "",
  "description": "Adds an AR-18.",
  "dependencies": [
    "WFIOST-H3VRUtilities-8.0.3"
  ]
}

3. Set up config.yaml thusly, according to the documentation:

directories:
  bepinex: C:\Users\<USERNAME>\AppData\Roaming\r2modmanPlus-local\H3VR\profiles\testing_modul\BepInEx
  managed: C:\Program Files (x86)\Steam\steamapps\common\H3VR\h3vr_Data\Managed
...

4. Set up project.yaml like so (yes, I'm aware my dependencies aren't set up right but it runs and it shouldn't impact this bug):

version: 1
dependencies:
  hard:
    h3vr.otherloader: 1.0.0
assets:
  runtime:
    nested:
    - assets:
      - path: any_modular18-core
        plugin: h3vr.otherloader
        loader: item_unordered
    
...

5. Add icon.png, README.md, and the virtualobject in resources like normal.
6. Open command line at project root, and run mason pack, which provides this output:

PS D:\unitymodding\STAGING\noghiri-BB_ModulAR18> mason pack
Parsed commandline arguments
Parsed config
Constructed compiler
warning at manifest.json(0,0): [C10] The author of the mod was infered by the directory name. Consider adding an 'author' property.
Compiled noghiri-BB_ModulAR18-1.0.0 with 1 warnings
Creating package
Added bootstrap DLL
Added minified manifest
Added Thunderstore-required files
Added resources
Created package
Acquired output file
Wrote content to disk

7. Open resulting mod.zip in 7zip, and open the manifest.json to read the version in the zip file:
   

Notably, the README.md is perfectly fine, it's been added correctly to the zip file. It's not a big deal to simply work around, but really doesn't conform to the behavior I'd expect from the standalone compiler.

Standalone Mason should have a subcommand that creates a new project, much like the quickstart repository.

Currently, Git versioning with Thunderstore manifest still causes some redundancy. Version tags in Git do not correspond with the package version, even though this is often the case. The standalone version of Mason should infer versions from Git, with a config to opt out. The version manifest property should not be required when using standalone, but it should still error on patcher.

A possible way to do this is to get all tags for HEAD, filter them into the SemVer-like format used by Thunderstore, then pull the highest version. This should be fed into the compiler. A config entry should be added to specify the prefix that tags use, like how MinVer does it.
It is unknown what should be done about untagged builds. The feature should still work, but the resultant version should not be the same as any tagged build. One solution may be to zero out all components and reserve that version for unreleased builds.