Topic: DLL updating

[MexicanCustard]

I've been using the new AutoCAD Autoloader(.Bundle) system to deploy applications within our company.  I keep the Bundle folders on a network drive and copy them to the local machine where needed.  Currently if I update a DLL then I just manually copy the updated file from the network to the local machine. Wasn't a big deal when only a couple of peeps were using the new software.  Now we're bringing more employees on board with the new software and 2 or 3 is turning into 30 quickly. So whats the best way to deploy apps and keep them updated within the company?

I thought about creating an app that checks the date of the local DLLs against the network DLLs and copies them locally before netloading them.  Any better ideas?

[BlackBox]

Why not just build that into the existing startup script(s) that execute each time a user logs in? All you need is a simple XCOPY call with the appropriate options (sub-directories, etc.).

Further, you can build into your existing app(s), or as a separate app to add to the mix, a folder monitor that can notify the user when you've made changes available on the network, that gives them both the option to save their work and update immediately (followed by restarting their session), or to postpone if they're in the middle of a tight deadline after acknowledging that the next time they start a new session that the update will be done at that time.

HTH

[Keith™]

Can you not simply load it from the network location, then you don't have multiple versions of it floating around. Of course the downside is that you can't update it while it is in use.

[MexicanCustard]

Can you not simply load it from the network location, then you don't have multiple versions of it floating around. Of course the downside is that you can't update it while it is in use.

It's possible, but because of .NET security you have to open AutoCAD up to loading .NET apps from any remote source including the internet.  I don't think that our users would ever try to load a .NET app from the internet or outside network but if the possibility exist then the IT guys just won't have it.

[Draftek]

I have the same setup with about 150+ users.
Maybe not the most advanced setup but its worked for a few years now.

I have a deployment app which merely copies the files to the machines and adds a shortcut to a network server application which brutally copies the files again for any updates.

[Keith™]

Can you not simply load it from the network location, then you don't have multiple versions of it floating around. Of course the downside is that you can't update it while it is in use.

It's possible, but because of .NET security you have to open AutoCAD up to loading .NET apps from any remote source including the internet.  I don't think that our users would ever try to load a .NET app from the internet or outside network but if the possibility exist then the IT guys just won't have it.

You guys don't use mapped drives? The OS treats them as local resources and AutoCAD doesn't know the difference.

[BlackBox]

Can you not simply load it from the network location, then you don't have multiple versions of it floating around. Of course the downside is that you can't update it while it is in use.

It's possible, but because of .NET security you have to open AutoCAD up to loading .NET apps from any remote source including the internet.  I don't think that our users would ever try to load a .NET app from the internet or outside network but if the possibility exist then the IT guys just won't have it.

You guys don't use mapped drives? The OS treats them as local resources and AutoCAD doesn't know the difference.

Mapped drives do not alleviate the issue of single copy unable to be updated while users have an active session.

The requirement being to either replicate to local disk via the production copy stored on the mapped drive, or to simply implement a mechanism (even if a manual process) of replicating out to that mapped drive's location with updates after hours, no?

[Keith™]

You are absolutely right. A resource in use can't be updated. In that scenario, I'd suspect that the update would be best done after hours or before users log on in the morning.

Even if you copy the DLL to the local machine, you would be better off simply doing it at logon. Trying to make the application search for a new version, copy that version local and then force the user to restart AutoCAD doesn't seem like a good solution either.

I just had a thought though .. perhaps a loader/update assembly would be best. The loader/update assembly queries the network location and determines if it is the latest version, if it is, then it copies it locally and then loads it ... this would not require a restart of AutoCAD because the assembly has not been loaded yet. The only time this would require an update is if the loader/updater was actually updated.

A simple check of the DLL assembly version on the local system and a network query to get the remote version would be all that is required to make it work.

[dgorsman]

Pretty much what I do.  I can't rely on users to be out of AutoCAD overnight - there's always a few who just *have* to leave their computers on, logged in, appliications running, and documents open overnight.  I have a simple DOS-box EXE which I can call from a simple LISP routine on start-up, which waits for all sessions of AutoCAD to close before it copies down the DLLs (and can add the contents of some REG files as well).

[MexicanCustard]

I just had a thought though .. perhaps a loader/update assembly would be best. The loader/update assembly queries the network location and determines if it is the latest version, if it is, then it copies it locally and then loads it ... this would not require a restart of AutoCAD because the assembly has not been loaded yet. The only time this would require an update is if the loader/updater was actually updated.

A simple check of the DLL assembly version on the local system and a network query to get the remote version would be all that is required to make it work.

This was my first thought too.  Only I like using the new Autoload and "programatically" netloading them means you cannot use that system.  Not that that's a bad idea though.

Pretty much what I do.  I can't rely on users to be out of AutoCAD overnight - there's always a few who just *have* to leave their computers on, logged in, appliications running, and documents open overnight.  I have a simple DOS-box EXE which I can call from a simple LISP routine on start-up, which waits for all sessions of AutoCAD to close before it copies down the DLLs (and can add the contents of some REG files as well).

That gives me an idea about letting the DLL version checking app run on AutoCAD shut down and just update the AutoLoad folders.  Is there a point during AutoCAD shut down when the DLLs are unloaded?  Would make things alot easier if there was a way to un-netload an app.

dgorsman - I saw where you had asked this same question some time ago on the Autodesk forums.

[BlackBox]

Is there a point during AutoCAD shut down when the DLLs are unloaded?  Would make things alot easier if there was a way to un-netload an app.

AFAIK - Even if there is, it won't help, as one cannot invoke this functionality... Meaning either way (knowing or not knowing where the unload point is), one must still fully quit the session(s) before the assembly is available for updating.

[Jeff H]

Have tried using Process class to get acad.exe and hook to Exit event?
Maybe in IExtensionApplication.Terminate you start new process that is a seperate application that then watches for acad.exe to end, and updates the files.
 
 
Or it could delete on exit and load them back up on start up.
 

[Keith™]

I just had a thought though .. perhaps a loader/update assembly would be best. The loader/update assembly queries the network location and determines if it is the latest version, if it is, then it copies it locally and then loads it ... this would not require a restart of AutoCAD because the assembly has not been loaded yet. The only time this would require an update is if the loader/updater was actually updated.

A simple check of the DLL assembly version on the local system and a network query to get the remote version would be all that is required to make it work.

This was my first thought too.  Only I like using the new Autoload and "programatically" netloading them means you cannot use that system.  Not that that's a bad idea though.

You can't do this even if you have two separate assemblies? Autoload the loader/updater then let it update (or not) and programmatically load the child assembly from the loader. Loading the loader would essentially autoload the actual program as well.

dang .. thats a load

[BlackBox]

I am not yet using the Autoloader mechanism personally (looking into doing so; this thread is helping me to better understand limitations), but currently using Registry to do so at startup, and at least there (in the registry) the ..\Applications\ key is processed alphabetically, and loaded in kind (i.e., "_App1" loads before "App1", etc.)... Perhaps the same works with bundles?

Regardless, you'd still need to check for write-access prior to performing the update in the event another process (offline files, etc.), or session has locked the file(s) / folder(s).