Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.5K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 267 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 992 SQL General
- 384 SQL Performance
- 33 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Options
Strange Automation Behavior
Fisherman
Member Posts: 456
This is very, very strange.
We have a .Net assembly (dll) that we wrote to facilitate communication of Navision order information to an XML Web Service that our customer operates. From that dll, we raise several events so that we can inform Navision of the state of the transmission, and so that we can keep the .Net assembly as "black box" as possible.
Overall, this works well, but we've just noticed some very odd behavior when it comes to raising errors out of the C/AL triggers handling the .Net events. For some reason, calling "ERROR" in the trigger actually causes a CLR error to be raised inside of the sub that raised the event. It's almost like calling the C/AL ERROR statement is injecting the error back into .Net as an exception.
We know that this is happening because our exception handler in our .Net assembly logs the general exceptions to the system event log, and changing the ERROR to a MESSAGE causes the behavior to stop.
Has anyone else experienced this? This seems like an incorrect vector to me - I don't think that calling C/AL ERROR should inject a system.exception back into my running assembly space....
We have a .Net assembly (dll) that we wrote to facilitate communication of Navision order information to an XML Web Service that our customer operates. From that dll, we raise several events so that we can inform Navision of the state of the transmission, and so that we can keep the .Net assembly as "black box" as possible.
Overall, this works well, but we've just noticed some very odd behavior when it comes to raising errors out of the C/AL triggers handling the .Net events. For some reason, calling "ERROR" in the trigger actually causes a CLR error to be raised inside of the sub that raised the event. It's almost like calling the C/AL ERROR statement is injecting the error back into .Net as an exception.
We know that this is happening because our exception handler in our .Net assembly logs the general exceptions to the system event log, and changing the ERROR to a MESSAGE causes the behavior to stop.
Has anyone else experienced this? This seems like an incorrect vector to me - I don't think that calling C/AL ERROR should inject a system.exception back into my running assembly space....
0
Comments
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
I thought you were a fellow nethead.
I'm considering reporting this to MS as erroneous behavior - your thoughts?
So Nav is probably trying to terminate the automation, or at least being nice and asking the automation to terminate itself when you throw an error.
I am not certain of this but from my standpoint this makes sense.
No one loves you like the one who created you...
I don't know - it seems odd to have the call to error inject an error into an external dll, especially when the .Net dll is catching exceptions - how does a system.exception map to a COM interface?
Generally speaking, injecting calls into a dll that weren't explicitly exposed is considered a security issue and possible vector....
2) You can try to define SingleInstance codeunit with this Automation and events to prevent automatic disposing when error...
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
yes Codemaster Kriki not nowing .NET seems to erroneous behavior to me too.
http://www.BiloBeauty.com
http://www.autismspeaks.org
I also have SQLServer programming on my list (with a higher priority), but I don't have the time for that either.
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
I'm unsure what you mean by this. NAV is not capable of instantiating the .Net framework, under which my Dll would have to run. The only thing it can do is call the appropriate class given the Class ID in the system registry, and pull the IDispatch information for COM interop with the assembly that is loaded under the .Net runtime. To say that "it becomes part of NAV" is not entirely correct - it becomes linked to NAV through IDispatch.
This is why I think that it's an incorrect vector. IDispatch shouldn't be exposing any way for NAV to raise an error inside of my dll...