Diff in Manual Netload w/ FileDia=1 vs LISP (Command "Netload" "...") ACAD 2012

[bjhuffine]

I'm going to start looking at Demand Loading, but I don't think that'll fully meet my needs.  Hopefully without me having to come up with a strawman sample, someone might have an idea of the issue.  If not, I'll see what I can do to replicate it in a strawman app, but that could be difficult because of all the parts. 

Does anyone know what the difference is under the hood in how the manual netload works vs the LISP command version?  I have an assembly that kicks off an exe that in turn hosts some WCF Services.  To ensure this process is kicked off correctly, I use some P/Invoke magic from the IExtensionApplication impelementation to call a Session state command.  This command configures the underlying framework and starts the process hosting (and to be honest, client proxy startup as well since it's self-hosting).  If I manually type in "Netload", then navigate from the file dialog to the dll, everything works like a top.  If I setup the acad.lsp with the same command, i.e. (Command "Netload" "C:/...."), there's all kinds of issues (which is why I haven't posted sample code here as it's really more in regards to what's going on under the hood vs a specific problem with the code). 

Most of the issues seem to be regarding it's inability to find certain referenced assemblies, processes, etc.   My Host.exe being kicked off by this process uses a configuration file that I have certain service assemblies mapped (since it's designed to generically load and host services).  It throws fits and absolutely cannot find it if a relative directory is used.  When I use the full file path in that configuration file to get past that, then it can't seem to start the Host.exe.

Another weird thing about this is that if I set FileDia = 0, then netload manually, I run into the same issues.  I'm guessing then that there's something about how the LISP commands use the FileDia setting?  Either way, I can't have users manually netloading an application for it to run.  It needs to be seemless.  Any thoughts?

[hgasty1001]

Hi,

I don't think there is difference in between the Autolisp function "netload" and the command version. I think that the problem may be the result of the order of loading/execution, could "acad.lsp" being loaded before the document activated event finished, and so if your code relies on that event or the document state then something could be in the wrong state. To my knowledge the last routine to be executed during start up its S::Startup, and this is after document activated finished, so may be it is a good candidate to put your loading routine in.

Gaston Nunez

[bjhuffine]

That is where I had it.  And there's definitely a difference.  I even ran the LISP Command (Command "Netload" "...") mannually in the command line after AutoCAD became quiesce to ensure it wasn't a timing issue.  I get the same exceptions.  This is definitely a first time I've ran into this.  The closest I have was when debugging configuration files.  In that case I had to add the <assemblyBinding> element.  That doesn't seem to be the case here and I'm really baffled.  And like I said, the manual "Netload" command without LISP gets the same exceptions if FileDia = 0, which adds to the question of "what's going on under the hood here?"

[augusto.goncalves]

Indeed I don't expect differences here... but can you attach some print-screen of the errors?

About your .NET project, please double check all AutoCAD references are set to copy local false. This means the folder where your DLL is places must not contain any AutoCAD DLL.

Looking forward to your reply...

[bjhuffine]

Augusto,

It turns out to be related to how it sees the file location.  I had instances of my code where it allowed (e.g. using Assembly.LoadFrom() to dynamically load an assembly to instantiate a type) for use of relative directories.  Under normal debug scenarios, this seemed to work just fine.  However, when I used the acad.lsp to netload it on startup, it didn't.  After some debugging I had found that it was looking in the AutoCAD install directory for files found in the Debug directory of the solution.  Afterward I was also able to replicate the issue by turning off the FileDia (set to 0), and then netload it.  So I'm assuming that there must be something the LISP api is doing that is either turning the FileDia off or related?  Either way, I think this is an important point worth understanding because it affects how we code with paths.  For now I've updated my code to use the Assembly.GetExecutingAssembly() operation, then extract the location and use that for a semi-relational approach but with a defined root.  I guess I'm curious if under the hood of the LISP api or the FileDia if something is occuring that would cause this (e.g. wrapping the netloaded dll in an AppDomain separate from AutoCAD (though I don't think this is it) whereas a command netload may not.

If you have an idea then great!  If not, then let me know and I'll try to create a strawman project for this scenario.

[augusto.goncalves]

And is this happens for folders that usually work? I'm asking in case the LISP code is trying to load from a untrusted location, which is blocked on AutoCAD for security reasons.

[bjhuffine]

Well, yes.  It worked just fine though the assemblies were in a folder separate from the AutoCAD install directory.  I have remote loading enabled via the acad.exe.config file.  But like I said, set FileDia to 0 or load with LISP, and it didn't like how it looked at directories.

[augusto.goncalves]

I made some testing on my end with FILEDIA=0 but could not reproduce it... indeed the security warning is appearing and this may cause problem, but if you have more details, maybe some steps, I can try reproduce it and investigate it better...

[bowa]

Have you considered having the DLL automatically loaded by including it in the Registry? The following REG stub will cause the file to be automatically loaded each time you open AutoCAD.

[HKEY_LOCAL_MACHINE\SOFTWARE\Autodesk\AutoCAD\R19.1\ACAD-D005\Applications\MyFile]
"DESCRIPTION"="My DLL Description"
"LOADCTRLS"=dword:00000002
"MANAGED"=dword:00000001
"LOADER"="C:\\Program Files\\path\\MyFile.dll"

 This one works for AutoCAD 2014. Change the path and file name to suit.