.NET assemblies via ACL

[ClayHelberg]

Hi Ed-



Unfortunately, my experience (a few years old, admittedly) was that the
only we could find to do it was to write a COM wrapper around the
assembly, to make it act like a COM object you can access using the
com_* functions in ACL. (And no, I didn't do it myself, the .NET control
vendor did it for us.)



If anyone knows how to do this, it's probably Brandon...



--Clay

[ebenton]

Can anyone give me a technique/syntax for accessing .NET assemblies using ACL? I know you can use com_attach() for regular Visual Basic-type stuff, but I am looking for .NET stuff.

[berard]

I messed around with a COM wrapper as well at one point, but you need
to get crafty with how you code it in order to avoid having to
re-register the COM component every time you make a change to your
.NET code.

Ultimately, we found it easier to just work in Java, not to mention
performance at least from .NET -> Arbortext is much much slower.

I'd be interested in hearing what you decide to do.

keith

[jdreystadt]

The developers tell me that you can just use com_attach. The following
ACL



package test2;



function dotest()

{

local handle = com_attach('ClassLibrary1.ManagedClass');

local a = 5;

local b = 2;

local sum = com_call(handle, 'Add', a, b);

response("$a + $b = $sum");

com_release(handle);

}





dotest();



Should work assuming that you have something like



using System;

using System.Collections.Generic;

using System.Text;



namespace ClassLibrary1

{

// Interface declaration.

public interface ICalculator

{

int Add(int Number1, int Number2);

};



// Interface implementation.

public class ManagedClass : ICalculator

{

public int Add(int Number1, int Number2)

{

return Number1 + Number2;

}

}



public class Class1

{

}

}



For your C#.



John Dreystadt
Software Development Director
Arbortext - PTC
734-352-2835
-

[dugald]

That's riht. We have a set of .Net objects some written in C# and
some in VB.Net and we build a single DLL to house them all then create
an msi to install this library. We use ACL to check that the user has
the most recent version of the DLL installed and if not then we can
run a silent install by calling msiexec from the system function in
ACL. Once the most recent version of the DLL is installed on the end
user's machine we simply make calls to its objects with com_attach and
have access to all the objects in the DLL (we have more than 11 of
them at last count that do all sorts of different things). The system
works for us because we use functions written in ACL to verify that
everyone is working with the latest copy of our .Net code.

I can provide more details if you're interested,

Dugald

Quoting "Dreystadt, John" <->:

> The developers tell me that you can just use com_attach. The following
> ACL
>
>
>
> John Dreystadt
> Software Development Director
> Arbortext - PTC
> 734-352-2835
> -
>

[ebenton]

Question relayed to me from a co-worker:


"Any idea how to get an "element" out of ACL? As in, a data object that I can pass to VB into an MSXML IXMLDOMElement object? I have an "OID" object referencing part of a document that I can use to get all sorts of interesting info like content, tag name, etc., but I can't seem to make a successful call to a VB COM object that expects a IXMLDOMElement data object.



This is probably a real "newbie" question, but that's where I'm at now."

[ClayHelberg]

Hi Ed-



I think Acl.DOMOID(oid) is what you want.



--Clay

[jdreystadt]

The question is being asked the wrong way around. Pass the OID as a
string to the COM side of the world and then call Acl.DOMOID(oidString).




John Dreystadt
Software Development Director
Arbortext - PTC
734-352-2835
-

[ebenton]

Based upon what I am being told by our developers, DOMOID returns an Arbortext IDOMNode, rather than an "MSXML" IXMLDOMNode (or IXMLDOMElement), so you'll get an error when trying to pass it to the object that wants an MSXML object, which is what is need here, I think.

Any thoughts on this, anyone?

[jdreystadt]

Ah, I did not read your message closely enough. All the different XML
parsers have different implementations underneath, so while you can get
DOM nodes from our software, they are not MSXML DOM nodes because we
have our own parser and DOM model underneath. If you can give some
background on what you are trying to do generally, people on this list
might be able to provide alternative suggestions but as stated, other
than walking the entire document from the Arbortext DOM nodes and insert
them into new nodes built by MSXML, there is no way to do exactly what
you are asking.



John Dreystadt
Software Development Director
Arbortext - PTC
734-352-2835
-