Writing a .NET dll that Jade can use

[justin]

I am trying to write a DLL in C#.NET that Jade can use (External Function or the like) but I can't seem to get it to work, and cannot find anything in the Jade docs about. All the Jade docs seem to be the other way round (i.e. Using .NET and calling Jade).
I can get it as far as actually reading the DLL but fails and comes back with 'function not found in assembly'? At this stage I just want to call one method in the .NET assembly, not sure if it should be an instance object or a static for Jade?

Anyone have an experience with this?

[JohnP]

Are you importing the .Net assembly? This is done with Browse>External Component Libraries. See Maintaining .NET Objects in UserGuide.pdf.

[justin]

Yeah I think the issue I was having was thinking that .NET was an External Function or External Method call, I didn't realize that Jade actually imports them. I eventually came across the same doc, just going to give it a whirl now but looks straight forward.

Cheers

[justin]

OK, now I've got an interesting situation. The server that I would like to get the .NET assembly imported into,does not have .NET framework installed. Jade throws a bit of a harsh error, would have been nice if it just said .NET framework not installed as it took me a little bit to figure out what was going on.

Now I have since installed .NET, but I am still getting the same error.

Any idea as to how refresh jade to now see the .NET framework?

Its a server so doing a restart may be difficult

[BeeJay]

For importing .Net dlls, I normally use one of the following two approaches:

1. Use a local copy of the target system to do the import. Then use the extract option on the External Components Browser to extract the component definition to a schema file. Finally, us my normal thin client connection to load the extract into the main development environment.

2. Run a standard client connection, often called a "fat client" connection, instead of a thin client connection on my local machine to do the import into the main development environment.

Both approaches avoid any issues with missing libraries etc on the server machine if this component is only ever going to be used on the thin client machines. If you're going to use the component on the server itself, then you do need to get all the additional dependencies for .Net installed on the server anyway so it's worth persevering with getting everything installed onto the server. I normally use approach #1 as I nearly always have a recent enough local copy of the development environment on my own local machine.

Hope that helps,
BeeJay.