Pushing updates to an add-in from a shared network drive

[DRoam]

I finally took the plunge into add-ins, with a lot of help from this class by @BrianEkins. Thanks so much, Brian, for continuing to contribute to our Inventor/automation education. I'm pretty sure it was another AU class by you that got me started into iLogic several years ago, and I've done a ton with that. It's cool to learn from you again while taking this next big step.

Now that I'm stepping out of the VBA/iLogic world (where deploying "source code" updates is as simple as changing the shared VBA project and/or external iLogic files on our network), and into the the add-in world, I want to make sure I can still easily and seamlessly push updates to our engineers.

Here's the process I'd like to take place:

1. When an updated version is ready to be deployed, bump up its Assembly version and build it.
2. Copy the newly-built add-in folder to a specific network location.
3. Each user's machine should be able to check for updates and automatically update the add-in when a newer version is available from the network location.

#3 is the part that needs some clever ideas. Does anyone else do something similar to this? How would you suggest going about it?

My current thinking about how it could work goes something like this:

• Write a function in the add-in to check for an updated version. The add-in could run this function at launch, or at exit if possible. This function could possibly work by comparing the Assembly version of the local .dll with the Assembly version of the the .dll on the network (this will always be at the same location).
• If the versions are different, simply copy the add-in folder from the network to the appropriate add-in folder on the user's machine (just like would be done manually to update the add-in).

Does that seem like a good solution? Did I miss anything important?

Thanks for any suggestions.

[bradeneuropeArthur]

Hi,

Simple.

I created a *.bat file that copies the files from your network to the necessary inventor paths.

with the following paths.

2) Copy add-in dll file to one of following locations:
a) Anywhere, then *.addin file <Assembly> setting should be updated to the full path including the dll name
b) Inventor <InstallPath>\bin\ folder, then *.addin file <Assembly> setting should be the dll name only: <AddInName>.dll
c) Inventor <InstallPath>\bin\XX folder, then *.addin file <Assembly> setting shoule be a relative path: XX\<AddInName>.dll

3) Copy.addin manifest file to one of following locations:
a) Inventor Version Dependent
Windows XP:
C:\Documents and Settings\All Users\Application Data\Autodesk\Inventor 2012\Addins\
Windows7/Vista:
C:\ProgramData\Autodesk\Inventor 2012\Addins\

b) Inventor Version Independent
Windows XP:
C:\Documents and Settings\All Users\Application Data\Autodesk\Inventor Addins\
Windows7/Vista:
C:\ProgramData\Autodesk\Inventor Addins\

c) Per User Override
Windows XP:
C:\Documents and Settings\<user>\Application Data\Autodesk\Inventor 2012\Addins\
Windows7/Vista:
C:\Users\<user>\AppData\Roaming\Autodesk\Inventor 2012\Addins\

this bat file I place in the startup folder of every machine..

So if the machine is started new the files are copied...

Regards,

[bradeneuropeArthur]

for the bat file:

xcopy c:\folder\*.* d:\another_folder\. /Y

@Anonymous off
xcopy "P:\XXXXXXXX.dll" "C:\Program Files\Autodesk\Inventor ####\Bin\" /y

xcopy "P:\XXXXXXXX.addin" "C:\ProgramData\Autodesk\Inventor ####\Addins\" /y

[DRoam]

Thanks Arthur, I'll keep looking into it.

[BrianEkins]

@DRoam, I'm glad you've found the add-in template useful.  While I was recently using it I found that I was missing access to some newer .NET technology and have updated the template.  The new version is available on my site (https://ekinssolutions.com/update-to-add-in-template/).

Regarding this specific question, there are a lot of ways to tackle this problem.  The brute force method of copying all of the files when a machine is started will work and is probably the easiest.  From there you can get more complex and more elegant in the approach.  I think the ultimate would actually be to write an add-in that would check to see if the version of the add-ins installed on the machine matches the version of the add-ins in your network location.  If not, it would unload the add-in and then copy the files over, and then load it again.  I think it's usually best to start with the easiest solution and then improve that if needed.

[DRoam]

---

@BrianEkins wrote:

@DRoam, I'm glad you've found the add-in template useful.  While I was recently using it I found that I was missing access to some newer .NET technology and have updated the template.  The new version is available on my site (https://ekinssolutions.com/update-to-add-in-template/).

---

Good to know, thanks Brian. Can you tell me what I would do to get an existing add-in project up to the newer .NET spec? Is that possible?

---

@BrianEkins wrote:

... If not, it would unload the add-in and then copy the files over, and then load it again.

---

This is the road I'm heading towards, but I'm encountering a showstopper with this -- even after I unload the add-in, Inventor is still apparently "holding on" to the DLL file. If I try to replace or delete it, Windows says that the file is open in Inventor 2017.

Is this the behavior you see as well? Or are you able to replace/delete the DLL after unloading the add-in?

[etaCAD]

---

This is the road I'm heading towards, but I'm encountering a showstopper with this -- even after I unload the add-in, Inventor is still apparently "holding on" to the DLL file. If I try to replace or delete it, Windows says that the file is open in Inventor 2017.

Is this the behavior you see as well? Or are you able to replace/delete the DLL after unloading the add-in?

---

This is normal behaviour. Inventor unloads the add-in, but doesn't release the dll. As far as I know Inventor has to be closed before replacing your add-in dll.