-CopyModReferencesToBuildOutput |
+BundleExtraAssemblies |
-Whether to copy game and framework DLLs into the mod folder (default `false`). This is useful for
-unit test projects, but not needed for mods that'll be run through SMAPI.
+**Most mods should not change this option.**
+
+By default (when this is _not_ enabled), only the mod files [normally considered part of the
+mod](#Features) will be added to the release `.zip` and copied into the `Mods` folder (i.e.
+"deployed"). That includes the assembly files (`*.dll`, `*.pdb`, and `*.xml`) for your mod project,
+but any other DLLs won't be deployed.
+
+Enabling this option will add _all_ dependencies to the build output, then deploy _some_ of them
+depending on the comma-separated value(s) you set:
+
+
+
+ option |
+ result |
+
+
+ThirdParty |
+
+
+Assembly files which don't match any other category.
+
+ |
+
+
+System |
+
+
+Assembly files whose names start with `Microsoft.*` or `System.*`.
+
+ |
+
+
+Game |
+
+
+Assembly files which are part of MonoGame, SMAPI, or Stardew Valley.
+
+ |
+
+
+All |
+
+
+Equivalent to `System, Game, ThirdParty`.
+
+ |
+
+
+
+Most mods should omit the option. Some mods may need `ThirdParty` if they bundle third-party DLLs
+with their mod. The other options are mainly useful for unit tests.
+
+When enabling this option, you should **manually review which files get deployed** and use the
+`IgnoreModFilePaths` or `IgnoreModFilePatterns` options to exclude files as needed.
|
@@ -213,6 +256,20 @@ Whether to configure the project so you can launch or debug the game through the
Visual Studio (default `true`). There's usually no reason to change this, unless it's a unit test
project.
+
+
+