The assembly name should be the name of the module (eg. TimedSequenceEditor), and the default namespace should be “VixenModules..”. For example, VixenModules.Editor.TimedSequenceEditor.
The build output directory should be relative to the solution directory, in an ‘Release’ directory for x86 release builds, and a ‘Release64’ directory for x64 release builds. The Debug output folders follow the same pattern It will also depend on the type of module. For example:
Vixen Modules (Release): $(SolutionDir)\Release\Modules<ModuleType>
Vixen Modules (Release64): $(SolutionDir)\Release64\Modules<ModuleType>
Vixen Common assemblies (Release): $(SolutionDir)\Release\Common
Vixen Common assemblies (Release64): $(SolutionDir)\Release64\Common
Vixen Applications (Release): $(SolutionDir)\Release
Vixen Applications (Release64): $(SolutionDir)\Release64\
Note: the $(SolutionDir) text will need to be edited in the .csproj file directly as VS escapes the ‘$()’ macros. The csproj files follow the current SDK style format.
If you’re unsure, look at another existing project, and copy the OutputPath for both Release and Release64, eg.:
To reference the Vixen project (or any other projects that are needed), make sure you add a ‘project reference’, and not a “normal” reference (to the binary DLL). This will help compatibility for other developers when used in different locations. References to projects should be set so they do not copy local. This avoids assembly loader issues with multiple copies. Under Properties of the reference.
- Copy Local : No
- Include Assets: None
Tabs vs. Spaces, and other formatting: Tabs are preferred, and general formatting standards are followed. However, please try to review all your own changes before committing, to ensure you are not making large changes to unrelated sections of code (eg. changing formatting in a file, or whitespace, etc.). Commits like this may be rejected. If larger reformats are desired, include them in their own commits noted as such to distingush them from logic changes.