Hello together,
in version 2016 I could modify the xml file to load the add-ins.
http://adndevblog.typepad.com/manufacturing/2016/04/add-in-security-in-inventor-2017.html
User override settings for Inventor 2017 are now stored in a binary file "%APPDATA%\Autodesk\Inventor 2017\Addins\AddInLoadRules"
http://help.autodesk.com/view/INVNTOR/2017/DEU/?guid=GUID-84B221D3-979B-420D-B955-9DCBDC0C5619
Which format does the file have? Is there any other possibility to modify the behavior?
Thank you
Georg
Hi Georg,
I am not fully understanding your workflow. Are you saying you do not want to use the steps in the DevBlog post you mentioned to prevent the security dialog popping up?
(Digitally signed add-in and the publisher of the certificate needs to be in the "Trusted Publishers" list)
I believe there is not another supported way to modify the AddInLoadRules binary file that is written to by Inventor when the User changes a setting for an Add-In in the Add-In Manager dialog.
Do you need to override what the user set for an Add-In? (un-block it ?)
In my limited testing the AddInLoadRule.xml file is still referenced when the AddInLoadRules binary file exists.
Thanks,
Wayne
Hello Wayne,
I have now 2 files: the binary and the xml-file. Is it possible to modify only the binary file? Otherwise I have to copy both files.
I have to override the user settings.
Thanks
Georg
Hello,
When you say "I have to override the user settings", are you an admin who would like to override settings for multiple users, or a single user overriding them for yourself?
If you are an admin, there is an administrator settings file that can be edited by someone with administrator privileges:
An expected use case is that the administrator would edit this file once when creating a deployment, and then install that for all users. The default copy of that file that ships with Inventor contains explanations of the various rules.
When individual users make changes, they are changing their user overrides file. This is located at the %APPDATA% path you mentioned in your post. Starting in Inventor 2017, that file is in binary format. We retained the ability to read the XML file for backward compatibility, so that settings made prior to Inventor 2017 would not be lost. But once the binary file is present (after the first time you save a change to the user overrides using Inventor 2017), the XML file will be ignored. We eventually want to eliminate reading settings from directories that are writeable by non administrators. So the supported way for users to make changes is via the Addin Manager Dialog, and the location and format of those settings are not exposed.
Note that user overrides do not necessarily override the administrator settings. For example, if the administrator decides to block an addin, and individual user cannot override the addin and allow it to load. (The reverse is allowed - a user can block an addin that the administrator has not blocked.)
I hope that helps. Let me know if you have further questions.
Joe
Hello Joe,
please send me some information about the file format. I need to change that file.
"But once the binary file is present (after the first time you save a change to the user overrides using Inventor 2017), the XML file will be ignored."
Thats not a good solution. There must be an Admin setting.
Georg
Hello Georg,
I would suggest deleting the binary file and then editing the XML. Note if you had made changes via the Addin Manager dialog, the XML file will be out of date relative to those changes.
Thanks,
Joe
I should add in response to your comment:
There must be an Admin setting.
The Admin setting is this file:
%INSTALLDIR%\Preferences\AddInLoadRules.xml
Note that an Admin setting has to go into an Admin-only writeable folder.
I dont know but for me it looks like the administrator file does nothing. I can edit that file to whatever I want.
<AddInLoadRules>
<Id Policy="Block">
{CD55624B-BXXB-4XXE-8XXA-8B5XXXD3XXX3}
<!--Addin1 -->
</Id>
<Id Policy="Block">
{6XXFFXX7-BXX7-4XXC-9F87-9FXXX67BXXX0}
<!--Addin2 -->
</Id>
</AddInLoadRules>
The file contains the code above.
regards
Tobias
I assume you have just obfuscated these GUIDS, but that the reals ones in your system match the actual values in the AddInLoadRules.xml file?
{CD55624B-BXXB-4XXE-8XXA-8B5XXXD3XXX3}
{6XXFFXX7-BXX7-4XXC-9F87-9FXXX67BXXX0}
and that these are not being blocked?
Are there other active rules in the publisher or trusted path sections in your AddInLoadRules.xml file?
If the add-ins are signed by a trusted publisher, they will be allowed regardless of the above setting.
Hi Joe
Yes I did change GUIDS for posting here but they are correct in the xml file and no there are no other active rules in this file.
I tried to do it step for step, so started from scratch and just added one addin with the code mentioned above.
The addins are not signed so they will be blocked. I think it will take some time until publisher start to sign their addins. One off them is pretty big and still didnt sign it.
If the add-ins are not signed by a trusted publisher, the code should continue on to check your ID rules. So if those GUIDs match, your block rule should block the add-in.
Can I confirm the version of Inventor you are using? The behavior I described started in Inventor 2017.
Yes we are talking about Inventor 2017.3.1
The GUIDS definitly match. I copy paste them to make sure.
Where is the addin installed?
If your Inventor install folder is, for example:
C:\Program Files\Autodesk\Inventor 2017\bin
Then addins underneath
C:\Program Files\Autodesk
will be trusted regardless of any ID rule.
They are both in separate folders. Something like this: C:\Program Files\Publisher\
Are the GUIDs new and unique to those add-ins? If you wouldn't mind sending me your XML I can try things out here. Otherwise I am not sure why this isn't working for you. Thanks.
Adding this as FYI so next time I search for an answer to this. Signing your add-in DLL is not enough, you have to import the certificate on the users machine. You can use powershell to do this like:
Import-Certificate -FilePath "C:\CA-PublicKey.Cer" -CertStoreLocation Cert:\LocalMachine\TrustedPublisher