When I installed the new InDesign 2020 version 188.8.131.52, the plugins of sdk version 184.108.40.206 are not running with it. Is there a new sdk version? I can't seem to find it.
Yes you are right, the sdk at https://console.adobe.io/downloads/id is still from Nov 2019. If i look at the prerelease site i can locate a sdk version dated 20 days ago for 15.1, i think if indeed a compilation with new sdk is needed this will be release publically soon. However i am surprised that a minor vrsion update does need compilation with a new sdk version else the plugin's won't load. Hope someone from the Adobe dev team would be able to share some information on this
Manan, you are right. The problem does seem from my plugin. When I tested a previous version of my plugin, it worked with the new InDesign.
The strange thing is that, I removed the ".fr" from my project and added it again, because I was having a compilation problem. The compilation problem was solved, but the PlugIn is not running with InDesign and it is giving me the message that the PlugIn is not recognized by this version of InDesign. This is happening on new and old version of InDesign.
Appreciate if you have any ideas to solve that problem. The ".fr" problem does seem to occur everytime I move my project from one machine into another.
Have a look at the deeper contents of your project, e.g. using a text editor.
When you add a .fr file, it will miss the CommandLine= and related attributes that specify the ODFRC compiler.
Thank you for the info Dirk. I think you might be right, there seems to be an issue with the ODFRC compiler. The "objRx64" seems to have idrc_ folders that are empty.
As a temporary workaround I copied those resources from an old PlugIn that was working into the "objRx64" folder and compiled. It worked fine.
I still have to find the main issue that is causing the _idrc folders to be empty. This is causing me problems everytime I move my project.
Appreciate the suggestions,
If its a windows project, open the project file in a test editor as Dirk mentioned and locate the fr file listing in the file. It should have the command odfrc with other options set. For reference and exact command line to use you can check the sdk sample project files. You can also see documentation on how to set custom build step in VS so that you can do all this using the IDE. For MAC also its pretty much the same but i don't edit the project file directly in it but use the IDE
Rightly pointed by Dirk, if you add the fr to the project you need to make sure you add the command to get it compiled by odfrc. Also on a MAC sometimes after such operations a rebuild is needed else the resources are not compiled (just an observation, this might be some issue with project setting on my end. I have been lazy to give this a deep thought)
Ading to Manan:
ODFRC produces intermediate files which are later handled by merge_res.cmd and restore_res.cmd - they basically perform some copy tasks. These extra commands are invoked by pre-link and post-build events.
All of this is historically grown over two decades, and tied together with plenty absolute, and pseudo-absolute variables referring to places within / relative to the SDK. These variable are defined either thru .vsprops files and .rsp files, again with a quite grown structure. Redundant, competing, inconsistent.
As soon you move your project, all the references fall apart, point to wrong or missing folders.
So the simple solution is to keep your projects in the exact same build/win/prj folder that the SDK uses.
In the long run a solution could be: learn the project file formats, make a sense out of all the different approaches and oddities, and fix them. Want your project file with your sources, rather than within the SDK? Want your temporary build file outside the source hierarchy? You can do. Repeat with every SDK release, or write a script to perform the required steps. You may also discover references to missing include folders (causing slower compile times), or find it more convenient to compile multiple .fr files independently and only merge the results into a single plug-in, or rework structures in the official SDK projects that match the IDE of 10 versions ago, always lazily auto-converted while a modern re-build has a very different file layout. And so forth.
To get started with that process, put your project under source control. Do the changes one by one, and when it fails, rethink your most recent change. Consider every compiler error output even if it is hidden by the IDE. If this sounds like a lengthy process - yes it is. If you're planning to stay for many versions, write multiple plug-ins, it may be worth the effort.
Thank you Dirk and Manan for your answers. I thought I was doing something wrong in my setup of the project since I am new to InDesign. But it does seem to be a problem of dependency to SDK among other issues.
My project is now outside the SDK folder, but might be worth setting it up in the future inside the SDK as Dirk suggested.
Appreciated very much your help.
Thanks for reaching out. I hope your issue is resolved now. We'd appreciate if you can mark the appropriate answer correct.
If you used any other method, please share it here. It'll help other users having similar concern.
If you still have issues, let us know. We'll be happy to help.
While the immediate problem of the OP is apparently solved, the actual question from the subject/title is not answered: where is the updated SDK? I just had a look at the default place https://console.adobe.io/downloads/id and the Plugin SDK over there is still from 2019, same for ITK Symbols.
Even worse, there have been several other original Adobe messages cross-posted to the "SDK" section that mention new features "Share the document for review", but neither of them touches developer documentation, new SDK headers and similar resources.
So this question is definitely still waiting for some qualified input that only Adobe can provide.