• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Migrating Plugin from InDesign 15 to 16

Engaged ,
Oct 25, 2020 Oct 25, 2020

Copy link to clipboard

Copied

Hi,

We have developped an InDesign plugin using the plugin_sdk_15.0.0.155 for InDesign 15 (2020), using Visual Studio 2017.

This morning I installed InDesign 16 (2021) and the plugin_sdk_16.0.0.077. I was able to recompile our PLN, but I am unable to find the latest idrc files to place in my (* resources) folder, along with my PLN. Where can I find these latest files (the ones I have are from last June and are probably valid only for InDesign 15).

Very best regards,

Olivier

 

TOPICS
SDK

Views

413

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Community Expert , Oct 25, 2020 Oct 25, 2020

You should create two configurations in your project, one for debug and another for release. You shall see a dropdown in VS toolbar to switch between the two. If you don't have access to InDesign's Debug build, you will need to compile the release configuration of your plugin. The main difference in the project setting of a release and debug configuration are as follows.

  • You need to link with the debug versions of the lib.
  • You need to pass the NDEBUG flag in the PreprocessorDefinitions to the C
...

Votes

Translate

Translate
Community Expert ,
Oct 25, 2020 Oct 25, 2020

Copy link to clipboard

Copied

Hi @Olivier Beltrami ,

idrc files are generated when your fr file is compiled. See if your fr is set to compile or not, also look for the merge_res command configuration. This should fix your issue i hope

-Manan

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Oct 25, 2020 Oct 25, 2020

Copy link to clipboard

Copied

Hi Manan,

 

Thank you very much for your prompt response.

The configuration of my .fr file had it to be excluded from the build.

But if I try to change that setting, what ITEM TYPE should I use ?

I tried a few of the ones that had resource in the name, but all failed.

What ITEM TYPE should I use in the .fr file info page ?

 

Very best regards,

 

Olivier

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Oct 25, 2020 Oct 25, 2020

Copy link to clipboard

Copied

Oliver, first of all, do note that not all the project .fr files are to be compiled. The basic setup is that there is a master fr file that includes all the other fr files and only this master fr file needs to be compiled. If more than one fr file is set for compilation then you will get errors.

Regarding how to set up the compilation of the master fr file? The easiest way for this would be to open up a sample SDK project, right click on the fr file included in the project, and see the command in the custom build step. Another option is to edit the project file using a text editor. This is a bit involved, I am pasting the relevant section of an SDK sample below. See the settings made for both the configuration, you will have to make corresponding thing for your fr file.

  <ItemGroup>
    <CustomBuild Include="..\..\..\source\sdksamples\basicdialog\BscDlg.fr">
      <Command Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">odfrc $(ODFRC_ADDITIONAL_FLAGS) "%(FullPath)" -o "$(IntDir)%(Filename).fres" -d DEBUG  -i ..\..\..\source\sdksamples\basicdialog @SDKODFRCOptions.rsp
</Command>
      <AdditionalInputs Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">$(IntDir)TriggerResourceDeps.obj;%(AdditionalInputs)</AdditionalInputs>
      <Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">$(IntDir)%(Filename).fres;%(Outputs)</Outputs>
      <Command Condition="'$(Configuration)|$(Platform)'=='Release|x64'">odfrc $(ODFRC_ADDITIONAL_FLAGS) "%(FullPath)" -o "$(IntDir)%(Filename).fres"   -i ..\..\..\source\sdksamples\basicdialog   @SDKODFRCOptions.rsp
</Command>
      <AdditionalInputs Condition="'$(Configuration)|$(Platform)'=='Release|x64'">$(IntDir)TriggerResourceDeps.obj;%(AdditionalInputs)</AdditionalInputs>
      <Outputs Condition="'$(Configuration)|$(Platform)'=='Release|x64'">$(IntDir)%(Filename).fres;%(Outputs)</Outputs>
    </CustomBuild>
  </ItemGroup>

I would suggest you make the setting using VS interface as editing the project file manually can cause file corruption if you are not experienced with it.

-Manan

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guide ,
Oct 25, 2020 Oct 25, 2020

Copy link to clipboard

Copied

Manan, even with experience you can corrupt such a file … 😉

 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Oct 25, 2020 Oct 25, 2020

Copy link to clipboard

Copied

Dirk, yes, that happens quite a lot. But what experience has taught me is patience and the stomach to revert and try again. Editing the project file is the go-to solution for me in most cases. Clicking through numerous screens and making the same changes repeatedly is such a pain as against copying and pasting the stuff. With that said, I don't dare to edit the project files of XCode, never tried that, they look so scary that I remain with the IDE. What are your experiences?

-Manan

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guide ,
Oct 26, 2020 Oct 26, 2020

Copy link to clipboard

Copied

LATEST

I automate all related tasks using node.js - similar to your manual edits. When I start with a new SDK, I apply a ton of proven edits to example SDK projects - e.g. to make them relocatable but still refer into SDK sources. Edit the response or xcconfig files to remove dead header search paths, flatten recursive paths (big speed up of compile time), and add others that I found missing in stock rsp. / .xcconfig . Move stray "-d something" from commandline into appropriate .rsp or .props . And so forth.

Rename version specific files to version specific names - my largest Xcode project builds 20 plug-ins across versions CS5 thru current, other projects have fewer but still multiple plug-ins. Adobe apparently never works cross version so they need not care about such details.

Since I started at a time when you could still have independent .fr files rather than that single "umbrella" file where you collide with preprocessor macros, my build process also continues to support that approach. "merge_res" has its name for a reason … . 

A recent project is a node.js program that has a full object model for both Xcode and VStudio projects, so that I can access and modify all features programmatically. There I'm right now adding a converter from Xcode project/target into the equivalent .sln/.vcxproj.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Oct 25, 2020 Oct 25, 2020

Copy link to clipboard

Copied

Hi Manan,

Your suggestion of opening up and imitating an existing SDK sample project has llowed me to compile the .fr file and generate the .idrc files. Thnak you very much for your help.

However, when launching ID16, I still get the message "Adobe InDesign does not recognize MyPlugin as a valid plug-in." which I thought was due to v.15 idrc files.

Is there an additional step needed to get my plugin to work under ID16, if it runs fine under ID15 ? I did install the v16 SDK. Do I need to get a special developer id for ID16 ? ID15 was the first plugin we ever worked on, so I'm not really cler on what happens when migrating to a new version.

Very best regards,

Olivier

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Oct 25, 2020 Oct 25, 2020

Copy link to clipboard

Copied

I would check if the merge_res and restore_res command lines are properly configured. Check the PrelinkEvent and PostBuildEvent configuration of the SDK sample plugin for reference. Another thing I would do is rename the 15 SDK on the computer to make sure nothing from that folder is being referenced.

-Manan

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Oct 25, 2020 Oct 25, 2020

Copy link to clipboard

Copied

Hi Manan,

Thank you very much for your help.

I now get the following, slightly different message: "The plug-in requires the debug version of InDesign.". I did read your response to an earlier post (First-time InDesign Plugin Developer - Some basic questions), and I have duly applied to join the Developer Pre-Release Program.

However, I still need to be able to ship my PLN to users who only have the normal version of InDesign. Under ID15, my release version contained a PLN and a PDB and that worked fine with the normal version of ID15. Your other post mentions "can always debug his code using the release version of InDesign (the version that is released for all to use). You just need to build your plugins with debug symbols generated", which seems to be the setup I have under ID15. So what is the difference with ID16 (yes, I did rename all my v15 folders to ensure no cross-folder effects) ?

Very best regards,

Olivier

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Oct 25, 2020 Oct 25, 2020

Copy link to clipboard

Copied

You should create two configurations in your project, one for debug and another for release. You shall see a dropdown in VS toolbar to switch between the two. If you don't have access to InDesign's Debug build, you will need to compile the release configuration of your plugin. The main difference in the project setting of a release and debug configuration are as follows.

  • You need to link with the debug versions of the lib.
  • You need to pass the NDEBUG flag in the PreprocessorDefinitions to the C++ compiler.
  • You should not pass debug to the odfrc command line, -d debug is meant for debug configuration only.

Once you do all the above-mentioned steps, the plugin should load on the release version, i.e., the public version of InDesign, which is available to your clients. For debugging release builds, you need to generate debug symbols for release versions of the plugin, which are generally not generated for optimization and speed up purposes.

-Manan

 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Oct 26, 2020 Oct 26, 2020

Copy link to clipboard

Copied

Hi Manan,

The removal of "-d debug" from the .fr custom build step did the trick 🙂

Thank you very much for all your help !

Very best regards,

Olivier

 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines