Programmatically retrieving installed InDesign software Build number

[Kasun_Bamu]

Hi all,
I'm trying to retrieve InDesign build number in both Windows and Mac environments. I'm using InDesign SDK version 18.
Since I'm doing this in both Mac and Windows environments, is there a method to retrieve the installed InDesign software build number from SDK? (I would prefer SDK method if such available)
For windows; Does registry includes the build numbers and if yes, where?
Or is there any other alternatives apart from SDK or registry, to retrieve the InDesign build number?

Can someone kindly give me a guidance

[Dirk Becker · Accepted solution]

For the dynamic value in the running application, there are plenty related methods in IApplication, such as IApplication::GetBuildNumber() .

See BuildNumber.h if you mean at compile time – that would be the build number of the SDK

[Kasun_Bamu]

Hi @Dirk Becker ,

Really appriciate your quick response. I tried this out;  IApplication::GetBuildNumber(). It gives the build number of  the "plugin that I developed using SDK". What I need to access is, Adobe Indesign software (InDesign.exe) build number.
Again thanks for the support. Noted this for the future reference.

[Rahul_Rastogi]

@Dirk Becker already pointed out in the right direction - IApplication has several methods for getting the version number of the InDesign Application.

As per you, it is giving you the build number of the plugin that you developed. - This seems to be wrong or you have made changes with InDesign SDK file itself or overriding the default indesign standard macro #define.

Or you are looking for InDesign.exe File Version Number ? - 

If you are looking for InDesign.exe file version number then you can google on the APIs and code would be different for both Mac and Windows

[Dirk Becker]

The build number should be irrelevant in most regards.

Two exceptions:

Via the version string macro it ends up in the plugin description (following major, minor and dot version), thus also in the document log (extended about dialog).

The build number is also used to detect debug builds, so that the release build does not accidentally load such a plugin. Kasun may be trying to load a debug plugin unaware that he needs an entirely different InDesign for that.

Another possibility: Kasun might not be aware that there are multiple 18.x SDKs (which provides build number constant that ends up in the plugin). Also noteworthy that the 18.0 build number is higher (plenty builds pre release) than the later 18.1 etc build numbers (build number counter is reset even for minor versions). There is even the possibility that two different minor versions end up at the same build number ...

Otherwise, when the plugin's build number matches that of IApplication, that should be expected because application and SDK should have the same build number. There would only be a difference if the plugin is built with an older SDK – the application would prevent loading of a too new version in the first place.

[Kasun_Bamu]

Hi @Dirk Becker,

InterfacePtr<IApplication> appID(GetExecutionContextSession()->QueryApplication());
if (appID == nil) {
    ASSERT_FAIL("nil");
}
IDBuild.AsNumber(appID->GetBuildNumber());

Really sorry for the confusion. Plugin I was testing and the InDesign had the same build number by coincedent. After testing with other ID versions with coworkers, I realized that there was no issue in the approach you suggested. Above is my implementation

Thanks for the support and valuable ideas @Dirk Becker and @Rahul_Rastogi

[Olivier Beltrami]

@Kasun_Bamu 

I use the attached code with SDKs 15-16-17-18-19, which gives the following.

InDesign.exe release version 18.4.0.56

And hich matches the Windows Explorer info (see below).

Very best regards,

Olivier