.NET
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

netload does not load dll

25 REPLIES 25
Reply
Message 1 of 26
PencilsWereSoEasy
4723 Views, 25 Replies

netload does not load dll

I've read through a number of threads on this, but they all seem to go after the code which i don't think applies to me.

 

I've got a firm of about 60 architects and we use a custom dll that loads on drawing open.  the dll loads fine on all but one computer.  even explicitly issuing the netload command and grabbing the dll manually does not work.  it also does not work on other profiles on that computer (i tried an admin profile, even though the user is a local admin).

 

so it seems there's some kind of environmental setting somewhere that i'm missing.

 

any thoughts?

 

we're using .NET 4.0 on ACAD 2011

 


______________________________
~ "if this were /. this would be funny"
25 REPLIES 25
Message 2 of 26

Hi,

 

Di you set up acad.config to work with 4.0 in that machine? Is .NET 4.0 Framework installed in that machine?, 32/64 bit issues, etc etc.

Also try posting the error message if any.

 

Gaston Nunez

 

 

Message 3 of 26

4.0 is installed, i have not edited the config file, but i also haven't edited on any of the other 60 boxes that seem to be working fine.


______________________________
~ "if this were /. this would be funny"
Message 4 of 26
Ed.Jobe
in reply to: PencilsWereSoEasy

I had an issue like that. There is some resource, etc. that that machine is lacking that causes a failure (unhandled exception) in your code and thus it won't load. Since  you don't have VS on that pc to do debugging, what I did was create some temp debugging statements in the dll that printed status messages to the editor at key points in the code. e.g. "Stage 1 passed". That helps narrow down where in your code the error is occurring. You could also include something similar in your Try..Catch statements. If you are not using Try..Catch, you could be getting errors and not knowing it. In my case, I still had some legacy vba stuff that I was loading at startup and on some pc's, the vba enabler never got installed.

 

Also, since the dll is loading on an event, it behaves a little differently than manually loading it. When you manually load it, the event is not firing, thus your code doesn't execute. So the dll could be loading but not executing. You could also create a command that runs the delegate that the event calls. That way you could test it manually.

Ed

EESignature

Message 5 of 26

Just guessing here but could it be a security issue?

 

Any chance dll was downloaded to computer? Maybe needs "Unblock"?

 

If Windows 7 machine could UAC be set too high?

 

CAD Programming Solutions
Message 6 of 26

we're still on XP (no UAC) and because i tried two different windows profiles (the user and an admin) i assume any security setting issues would have presented themselves.  The IE settings on in the admin profile are the OOTB settings.


______________________________
~ "if this were /. this would be funny"
Message 7 of 26
DiningPhilosopher
in reply to: Ed.Jobe


Also, since the dll is loading on an event, it behaves a little differently than manually loading it. When you manually load it, the event is not firing, thus your code doesn't execute. So the dll could be loading but not executing. You could also create a command that runs the delegate that the event calls. That way you could test it manually.


Hi.  What you say above does not appear to be the case here. Would you care to explain further what 'event' managed assemblies are loaded on?  

 

As far as I know, there is no difference in the behavior of a managed assembly regardless of how it is loaded. The IExtensionApplication.Initialize() method will always execute regardless of how a managed extension dll is loaded.

Message 8 of 26
Ed.Jobe
in reply to: DiningPhilosopher

Kelvin,

 

Thanks for requesting clarification. So when I said "it behaves", I didn't mean the dll load process, but code execution. My first suggestion addressed the possiblity that a runtime error in the Initialize method prevented the dll from loading. The second suggestion addressed the the possiblity that the dll did load, but without any observable effect.

 

Since the OP didn't post any code, I have to make some assumptions. Yes, the code in the Initialize method would run, but I don't know what that might be, if any. This is the statement I was addressing:


@PencilsWereSoEasy wrote:

even explicitly issuing the netload command and grabbing the dll manually does not work.

 It sounded like he expected the code that runs in the dwg open event, to work when he netloaded it. So I was pointing out that the open event would not fire at that point. Therefore, it may only appear that the dll didn't load successfully. To test the code that runs in an event, he could create a command method that calls it, provided that any requirements that the code needs to run are met. Looking back, I also see I may not have understood one part. It appears that the problem dll is possibly being called from another dll during the dwg open event. That doesn't necissarly imply that any other action is happening upon dwg open. So we really have no clear idea what's going on until they provide more details. Until then, everybody's just throwing out ideas.

 

Thanks again.

Ed

EESignature

Message 9 of 26
PencilsWereSoEasy
in reply to: Ed.Jobe

and then just for MY clarification (since i have no coding knowledge, other than minor LISP) i'm assuming that just manually issuing NETLOAD and reaching for the dll file should work.  am i correct on that?  that process works on every other machine except the porblem one, and it also seems to work with my acaddoc.lsp file doing the net-loading.


______________________________
~ "if this were /. this would be funny"
Message 10 of 26
Ed.Jobe
in reply to: PencilsWereSoEasy

When you say, "it works"or "it doesn't work", we have no idea what that means. Think "here's what I think should happen" and "here's what actually happens" and then provide the details. Yes you can netload the dll, but what do you expect to happen after netload finishes? (note the side discussion on whether you have code in the Initialze method). If it loaded successfully, you should be able to see its commands listed if you run "ARX C". If not, you need to find ways to debug your code. If you can't run VS on the problem pc to do an actual debugging session, then you can code in some "progress markers" or other indicators of code execution. Even using a messagebox here and there works to display some status info.

Ed

EESignature

Message 11 of 26
PencilsWereSoEasy
in reply to: Ed.Jobe

sorry,  both the following are initiated by me manually typing NETLOAD at the command and choosing the dll file.

 

works = i can issue and embedded command "MYCOMMAND" and get a "Hello World" printed to the command line and the main function of trapping a double-click event and replacing the normally returned form (acad's block editor) with our own custom form.

 

does not work = upon choosing the dll file, i get no errors or notifications, but "MYCOMMAND" doe NOT return "Hello World" and the double-click event does not produce our custom form.

 

and it only does NOT work on one computer, and it does not work in etiher the normal user profile nor when i log in under an admin profile.  which is why i feel it's something like a global security setting on that machine.  (the user is a local admin with full local rights)


______________________________
~ "if this were /. this would be funny"
Message 12 of 26
Ed.Jobe
in reply to: PencilsWereSoEasy

It may be possible, but you have to start testing and ruling out what you can. Why couldn't it be a problem with your code/dll? Try creating a test dll that just pops a message box that says "Hello World". Don't use the command line as that depends on references. If something simple works, you know its not file access rights. It could be something like that pc has acad installed differently and the mgd files can't be found.

Ed

EESignature

Message 13 of 26
PencilsWereSoEasy
in reply to: Ed.Jobe

perhaps, but all these boxes have come from a standard image that we use for all cad workstations, so the install should be identical across the board.

 

did i mention i've tried repairing (to no avail) then actually uninstalling and re-installing acad (to no avail, although i did not go through the registry and kill all the related keys - but think it should have gotten me close enough if the problem was realted to an install (we also use standard profiles and workspaces in the office)).


______________________________
~ "if this were /. this would be funny"
Message 14 of 26
Ed.Jobe
in reply to: PencilsWereSoEasy

The suggestions I offered are a whole lot quicker than uninstall/reinstall. Give it a try. Until you verify through testing that the problem is NOT with your code, you're spinning your wheels testing the OS.

Ed

EESignature

Message 15 of 26
PencilsWereSoEasy
in reply to: Ed.Jobe

ok, i guess what i'm going after is if anyone has any thoughts about settings, since the code DOES work (whether auto loaded or manually loaded) on a lot of other machines.  and that it also doe not work on multiple profiles on that one machine.

 

but i've got the programmer doing the dialog suggestion now.  so i'm expecting that upon loading, i'll get the popup dialog


______________________________
~ "if this were /. this would be funny"
Message 16 of 26
Ed.Jobe
in reply to: PencilsWereSoEasy

I thought you were the programmer. Accurate information is important for troubleshooting. Think of it like working on a car. If your car doesn't start, what you you do first? Start replacing spark plugs, air filter and fuel filter,  or run some diagnostic test to get information? Friday my son called me, his motorcycle had stalled. I could hear him cranking the starter and the battery was going dead. So we set out getting a new battery. It was late and we couldn't get one, so I brought the old one home and charged it hoping it would last long enough for him to get home. It cranked but the bike still wouldn't start. Then I found out it went dead because he had been cranking on it trying to get it started again. Wish he had told me that at first. Once I had some accurate info, I traced it to a disconnected vacuum line. Troubleshooting is all about getting good information. Since  you aren't a programmer you may have missed it, but the suggestions I gave you are way to get info you wouldn't normally get. Like plugging in an engine analyser. Even though the dll works fine on most pc's, its still possible that the code can fail on one. The code uses the pc's resources. If it uses them improperly or if the resources aren't available, then the code fails. You're looking for some setting to be different on that pc, but you realize that something on that pc is different. That something could be a resource that the code depends on. The only way to know is to do some diagnosting testing. In the programming world, we call that debugging.

 

BTW, if you do get a simple dialog to display, that tells you that the basic framework is ok. The problem must lie with the dll that won't work. More thorough debugging would be required. In the car analogy, that's like eliminating a lot of possible problems by first checking for spark to see if its an electrical problem or a fuel problem.

Ed

EESignature

Message 17 of 26
PencilsWereSoEasy
in reply to: Ed.Jobe

fair enough, but after a decade at this office i've learned that i can take certain liberties in troubleshooting.  the fact that they all come from the same image for the same model dell box with the same specs usually is enough of a safeguard that i can relay on if only a single computer is bombing.

 

and at this point, we're just gonna re-image it anyway and try that.  


______________________________
~ "if this were /. this would be funny"
Message 18 of 26
Ed.Jobe
in reply to: PencilsWereSoEasy

It would be interesting to see if it works.

Ed

EESignature

Message 19 of 26

Please FULLY describe the problem you ran into. For example, when you said:

 

"MYCOMMAND" doe NOT return "Hello World",,,

 

Not returning what you expected, is just one of the possible symptoms that show "it does not work". Once you issued "MYCOMMAND" command, if the "Hello World" is not shown, does AutoCAD shows "Unknown command" (or something like that), of nothing at all (very unlikely, but according to your description, it seems the case?).

 

Does your DLL implement IExtenseionApplication interface? If yes, do you have proper try...catch exclosed the code in Initialize(). If not, exception in Innialize() would fail loading the DLL assembly (then, when you enter command MYCommand", you should get AutoCAD prompt for "unknown command").

Message 20 of 26
DiningPhilosopher
in reply to: Ed.Jobe

Sorry ejobe, let me requote again what you wrote: 

 

   "Also, since the dll is loading on an event, it behaves a little differently than manually loading it"

 

I was asking you what 'event' the DLL is loading on, and why it would behave differently (loading or code execution, it does not matter which) if it is loading on 'event' verses being loaded manually via NETLOAD.

 

Could you please clarify that?

 

Most of us are all well aware that if an exception is raised in the IExtensionApplication.Initialize() method, it will prevent registering of commands and event handlers, but that will happen regardless of how a dll is loaded (e.g., on an 'event' as you put it, or manually).

 

As far as I know and have seen based on my own testing, there is no difference in the behavior of code execution that depends on how a dll is loaded. And I'm still not understanding what you mean by 'loaded on an event'. 

 


Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th


Autodesk Design & Make Report

”Boost