.NET

.NET

Reply
Contributor
dhaverstick
Posts: 22
Registered: ‎01-12-2004
Message 11 of 19 (392 Views)

Re: PackageContents.xml update from 2013 to 2014

08-06-2013 07:15 AM in reply to: fenton.webb

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.

ADN Support Specialist
fenton.webb
Posts: 352
Registered: ‎07-24-2007
Message 12 of 19 (387 Views)

Re: PackageContents.xml update from 2013 to 2014

08-06-2013 10:06 AM in reply to: dhaverstick

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





Fenton Webb

Developer Technical Services

Autodesk Developer Network


Contributor
dhaverstick
Posts: 22
Registered: ‎01-12-2004
Message 13 of 19 (383 Views)

Re: PackageContents.xml update from 2013 to 2014

08-06-2013 10:48 AM in reply to: 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

Distinguished Mentor
BlackBox_
Posts: 785
Registered: ‎02-25-2013
Message 14 of 19 (381 Views)

Re: PackageContents.xml update from 2013 to 2014

08-06-2013 10:54 AM in reply to: fenton.webb

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



"Potential has a shelf life." - Margaret Atwood


Autodesk Exchange Apps ~ Autoloader ~ AutoCAD Security


AutoCAD® 2014, and Civil 3D® 2014 Certified Professional ~ Autodesk® Authorized Developer

ADN Support Specialist
fenton.webb
Posts: 352
Registered: ‎07-24-2007
Message 15 of 19 (375 Views)

Re: PackageContents.xml update from 2013 to 2014

08-06-2013 03:38 PM in reply to: BlackBox_

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.





Fenton Webb

Developer Technical Services

Autodesk Developer Network


Distinguished Mentor
BlackBox_
Posts: 785
Registered: ‎02-25-2013
Message 16 of 19 (370 Views)

Re: PackageContents.xml update from 2013 to 2014

08-06-2013 05:48 PM in reply to: Fredrik.Larsen
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?


"Potential has a shelf life." - Margaret Atwood


Autodesk Exchange Apps ~ Autoloader ~ AutoCAD Security


AutoCAD® 2014, and Civil 3D® 2014 Certified Professional ~ Autodesk® Authorized Developer

ADN Support Specialist
fenton.webb
Posts: 352
Registered: ‎07-24-2007
Message 17 of 19 (354 Views)

Re: PackageContents.xml update from 2013 to 2014

08-07-2013 10:58 AM in reply to: BlackBox_

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.





Fenton Webb

Developer Technical Services

Autodesk Developer Network


Distinguished Mentor
BlackBox_
Posts: 785
Registered: ‎02-25-2013
Message 18 of 19 (343 Views)

Re: PackageContents.xml update from 2013 to 2014

08-08-2013 06:45 AM in reply to: fenton.webb

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



"Potential has a shelf life." - Margaret Atwood


Autodesk Exchange Apps ~ Autoloader ~ AutoCAD Security


AutoCAD® 2014, and Civil 3D® 2014 Certified Professional ~ Autodesk® Authorized Developer

Valued Mentor
Rob.O
Posts: 261
Registered: ‎06-25-2007
Message 19 of 19 (206 Views)

Re: PackageContents.xml update from 2013 to 2014

03-25-2014 02:15 PM in reply to: BlackBox_

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

 

Post to the Community

Have questions about Autodesk products? Ask the community.

New Post
Announcements
Do you have 60 seconds to spare? The Autodesk Community Team is revamping our site ranking system and we want your feedback! Please click here to launch the 5 question survey. As always your input is greatly appreciated.