# Deploying modules

## Deploying modules

When a module is fully developed, it needs to be published to the store, so that it can be used. To do this, it is built in **release mode** and uploaded to the store using FTP or the **plugin-manager** in the backend. If the latter is chosen, the module must be packaged in a format that Smartstore can recognize and process. This functionality is provided by the **Smartstore Packager**.

### Versioning

`module.json` provides properties for *versioning*. The `Version` property defines the version of the module and `MinAppVersion` specifies the lowest supported Smartstore version that can run the module.

By convention, that the version number should always reflect the current Smartstore version, for which the module was built. If a hotfix has been applied to the module, the revision part of the version number is incremented.

Let's say the release version of a module is `5.0.1`. A hotfix would make the version `5.0.1.1`, and the next revision would be `5.0.1.2`, and so on.

### Build the Module in release mode

Modules that are to be deployed, must be built in **release mode**. If only a single module is to be built, set the Visual Studio solution configuration to `Release` and select `Build` from the module's context menu. The module will be built and placed in the path defined by the `OutputPath` in the project file.

Alternatively, you can run the file that builds the entire solution in **release mode**. Depending on the target platform, one of the following batch files can be used.

* `build/build.linux-x64.cmd`
* `build/build.osx-x64`
* `build/build.win-x64.cmd`
* `build/build.win-x86.cmd`

If you are just building a module, the version of the batch file is irrelevant because modules are built platform-independently.

{% hint style="info" %}
For more information about deployment in general, see [Deployment & Build](/readme/deployment-and-build.md).
{% endhint %}

After successful execution, the compiled application can be found in *build/Artifacts*. The *Modules* directory contains all modules that were compiled in **release mode**.

### Deployment via FTP or RDP

If access is granted via FTP or RDP, the modules can simply be uploaded to the *Modules* directory. After restarting the application, modules can be installed using the **plugin-manager** (admin > configuration > plugins). If the modules are already installed, the application must be restarted to load the current modules.

{% hint style="info" %}
Because the modules are loaded by the running application, the page's app pool must be stopped before the files are uploaded.
{% endhint %}

### Packager

If a module is to be distributed to a third party, the module should be provided in a format that allows the third party to install it in their store independently.

This can be done using the **Smartstore Packager**. To use it, open the `Smartstore.Tools.sln` solution located in the Smartstore repository root. Build the `Smartstore.Packager` project from the *Tools* directory. The resulting `Smartstore.Packager.exe` file can list all modules of a build directory. After starting the packager, select the directory in *Artifacts*, created by the batch file. Clicking on **ReadExtensions** will list all available modules. Now select the module you want to package, an output directory and press **Create Package**.

The packager creates a zip file using the naming pattern `Smartstore.Module.{module systemname}.{current module version}.zip` which will result in something like `Smartstore.Module.MyOrg.MyModule.5.0.zip`.

This packaged module can now be uploaded by any store owner. There is no need to stop the app pool, when using this method and Smartstore will automatically restart the application.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://dev.smartstore.com/compose/modules/deploying-modules.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.