PackageContents.xml update from 2013 to 2014

[Anonymous]

Hi

I have recently downloaded the last version of Autocad, 2014. As I understand my applications for 2013-version should run on 2014-version. But my bundle does not seem to load my dll. 

I have updated the SeriesMax to 19.1 (See attached image), but the commands does not seem to be recognized. The partial cui is loaded, but the commands does not work when the buttons created from the partial cui is pressed. (See attached image)

Why is this happening?

[fenton_webb]

Can you post the bundle maybe?

[Anonymous · Accepted solution]

I have found the problem.

For the 2014 version you cannot have both of these lines:

LoadOnAutoCADStartup="False" and LoadOnCommandInvocation="True"

So when I just removed the first one everything works fine 

I know it was redundant to have both, but I had it since it was very explaining when someone read the xml file.

[DiningPhilosopher]

Well, great that you've solved that one, but it is not redunduant to have both, when one is false and the other true.

I can't imagine why that problem should be happening at all.  It wouldn't happen if the elemetns were being processed correctly. Those elements correspond to a set of flags, any of which can be either true or false.

[BlackBox_]

---

@DiningPhilosopher wrote:

... It wouldn't happen if the elemetns were being processed correctly.

---

*Points finger to nose*

this.Mode = Modes.Rant;

You should see how (poorly) CUIx are handled by Autoloader (if you haven't already)... Duplicates are replicated into each version's ..\Support\ folder, and if one disables a given plug-in (by deleting, or renaming the .bundle), the 'residue' (duplicate CUIx files replicated) are still loaded!

Never mind if you have Foo1.cuix, and Foo2.cuix, the Ribbon shows Foo2, then Foo1 RibbonTabs... Rearranging the elements in PackageContents.xml has no change. Even in CUI Editor Foo2 is shown above Foo1.

Further is the issue of incorporating partial CUIx RibbonPanels via common RibbonTab ID, which must include the 'parent' RibbonTab in Main CUIx, and cannot simply be added programmatically via RibbonControl at Startup, because Autoloader loads the CUIx prior to RibbonTab being programmatically added via RibbonServices.RibbonPaletteSet.Loaded Event.

So in the scenario of Foo1.cuix, and Foo2.cuix, and a code generated RibbonTab "FOO" (all with same ID), the Ribbon reads ... FOO (showing Foo2 Panel), FOO (showing Foo1 Panel), FOO (blank, from code)... Less than simple, and a great distance from intuitive IMO.

[dhaverstick]

A big "Amen" to what BlackBox said! I've been fighting with CUI's and Autoloader stuff since it came out and apparently nobody at Autodesk understands that there are problems with this.

Darren

[fenton_webb]

The Autoloader doesn't do anything special, it just utilizes existing functionality. The reason it copies the CUIX's around is because they are per-user editable files.

Why the CUI is not being unreferenced when the bundle is deleted is most likely because the bundle has no ProductCode and UpgradeCode defined, or those defines are not unqiue.

Also, once the bundle is removed, AutoCAD must be restarted to process the 'bundle remove'

[BlackBox_]

---

@fenton_webb wrote:

The Autoloader doesn't do anything special, it just utilizes existing functionality. The reason it copies the CUIX's around is because they are per-user editable files.

Why the CUI is not being unreferenced when the bundle is deleted is most likely because the bundle has no ProductCode and UpgradeCode defined, or those defines are not unqiue.

Also, once the bundle is removed, AutoCAD must be restarted to process the 'bundle remove'

---

Hi Fenton,

While the ProductCode, etc. precludes the CUIx from being reloaded after a given .bundle has been renamed to *.bundle.void for example, the CUIx copy(s) remain.

Example:

Each of 100 users with AutoCAD 2012, 2013, and 2014 installed, and have opened each version with an app enabled once, and then remove/rename the app .bundle, and have restarted each application once again, there's now 400 copies of the associated CUIx (100 being from the source app itself, the others in their respective version's ..\Support\ folder)... When all that is needed is one copy of the app (and the CUIx definitionally), located on the network (provided the license is free, or valid for X users; a separate topic).

Further, who is responsible for maintaining the product in the event a user breaks the CUIx, etc.? 

... Not sure that the last questions has an answer, really, but I am interested in your thoughts on the matter.

As always, I appreciate your time, and consideration.

Cheers

[fenton_webb]

First of all, I think that is an extreme use case that will never happen, 100 users on the same machine?

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.

[fenton_webb]

Just so you know, this whole mechanism is supposed to make your life easier - if it doesn't, you need to tell us why and explain how it should work better, then we will get it implemented for you.

[dhaverstick]

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.

[fenton_webb]

hang on, this is 2012 - did you install the sp?

[dhaverstick]

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.

Darren

[BlackBox_]

Hi Fenton,

[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. 

Cheers

[fenton_webb]

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.

[BlackBox_]

Where is all of this described in the documentation?

Who is responsible for maintaining broken user editable CUIX from downloaded exchange apps?

Why not instead simply allow the user to copy the desired CUIX components to their own Main/Custom CUIX rather than replicating it out to each-and-every-single product version's ..\Support\ folder? 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? So why not have a single user editble CUIX, rather than unneeded art duplicates?

Why can developers not provide per-user, and enterprise licensing for our exchange apps, that are able to be Autoloaded from the network rather than one per user machine?

Thumb drive copied/distributed apps?

[fenton_webb]

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.

[BlackBox_]

Hi Fenton,

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.

Cheers

[Rob.O]

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:

http://forums.autodesk.com/t5/NET/AutoCAD-2015-Autoloader-Changes/td-p/4910140