acaddoc netload not working

[noynpe]

Hi,

I am working on a deployment package for my company.

We have written a simple function to add a window containing a Microsoft Yammer site inside the civil 3D enviroment.

This works fine, but I'm having trouble sharing it with others.

I have added the following line in the acaddoc.lsp

(command "_netload" "C:/CAD/C3D/2021/Basics/CivYam.dll")

The whole deployment package downloads all our customization files including the CivYam.dll to the correct location.

When the users try to activate the function it seems as if the dll file has not been loaded as it produces  the following:

Unknown command "CivYam"

This works fine on my computer where I have built the deployment. Any ideas on what can cause this?

[Jeff_M]

You mention that the deployment downloads the file. Perhaps Windows has added the Block tag to the file so it needs to be Unblocked in the file's General properties.

[JamesMaeding]

in addition to the blocking thing, which affects my free Purgeids tools, check secureload settings as that can block stuff from loading too. I recommend 0 for secureload, especially since any other setting is not any more secure than 0 in reality. Its a fake feature if you understand acad programming.

[noynpe]

Thank you both for input!

The blocked DLL was my first thought also, I have now double ckecked and the DLL file is not blocked by Windows.

The securefileloadsetting was set to 1. Changed it to 0 and tested again with no result.

[norman.yuan · Accepted solution]

Firstly, you should run the lisp (command "_netload" .....) in acad.lsp, instead of acaddoc.lsp, which runs on every newly opened drawing, while the .NET DLL only needs to be loaded into AutoCAD once.

Also, you did not say what the deployment actually does except for place files to "...the correct location", I assume it is the folder "C:\CAD\C3D\2021\Basics". You need to make sure this location is a "trusted location" in the AutoCAD running profile.

You can easily find out if your DLL is loaded or not in following way:

1. You can make your DLL as IExtensionApllication and in the Initialize() method, write some message to the command line:

public void Initialize()

{

  var ed=Application.DocumentManager.MdiActiveDocument.Editor;

  ed.WriteMessage("\nLoading custom addin: \"CivYam.dll\"...");

  ... ...

}

This way, after AutoCAD started, you should see this message at command line.

2. Or you can simply add (princ "\nCivYam.dll loaded") following (command "_netload" ...) in acad.lsp. Again, after AutoCAD starts, you should see this message. 

If you do not see message at command line after AutoCAD starts, it is possible the acad.lsp does not get run by AutoCAD. you need to check if acad.lsp is available in one of the support path of running profile. Or, you may have mutiple support paths contain acad.lsp, but the only the acad.lsp in the first support path get run, thus the (command "_netload" ,,, ...) should be in this acad.lsp.

Or, the running acad.lsp (in your case, it is acaddoc.lsp, but again, you should use acad.lsp) contains many lisp statements before (command "_netload" ...), and it could run into error before (Command "_netload" ...) is reached, thus, the DLL is not get loaded.

The other possibility is that if your DLL does implemented IExtensionApplication and you have some code in Initialize(), make sure you wrap the all code in try...catch... Otherwise, if the code raises exception for some reasons (other users computers may have different configuration from yours, that may be relevant to your code in Initialize()), the loading DLL process would be aborted.

Since your DLL is placed in specific folder and not loaded with "auto loading" mechanism, you'd be better to provide some hint to user that the dll is loaded (by printing message to command line; no message, then, means not loaded).

[JamesMaeding]

@norman.yuan  has good points.

The SECURELOAD to 0 will eliminate the trusted path issue.

The issue of using acad or acaddoc.lsp is true too, however adding to acaddoc.lsp will not hurt.

The problem is we don't know if you have a finding and loading problem, or a dll incompatible problem.

You can solve that with adding code to your acaddoc.lsp, proving it found the .dll:

(if (setq fname (findfile "<dll path>"))

  (princ (strcat "\nFound " <dll name> " at " fname))

)

I'm not sure how to test if a dll loaded, other than to see if a function it provides works.

You are just defining commands, not lisp functions, so you might consider adding in a token lisp function so you can do:

(if <my lisp function name> (princ "\nThe dll loaded"))

The code for stub lisp function would be:

 [LispFunction("StubFunction")]
 public ResultBuffer LispStubFunction(ResultBuffer args) {
  return new ResultBuffer();
}

So you need to untangle the issues of loading vs compatibility.

Seems like the compatibility is fine if you can load it, that is all I test.

The other thing is that if you are having these issues, you need to spend some time reading the forums.

You will have much harder issues ahead than loading so be patient.

[noynpe]

Thank you very much for detailed description of multiple actions.

One thing I hadn't checked was the order of the support path. And indeed the support path was included but far down on the list and probably below another acaddoc.lsp.

I will take your  advise and put it into acad.lsp instead, I did not know about this. From the beginning I was trying to get my command to open Yammer at startup, but all I found was to put it in the acaddoc.lsp, but then it would run every time a new document was started, which is why I made a button instead.

Follow up questions:

- Without having done exstensive testing, I cant  seem to make yammer actually run on startup. I have put the following in my acad.lsp:

(command "_netload" "C:/CAD/C3D/2021/Basics/CivYam.dll")
(comman "_yammersweco")

It runs the netload, and my button for running the command works well, but it does not bring up the Yammer window upon startup. Are there any limitations to this that I am not aware, or am I simply doing it wrong?

- I have put the path to my custom acad.lsp and acaddoc.lsp on the top in my profile. This is the profile I have exported and all other users are supposed to use this, but for them the custom support path sits at the bottom of the list at support file search path. How can I controll this behaviour?

[Jeff_M]

@noynpe rather than using acad.lsp to autoload and run the dll, have you considered using the Autocad app autoloader? With it, you can specify to load at startup and to run a command at startup. And, it does not rely on the order of the support paths.

[JamesMaeding]

@noynpe 

Sounds like you need to get your program simply running first.

for that dialog, I assume its a modeless.

You should be calling that with:

Autodesk.AutoCAD.ApplicationServices.Application.ShowModalDialog(frm)

That makes it a child window of acad.

You can debug through your prog to see what is happening if the window will not show.

now, your acad.lsp and acaddoc.lsp should both be in your top support path.

ALWAYS make both files if you are in control, even if they are both blank. You do not want someone else's startup files found and run.

Controlling the top path for other users is an issue. You really don't want your .net program doing this.

Your program can add its path to the support paths, if you had something that runs by hand.

Your prog path should be fine at the end though.

The acad.lsp and acaddoc.lsp paths should be handled differently. What I recommend is some lisp the users run once by hand, that sets the acad.lsp and acaddoc.lsp path at top. Then in your acaddoc.lsp, you check that the paths are in order, so the system heals itself usually. The problem is if users start some other profile and the paths are not there, nothing works and nothing heals.

The solution to this I have used for 20 years now, is to make a company profile, and a company acad icon, with profile specified (/P in params). You have the company menus and things in it, so its obvious when a generic profile is started. In that /P, you specify a full .arg path to the default company exported profile. That solves the initial startup issue, where the company profile does not exist.

There are other solutions, and they take time to tune up, but once in place they work so well you forget about them most of the time. I manage 100 creative cad users this way, and if they really screw up their profile, they just rename it and it re-imports the default. That saves your but for remote people in a hurry, beggin you to get their CAD happy again.

[noynpe]

@JamesMaeding 

Thanks for alot of good advise here!

The program is up and running, and accesible by a custom button.

I was hoping to be able to set the path order in the deployment somehow without having to run a lisp or anything manually afterward. With 4-500 users this would not work.

As for the .arg file - I am doing this, but via a third party application we use as a base for our C3D enviroment. 🙂

[noynpe]

@Jeff_M I will look in to this! Thanks for the tip!