Different ways to get the Version Number of a Mendix MPR Project File

Mendix Logo evolution: 2013–2023

You have downloaded a ZIP with a Mendix MPR project from the WEB, or just opened a folder with an ancient project and you don’t remember the Studio Pro version such project was saved. Obviously, you can just use the most recent version of Studio Pro and open the file. However, this may incur a version migration which is not what you want. You need to open the MPR file with the correct version of Studio Pro. How can you discover beforehand the Studio Pro version used?

Naive Approach

Besides the obvious solution which would be simply to try to open the project with the latest Studio Pro version and convert/update the file to be able to open it, there’s an alternative solution.

Our first attempt would be opening the file project-settings.user.json using your favorite TXT editor. In this JSON, look for the key settingsParts/type and you will see the information with the version, as shown below:

The Mendix version number in the “type” key

This is a bad solution since this file project-settings.user.json is only sometimes available. For example, if you download the project from a GIT repository, you won’t find this file, because it’s usually listed in the .gitignore file.

The same is true for the *.launch file. The Mendix version number is found in many tags:

The Mendix version number in the *.launch file

If your project happens to have a deployment folder (i.e: it was run at least once), you can try to open the file build_core.xml (or variables.gradle) and look for the version number used as the path name of various tasks of this buildfile.

The Mendix version number in the buildfile file

Another attempt could be to see the information from the file base_ver in the .mendix_cache folder:

The Mendix version number in the base_ver file

All these “solutions” are naive, because:

• The files could not be available
• The version informed in the file could not be in sync with the MPR file.

So, let’s try other options.

Tools approach

Mendix provides us with some useful tools for different purposes. One of these tools is mx.exe, located in the modeler folder of your Studio Pro installation. See the docs at mx Command-Line Tool for details. For our case, run the command:

mx Command used to get the MPR version number

PS D:\apps\Mendix\9.24.12.20495\modeler> .\mx.exe show-version H:\work\truechange\mendix\PurchaseOrderSAP-main\PurchaseOrderSAP.mpr
9.18.0.53394
PS D:\apps\Mendix\9.24.12.20495\modeler>

The mx show-version command reports which version of Studio Pro was used last time the app was opened.

Another tool is MprTool.exe also located in the same folder. This is a visual tool. You should open the MPR file in which the version is unsure and select the menu option Tools/EditMetadata:

Mpr tool showing the MPR version number

I prefer to use the mx.exe tool, because it is very light and can be used in a CI/CD environment, and it’s also available in Linux!

DB approach

The DB approach is based on the fact that the MPR file is indeed a database file. This knowledge is very useful in our case since we can use an SQL query to obtain the Studio Pro version of the MPR project saved.

Install Winget if needed. After this, run the command below to install the SQLite tool, required to run SQL queries in our MPR file:

The command to install SQLite

winget install -e --id SQLite.SQLite

At this point, we can run a query to get the Studio Pro version used to generate the MPR file:

sqlite3.exe .\PurchaseOrderSAP.mpr "select _ProductVersion from _MetaData"

Using SQLite to get the MPR version number

We can also use a UI tool like SQLiteStudio or DBeaver to get the same result:

DBeaver showing the MPR version number

Conclusion

You may ask: wow, why did someone go to the trouble of writing an article just to find out the version number of the MPR project file, is it that serious? Yes, I have already witnessed a case where a team member inadvertently opened a project saved with a Studio Pro LTS, but using the most recent Studio Pro available and committed the project with the changes that would be related to its story. This had repercussions on other devs and also on the development environment. The solution was to revert to the last version committed in the correct version, but this caused unnecessary inconvenience and the developer had to redo the story.

OK, in this case, the problem was not necessarily related to a lack of knowledge of the MPR version, but rather a communication failure between team members, but it illustrates the importance of knowing the MPR version number since it is not possible to make an MPR version downgrade.