Topic: Autoloader

[RICVBA]

I'm in search for a fast way of testing&debugging AutoCAD plugins made in VSE2015 for Autocad 2014, trying to avoid that boring "netload -choose path&file- type command" procedure.

I thought Autoloader (http://adndevblog.typepad.com/autocad/2013/01/autodesk-autoloader-white-paper.html) could be a solution, where I should deploy my "application" once, specifying the proper path (the usual "...\Documents\VisualStudio\Projects\myProject\debug\") to the fresh .dll to be netloaded every time a debug session starts Autocad

Is anyone already aware it is possible?

Or which other solution is possible/better?

thank you

[Keith Brown]

If you are just using it for testing and debugging then modifying the registry for me is the way to go.  The tools by Gile here make that very easy.  If you are looking for a distribution solution then the autoloader would work better in that situation in my opinion. 


The reason why I don't use the autoloader all the time is I would need to copy the dll or dlls to the autoloader directory each time i modified them.  Now i could use visual studio to automate this but I prefer to just use Gile's tools to install and uninstall the dll when needed.  I have a separate dll with commands that will do that for me.

[BlackBox]

I'm a big fan of the Autoloader mechanism, and use it for both app deployment, and interim debug\release testing.

For the latter, simply setup an Autoloader .bundle, and in your Visual Studio Project's Properties, specify the relative path for where the PackageContent.xml file is loading your compiled Assembly (see ModuleName XmlProperty for the appropriate ComponentEntry).

This automagically creates the necessary Registry entries for you at debug launch, and the next time the application is started (in or outside of VS), any Autoloader assembly not found is cleared from AutoCAD's Registry for you.

The only real gotcha with Autoloader 'residue' comes from the replicating of .CUIx/.MNR files from the .bundle itself into each-and-every-single product's ..\Support\ folder. Grrr

Cheers

[Keith Brown]

I forgot to mention that I sometimes have a second autocad running to do extra miscellaneous operations.  Using the Autoloader in this scenario makes it a little more difficult as AutoCAD will lock down the dll.  Being able to uninstall in one version but having it running in another is a big plus for me.  The autoloader makes this difficult to achieve without constantly copying directories/files.

[Jeff H]

I just use the Autoloader that loads an add-in that checks folders if files have been updated and if so copies them and then netloads them.

[RICVBA]

@Keith Brown:
I made it with Gile's tool! (I must have made some mistakes...)
Now I'd like to have proper command already sent to Autocad as weel so that after launching debug I'm straight on my way at the first breakpoint
how is ět possible?

to install/uninstall dll selectively for different Autocad sessions do you filter autocad product keys via "GetAllProductKeys()" method?
I guess this could be possible with different Autocad releases only

@BB:
If I got it right, the Autoloader and Keith-Gile's ways acts similarly to my needs: in both cases I must take care of uninstalling what I don't need anymore (removing assemblies form Autoloader Directory vs running Uninstall() method).
but I'm quite worried/annoyed with that  "Autoloader 'residue'": what is this exactly?

@Jeff
through your way, do you suffer the BB 'reside' issue?


thank you all

[BlackBox]

Autoloader 'residue' are files that remain even after successful uninstallation of an app you've formally downloaded from Autodesk Exchange, or tested of your own making - and only if you've included .CUIx and/or .MNR files (a requirement to publish an app at Autodesk Exchange).

This is an inherent 'benefit' of the Autoloader mechanism, and applies to any, and all Autoloader apps, regardless of your procedure to compile and update an Autoloader app's .bundle's assemblies.

The only way to avoid this issue (and again, only if using .CUIx or .MNR files), is to NOT use Autoloader at all.

[BlackBox]

Autoloader 'residue' are files that remain even after successful uninstallation of an app you've formally downloaded from Autodesk Exchange, or tested of your own making - and only if you've included .CUIx and/or .MNR files (a requirement to publish an app at Autodesk Exchange).

This is an inherent 'benefit' of the Autoloader mechanism, and applies to any, and all Autoloader apps, regardless of your procedure to compile and update an Autoloader app's .bundle's assemblies.

The only way to avoid this issue (and again, only if using .CUIx or .MNR files), is to NOT use Autoloader at all.

More information here:

http://adndevblog.typepad.com/autocad/2013/01/autodesk-autoloader-white-paper.html (<-- see comments at bottom)

http://forums.autodesk.com/t5/net/packagecontents-xml-update-from-2013-to-2014/m-p/3872842#M34603

[RICVBA]

Thank you  BB
As for now I don't use CUI and/or MNR files (at least for what I'm aware of ...)
So I'll give Autoloader way a try, too.

Skipping for a while (if I get feedbacks I'll start a new topic) to another argument I thought I saw a very fine topic in the swamp net thread about how to design an application for Autocad. It mainly investigated the high level design of it before jumping into some coding details (but not that many). I remember it was attended by the most clever of swamp guys and probably all of you here.
well, I'd like to get to that topic again but I couldn't make it till now. It should have started some 6 to 12 months ago and may not have had a proper topic title.
Maybe someone of you can help me getting that topic.
This since I actually want to code for an Autocad application that make use of a new a palette to help the user "build" his objects with predifined properties and methods through multiple sessions (thus needing to save and retrieve infos between them

thank you

[BlackBox]

You're welcome; I'm happy to help. :beer:

I choose to use Autoloader, despite the .CUIx byproduct (which doesn't affect how an app performs at all), because of how simple it is for me to quickly debug/deploy an app, each-and-every-single time I decide to create a new plug-in after reading a forum, or just generally have a new idea for an app - methinks you'll find it (Autoloader) to be beneficial as well.


as for the PaletteSet threads, not sure what you're looking for specifically, but here are two recent threads that come to mind:

Converter Palette

Zero Document State and Custom Tool Palettes

[RICVBA]

Thank you BB
I'll have a thorough look at the second link
As for the first one  I already read it once and started wondering whether to quit Winforms for wpf.  I searched the web and ended up with the thought wpf should stay for desktop apps and could also help for new standard winRT which seems bound to rule for mobiles and web.
what are your thoughts about this subject?

[BlackBox]

As for the first one  I already read it once and started wondering whether to quit Winforms for wpf.

Boo WinForms, Hooray WPF!



*In before MexicanCustard*

[MexicanCustard]

Boo WinForms, Hooray WPF!

*In before MexicanCustard*

Sweet, another convert!  Soon I'll have you all using WPF and Winforms will go the way of the dinosaur.

[Keith Brown]

Winforms is not dead!  Still making a lot of money using this supposedly dead and archaic technology!

[dgorsman]

For those just starting, yeah - WPF is the way to learn.  Me, I learned on Winforms, they function, and juggling too many things to get enough large blocks of time to learn.  Whatever works, right?