C# Add-in access Interop Application/Methods

HI Viktor,

Viktor_Kulik said:

With that, I understand i shouldn't be using GetObject as that will give me out-of-process instance of the Application,

Exactly

Viktor_Kulik said:

but is there a .NET or other api that will give me access to the interop Application?

Utilities.ComApp.<whatever>

Viktor_Kulik said:

and was looking to do some benchmarking and comparing of the interop vs the .net API performance for doing basic scanning/processing/updating elements.

I have several comments to this topic:

• It makes sense (I did couple of such measurements in the past), but good enough rule is Interop tends to be slower than NET API, because there are more layers between "end point" and public API. But it is not simple to evaluate the results, because API and object model is completely different.
• Especially in scanning, the biggest difference is not in used API (NET vs Interop), but in used approach/class (iteration, delegate, Interop scanning), where the fastest is (no surprise there) direct iteration using NET enumeration. And my experience is that 90% of performance issue is not in API at all, but in wrong code, wring algorithms and software + application architecture ;-)
• Strictly said, it is impossible to do correct benchmarking on top of so complex hosting application like MicroStation. Unfortunately, it is easy to obtain "some numbers" and think they are valid.

Viktor_Kulik said:

comparing of the interop vs the .net API

I think the rule here is not performance, but existing vs new code and APIs incompatibility:

• For new code, use new NET API everywhere is possible (fortunately there are only a few exception like the discussed cell modification).
• When there is bug or missing functionality in NET, decide what is better: To use Interop (also buggy, but known and it typically works fine, where NET not) or to use C++/CLI to call C++ API. To use Interop is simple, but APIs cannot be mixed freely (especially Interop Element is not NET Element). whereas C++/CLI is efficient, powerfull, but requires extra skills and lead to more complex code and application structure (separate assembly for C++/CLI wrappers).
• When there is existing code, use it, when cost and time are priorities.

With regards,

  Jan

Jan Šlegr said:

especially Interop Element is not NET Element

Correct. But we have an article(sorry it is in Chinese) to describe how to convert between these two kinds of elements as below:

新老Element的相互转换

Certainly it is somewhat complicated.

Hi Jongan, any examples to convert an element in a reference?

Hi Mark,

Mark Shamoun said:

any examples to convert an element in a reference?

I did not test the code with referenced elements, but it looks to me like general solution, so there should be no problem with references.

Is you question general or you experienced any problem?

With regards,

  Jan

I am having issues with Items.Find when the element is in a reference and has been converted from a NET element to an interop element. I was initially convinced some element data was not getting converted but it is looking like an Item Type issue. I will start another thread if i dont get to the bottom of it.

Hi Mark,

I agree it's probably too far from the original discussion that to start a new one makes sense, but anyway,,, ;-)

Mark Shamoun said:

when the element is in a reference and has been converted from a NET element to an interop element.

Why to do anything like this? The conversion between Interop and NET is quite rare requirement, and is typically done when Interop functionality is missing in NET (e.g. like still no way how to place cell from cell library in NET).

Mark Shamoun said:

I am having issues with Items.Find

EC API in NET is far more powerful (in fact, it is one from the best part of NET API, because EC was designed using some ideas from NET and EC was implemented at first in NET). So why to convert  the element to use limited Item API with them in Interop?

Mark Shamoun said:

but it is looking like an Item Type issue.

I do not think so. The whole conversation is about to convert "a handle to element in memory", but nothing else. And EC data (items) are "the else", because they are not stored with element, but in parallel, when there is a link between element and EC data.

So I guess the element is "transformed" between NET and Interop right, but EC data are not loaded, because they are covered by the conversion.

With regards,

  Jan

Hi Mark,

I agree it's probably too far from the original discussion that to start a new one makes sense, but anyway,,, ;-)

Mark Shamoun said:

when the element is in a reference and has been converted from a NET element to an interop element.

Why to do anything like this? The conversion between Interop and NET is quite rare requirement, and is typically done when Interop functionality is missing in NET (e.g. like still no way how to place cell from cell library in NET).

Mark Shamoun said:

I am having issues with Items.Find

EC API in NET is far more powerful (in fact, it is one from the best part of NET API, because EC was designed using some ideas from NET and EC was implemented at first in NET). So why to convert  the element to use limited Item API with them in Interop?

Mark Shamoun said:

but it is looking like an Item Type issue.

I do not think so. The whole conversation is about to convert "a handle to element in memory", but nothing else. And EC data (items) are "the else", because they are not stored with element, but in parallel, when there is a link between element and EC data.

So I guess the element is "transformed" between NET and Interop right, but EC data are not loaded, because they are covered by the conversion.

With regards,

  Jan