Fenton, please refer to case ID 07828416 to see a similar problem to the one described above. Basically, what I want to accomplish with the Autoloader schema is this:
1) Have my users run an installer to install a AutoCAD plugin. The panel for this plugin will reside on a custom tab for all my company's plugins.
2) The next time the user starts AutoCAD, all the tabs and panels related to the just-installed plugin will be visible and available. The plugin dll is also loaded.
In order to accomplish this, I have had to write an executable that writes things to the registry in order for AutoCAD to know to create the panel for the new plugin dll at startup. This is done by loading another dll which, when run, will create the needed panels and possibly the custom company tab if it does not exist. Yes, I have tried creating partial cuix files in advance but that method does not work for my scenerio.
This process works but almost always causes AutoCAD to crash the first time the user starts it up after installing a plugin. The next time AutoCAD starts up, everything is cool and the plugin is available through the newly created panel. Unfortunately, I am unable to reproduce this crash while debugging the code.
I apologize. Yes the case refers to an older release. However, I have used the same code and process with AutoCAD 2013 with the same results. My preliminary testing with AutoCAD 2014 has also shown a crash when opening up AutoCAD for the first time after installing a plugin.
I did not intentionally hijack this thread and I apologize to the person who started it. Perhaps we should continue this discussion elsewhere.
[Fenton] - "First of all, I think that is an extreme use case that will never happen, 100 users on the same machine?"
Perhaps I should have been more explicit... I've never heard of any employer having more than one employee on any given workstation for anything other than temparary circumstances.
When I said 100 users, I very much meant one (1) user each with their own workstation, each workstationwitth their own, valid license of each 2012, 2013, and 2014 (we have thousands of users)... That's 100 users, 100 workstations, 100 licenses of 2012, 100 licenses of 2013, 100 licenses of 2014, and 100 copies of an Autoloader app stored locally.
Hopefully that makes (more?) sense to you now.
[Fenton] - "Nevertheless, the autoloader loads partial CUIX files into the main CUIX. It makes a copy of the partial CUIX in the user's roaming support folder so that any changes that the user makes are saved. If the original bundle that houses the CUIX is removed, then any main CUIX that references the named CUIX from the bundle will no longer load the afore mentioned partial CUIX. It will not be deleted, it will simply not be loaded. If the bundle reappears again, the copied CUIX in the user's roaming support folder will be used again, unless, the bundle contains a newer partial CUIX.
If any of this is not the case, let me know and we will fix it."
Firstly, thanks for clarifying the procedure/steps... This is the first I've seen this level of detail documented (if it is documented elsewhere publicly, I've not been made aware of it in several interactions in forums, DevBlog comments, and ADN staff).
That said, I still do not understand why the CUIx copies remain (and that doesn't make the procedure wrong, per-se)... If a given app is uninstalled, or otherwise made unavialble, the CUIx copies should be removed, methinks.
The reason the copied CUIX are not removed is because they are user editable files. As with any system, you generally don't remove user editable files on uninstall.
As I mentioned before the autoloader wraps existing core autocad functionality, it does nothing new - so as far as documentation is concerned, please refer to existing documentation.
I'm wondering why you are seeing these problems, and we cannot reproduce. Are you using multiple CUIX files via multiple workspaces perhaps? Multiple profiles? Or what exactly is your setup?
Your comment "Presumably if the user does make changes to said CUIX, they'd want their changes available to any/all versions the app is available to, no?" - I understand where you are coming from, but it's far too general an assumption to make. AutoCAD is used in so many different ways, doing something like that would in my experience bring the house down.
Simply installing your bundle to %ProgramData%\Autodesk\ApplicationPlugins makes the app available to all users of that machine.
In 2014, when you build a network deployment, you can add your app installer to the deployment and it gets installed automatically to your enterprise.
Loading apps from network drives, thumb drives, or any untrusted locations causes .NET security issues, which in turn causes confused, frustrated users and in turn support calls. The autoloader is intended to be simple, uniform (standardized across multiple autodesk products, AutoCAD, Revit, Maya, Inventor, Alias, Vault, etc etc) and super simple and reliable. Introducing thumbdrives will break that. You should read about .NET secuirty to fully understand where I'm coming from.
I'm really unsure where these misunderstandings are coming from; I used to think I was articulate, but seem to have been utterly unclear in my attempt at pointing out what I've been experiencing as a few issues with Autoloader for the past +/-6 months.
I will have to post back later today (perhaps during my lunch?), as we seem to be crossing paths, instead of having an honest conversation about Autoloader, its capabilities, and its limitations.
I appreciate your time, and consideration.
As an aside, methinks this would be a great time for a new "Autoloader" customization forum (mapped into the customization for each applicable product to one, single forum?), where several of the posts in this hijacked thread could be moved by Discussion_Admin.
Sorry to bring a somewhat "old" thread back from the dead, but I wanted to comment on the original content.
I have experienced this same issue of the copied CUIx files when using AutoCAD 2012. This did not occur until I upgraded to SP1. Kean mentioned in the comments section of one of the Autoloader DevCasts, that it appears to be an unintended side-effect introduced in 2012 SP1.
This is how I use the Autoloader utility in our environment (may not necessarily be as intended):
To stat, I really don't want the users changing our custom CUIx files as they are organized in a particular manner that is designed to follow a standard workflow.
I make changes to the ribbons on my machine and save them to our Vault server. The working copy of those CUIx files are stored in a secure location on the server.
I have some scripts that copy all of the .bundle folders from the server to each users machine when they log on to their computer. I am using the C:\Program Files\Autodesk\ApplicationPlugins folder to store the .bundle folders.
My design intent is that each time a user starts AutoCAD, they get all of the latest and greatest custom ribbons and .NET code.
With the issues that were introduced in 2012 SP1, if I were to update a CUIx file, the next time the user logged in and started AutoCAD, I would expect that they should see the new changes to the CUIx. Unfortunately this was not the case. The CUIx file was loading from the copy (in the support folder) and NOT the latest version stored in the ApplicationPlugins .bundle folder. As if it is only being copied the initial time it is found in the ApplicationPlugins .bundle folder and never again.
I got around this by setting up the scripts to delete the old CUIx files from the support folders. Works pretty well.
Anyway... we are getting ready to upgrade to AutoCAD 2015 and I have a new issue. I ran across this thread while searching for a resolution to the new problem and wanted to share my thoughts.
I have posted a new thread about the AutoCAD 2015 Autoloader problem here:
Access a broad range of knowledge to help get the most out of your products and services.
Start with some of our most frequented solutions or visit the Installation and Licensing Forum to get help installing your software.
Upgrading to a 2015 product? Make sure to check these out 1st!