Netload behaves different in lisp and command line

Netload behaves different in lisp and command line

JamesMaeding
Advisor Advisor
706 Views
3 Replies
Message 1 of 4

Netload behaves different in lisp and command line

JamesMaeding
Advisor
Advisor

I grabbed the latest ArcGIS for Autocad (AFA), and did as I normally do with the "bundles", which is grab the files needed to run, and put on a folder not in program files so I can copy to lots of user machines without doing installs.

You typically just need to add a path to the folder you put in, then do some loading and possibly menuloading instead of the registry having acad autoload things.

In my case, I specifically do not want the add-on loading until needed. So killed two birds with one fell swoop.

AFA has one main dll you must load to get things going.

I tried this with lisp - (command "netload" "the dll...").

It seems to load it, but then fails to find a needed dll that is in same folder.

If I do the netload through command line, and pick the dll by browsing, it finds the dependency and works.

I have secureload at 0, since the security is fake to begin with.

So does anyone know if the lisp call to netload is somehow different than manual netload?

My next test is to see if loading the dll in c# will work.

This absolutely may be something with AFA, but checking to see if its an acad thing first.

BTW, AFA outclasses acad Map for GIS data file prep from a dwg IMO. It even has a lisp API like Map does.


internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties

0 Likes
707 Views
3 Replies
Replies (3)
Message 2 of 4

norman.yuan
Mentor
Mentor

I am not aware that there is difference between executing command "NETLOAD" manually and by LISP (Command "NETLOAD" ...).

 

Looking at the bundle's "PackageContents.xml" file, it list all 10 dlls as LoadOnAutoCADStartup="True", which, IMO, is not necessary, though harmless. If the DLL "ArcGisForAutoCAD.dll" contains all the commands for the suite and possible IExtensionApplication implementation and all other DLLs are referenced in it, then only this one needs to be explictly loaded in AutoCAD on startup (or loaded manually with command "NETLOAD", as you do it manually without issue), other referenced DLLs should be loaded automatically. Again, I do not see why LISP statement (Command NETLOAD" ...) does things differently.

 

One more thing to look at, not sure if it is relevant, is that since you place all the DLLs of the suite in your chosen location, instead of running the bundle's setup.exe, do you add a support path to the chosen location, as the setup.exe does (pointing to C:\Program Files\Autodesk\ApplicationPlugins\ArcGisForAutoCAD.Bundle\Contents)? The support path is required for the plugin to locate AFA.cuix when ArcGisForAutoCAD.dll is loaded and initialize its ribbon menu.

 

 

Norman Yuan

Drive CAD With Code

EESignature

0 Likes
Message 3 of 4

JamesMaeding
Advisor
Advisor

@norman.yuan 

Wow, thanks for looking at it.

I also noticed the autoload in the xml. I actually tried setting that to false before completely moving to another folder.

I believe the install puts reg entries that autoload the dlls, so am not really sure what the xml is used for besides meta info.

You are exactly correct on just loading the one dll, and it works fine if you hand load the dll.

I do add the support path to folder with dll's, that is always necessary.

Its a mystery so far...

 


internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties

0 Likes
Message 4 of 4

JamesMaeding
Advisor
Advisor

I messed with things a bit, and found that if you use lisp to netload both the ArcGISForAutoCAD.dll and Microsoft.Xaml.Behaviors.dll, it works.

I did do an uninstall of arcgis to try to get things clean.

When I did that, the hand loading of ArcGISForAutoCAD.dll did not solve the problem it used to.

I know people will get distracted and say its the registry loading whatever, and that could be involved, but my post was about why the lisp call and hand calls behaved differently, given same environment.

I doubt we will ever get to the bottom of it, it is a bug though.

 

 


internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties

0 Likes