Why not include the ini file as part of the addin package?
Then everyone is working from the same information and you can still push out changes by updating the addin package.
Thanks for replying. I often use an ini file for adding emails or lists that change often. When I need to add or delete an email I open the ini in notebook, edit, save and I’m done. If I store an email list in an add-in I would need to open the program in .net, change the email, rebuild, open the admin tool, remove the add-in, etc. etc. My question is probably more, should the ini file be in the vault or on the network. Is one slower to open the file than the other?
I think what Simon means is to include the INI file with deploying the add-in (not hardcoding in the code). When adding the add-in in the Administration file you can select more files in addition to dll files. The you can access this file in the add-in using relatieve path.
But adding the INI to the vault is a good idea for me. You can also control the access permissions for the ini in the vault. Just do not forget to get the latest version of the ini file in the code whenever you are accessing it.
Artem Taturevych, Application Engineer at Intercad (Australia)
translationXpert – add-in to translate SolidWorks models
myIntercad – an integrated tool for SolidWorks Professionals
Thanks Artam for clarifying. I never thought of adding the file as part of the package. Even though you clarified the asnwer I’m going to give the correct answer to Simon because he was first, I wish I could give it to both of you.