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

Some custom commands no longer recognized, why?

7 REPLIES 7
SOLVED
Reply
Message 1 of 8
Jeff_M
471 Views, 7 Replies

Some custom commands no longer recognized, why?

I have a rather large toolset comprised of 4 projects, 3 of which have helper classes, and one that has all the commands defined with CommandMethod(). There are close to 300 such commands, most are in their own classes. As of sometime last week about 10% of the commands are now getting the "Unknown Command" when executed. All but 1 of the commands that are not recognized have not been edited in years. I have separate builds for the versions of Civil 3D (2020, 2021, 2022, etc.) and every one of them has the same issue, with the same commands. This also affects both Debug and Release builds.

 

I have a command in the same project to get a list of all the commands in that assembly. It correctly finds all of them, including those that AutoCAD does not. What could AutoCAD be seeing which stops it from recognizing some commands? 

Jeff_M, also a frequent Swamper
EESignature
7 REPLIES 7
Message 2 of 8
_gile
in reply to: Jeff_M

Hi,

Could it be a CommandClassAttribute issue?

If a class containing CommandMethods is decored with the CommandClassAttribute, then all classes containing CommandMethods must be decored with the CommandClassAttribute



Gilles Chanteau
Programmation AutoCAD LISP/.NET
GileCAD
GitHub

Message 3 of 8
Jeff_M
in reply to: _gile

Thanks for the suggestion, @_gile . No, there are no CommandClassAttributes in the project.

Jeff_M, also a frequent Swamper
EESignature
Message 4 of 8
ActivistInvestor
in reply to: Jeff_M

If some, but not all commands from the same assembly are not recognized, it would suggest that there's an exception being thrown in the ProcessAssembly() API that does the registration of the commands. If the exception is thrown after some of the commands are registered, then those that haven't been registered won't be.

 

Long ago, I wrote a diagnostic tool that replaces Autodesk's AssemblyLoad handler with a surrogate to diagnose this type of problem. It might help identify the issue.

 

Update: That file is no longer available at the above link, but I'll try to find a local copy of it.

 

Message 5 of 8
Jeff_M
in reply to: ActivistInvestor

@ActivistInvestor Thanks for that link back to the Swamp. Not sure how my search there for this issue didn't turn that up. The link in the first post there did give me the old (2012) zip file. Will be checking it out momentarily.

Jeff_M, also a frequent Swamper
EESignature
Message 6 of 8
Jeff_M
in reply to: ActivistInvestor

I actually found the edited one for 2013 that Jeff H posted there. Making the minor change to .NET Framework 4.8 and changing the reference paths to find AutoCAD 2023 and it runs well. I had great hopes! However, there are classes showing as loading successfully with commands that are not recognized. Also, it is only displaying 173 as successfully loaded (I added a counter and also output to a text file), but there are many more than that (267) which have commands defined.  This is what a search for CommandMethod using  the FindNReplace tool: 

Jeff_M_0-1725329525589.png

 

Jeff_M, also a frequent Swamper
EESignature
Message 7 of 8
ActivistInvestor
in reply to: Jeff_M

Trying to remember ~12 years back, I think the problem is that MYNETLOAD is only looking for non-static types that have non-static  CommandMethods, because it tests creation of instances of those types. It shouldn't be too hard to build a similar tool that grabs all CommandMethods, including static ones. I'll take a look at it to see if there's an easy fix.

 

My guess on this whole thing, is that there's an exception being thrown in the process that registers CommandMethods, and the ones that were defined are those that were processed before the exception was thrown. That's the only possible explanation I can come up with for why some CommandMethods are defined, while others are not.

 

Of course, because the managed runtime suppresses exceptions, we can't find them.

 

You could try handling the AppDomain.FirstChanceException Event, which should be fired before any exception handler currently on the stack gets it.

Message 8 of 8
Jeff_M
in reply to: ActivistInvestor

@ActivistInvestor  Thanks for the help, Tony. It turns out, as usual, that I am an idiot.

 

I'm converting many WinForms to WPF. One of them I was working on last week is fairly complex so, rather than try to call one or the other depending on Debug vs Release I copied the class to a new cs file, renamed the class and Command, and all seemed well...until it wasn't and I spent the last 4+ days trying to track down the loss of commands. I finally did a search in VS for CommandMethod and started scrolling through the results looking for something that stood out. When I got to the 2 classes for the form/wpf code I had copied, I found the error. There were 2 other commands defined at the end of the class which I hadn't noticed (mainly because they were added years ago by someone else for testing which I had never used). This meant that there were 2 duplicate command names which is what was stopping AutoCAD from processing past them. Commenting them out of the copied class fixed the issue.

 

Lesson learned, when you think there is likely a name conflict then do a better job of looking for that conflict before spending countless hours chasing the wrong things.

 

Thanks again for trying to help me out.

Jeff_M, also a frequent Swamper
EESignature

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

Post to forums  

AutoCAD Inside the Factory


Autodesk Design & Make Report