Topic: CommandMethods stopped working

[sinc]

One of my users is reporting a problem.

For some reason now, whenever he tries to run any of my custom commands, he gets "Unknown Command".  The toolset used to work on his system, and it continues to work on everyone else's.  And during C3D startup, we see the standard messages it prints after it loads, so it looks like my custom code is being loaded into C3D and is running.  Just none of the command methods work.

Anyone else seen this issue?

[David Hall]

I have seen it, and it happens to plain Autocad as well as custom code.  The only way I have been able to fix it is to do a clean install of software.  I dont pretend to understand why a good install goes bad, but it does

[sinc]

Turns out that he didn't have the .NET 3.5 service pack installed.  We had to rebuild that computer recently, and all the updates never got loaded.  Once we got his computer up-to-date on its Windows Updates, everything was happy again.  

[sinc]

OK...  Time for "CommandMethods stopped working, Take 2"...

This time, my CommandMethods are not working, but ONLY in Land Desktop 2008, and ONLY when I'm running in debug mode.  I can run in debug mode in Civil 3D 2008, and it runs fine.  But in LDD 2008, I get "unknown command" errors.  And I can run the debug build in LDD 2008, and it runs fine, as long as I'm not trying to run it from the debugger in VS.

Other than the CommandMethods, everything is working.  I can put breakpoints in event handlers, and they are getting fired and running as expected.  It's just the CommandMethods that aren't working.

I checked the obvious things:  "Copy Local" is set to false on the managed DLLs, .NET is fine, all code in IExtensionApplication.Initialize() is running fine with no exceptions.

[Spike Wilbury]

have not done much c# lately... but by any chance that you might have a predefined exception on your Initialize(); like:

public void Initialize()

... some of your stuff goes here
... etc....

   throw new Exception();
}

[sinc]

No.  I even tried single-stepping through the code in Initialize(), and then also tried putting the whole thing in a try/catch block, just to see if some unexpected exception was being thrown, but could find nothing.

What would cause it to fail ONLY when running in debug mode in LDD 2008?  The same (debug) build runs fine in LDD 2008 if I don't run it from the debugger.  And it runs fine from the debugger in other Autocad products, even Civil 3D 2008.  It's only while running from the debugger in LDD 2008 that I have problems.

Is there anything in the User Profile that could cause this?  I suppose maybe I can start trying experiments like creating new Profiles...

[Spike Wilbury]

No.  I even tried single-stepping through the code in Initialize(), and then also tried putting the whole thing in a try/catch block, just to see if some unexpected exception was being thrown, but could find nothing.

What would cause it to fail ONLY when running in debug mode in LDD 2008?  The same (debug) build runs fine in LDD 2008 if I don't run it from the debugger.  And it runs fine from the debugger in other Autocad products, even Civil 3D 2008.  It's only while running from the debugger in LDD 2008 that I have problems.

Is there anything in the User Profile that could cause this?  I suppose maybe I can start trying experiments like creating new Profiles...

Sinc;

I have this info, that might help - maybe is that acmgd.dll it is being loaded twice for what I know it is demand loaded at startup - you might need to hack the registry and change the loadctrls or check if you have installation dir for Properties>Debug>Start Options and you mention about setting to false the copy local but don't copy acmgd to the debug/bin folder

[sinc]

I have all the managed DLLs with Copy Local set to false, so that should take care of that issue... right?

And it works fine when I run it in other Autodesk installations on the same computer.

[sinc]

Issue...  solved?  I don't pretend to understand it, but here's what I found...

I'm running on Vista x64.  32-bit apps get installed in a "Program Files (x86)" directory on this computer.

In order to maintain build compatibility with XP, I leave all settings in VS set to point to "Program Files".  Then I create links in Vista to link from the "Program Files" directory to the actual install location in "Program Files (x86)".  As a result, I can build on either Win XP-32 or Vista-64 without changing anything.

In keeping with that, my .csproj.user file had the following line:

Code: [Select]

<StartProgram>C:\Program Files\AutoCAD Civil 3D Land Desktop Companion 2008\acad.exe</StartProgram>
This seemed to work, in that Land Desktop started correctly when I started the debugger.  And this is how I have things setup for Civil 3D, where I do most of my work, and everything is fine.

But for some reason in Land Desktop, the CommandMethods don't work when I do this.  However, the CommandMethods start working again if I change that line in the .csproj.user file to this instead:

Code: [Select]

<StartProgram>C:\Program Files (x86)\AutoCAD Civil 3D Land Desktop Companion 2008\acad.exe</StartProgram>
For some reason, when I use the path that goes through the link, CommandMethods don't work.  When I use the path that goes directly to the Land Desktop installation directory, they work.

[Spike Wilbury]

well... i can test anything don't have x64     

[Dinosaur]

Just a thought - Land Desktop is pretty long in the tooth and you are trying to feed it a very complicated file path.  Could it be that some old file name or search path limitation is kicking in and making LDT barf?

[It's Alive!]

Interesting, I have found it much easier to setup a virtual machine for doing x86 work. I had started down that path of messing with settings and paths but ended up with a mess. It might not be as bad in the managed world though..

[sinc]

I'm not sure it's that much different.  With Civil 3D, most of the API is still not in a managed API, so most things still use the COM interops.  With C#, though, I don't have to worry about 32-bit vs. 64-bit as much as C++ programmers do, so there are pieces that are definitely simpler in C#.

All in all, I've found it to work pretty well.  It's definitely much nicer than running Civil 3D in a virtual machine.  But as you can see, it still creates some quirks to sort through.