Develop Reference

Loading a C# class in R 3.6.x

I have a solution that is built in Visual Studio 2019 using C# 3.5.0. I have my mother application that is coded with RStudio running R3.6.x. My objective is to use the solution (Project files are with me) and integrate with R. The input data flows from R and uses the C# code to produce the intermediate outputs.
My attempts:
1. I tried dyn.load to build the dll but it fails with "module not found" error message.
2. I did not find ".cs" as one the objects accepted by shlib cmd tool for building R loadable dll packages.
2. Tried to install rClr and it failed as there is no library for R3.6.x
So the challenge is to find an efficient way to load the COM object in R 3.6.x. Suggestions welcome.

You might want to take a look at Exporting a C# function. This will only allow c-style function calls. There are also R-Interop that uses named pipes for communication. A third way might be to use Component object model.

No module named xlsxwriter.workbook -Ironpython

I was trying to call a python code using C# ironpython. But encountering this error.
"No module named xlsxwriter.workbook"
Getting this error on import line only.
While the same code is running in that machine with regular python(version 2.7)
Please help.
from xlsxwriter.workbook import Workbook

This is happening probably because the xmlwriter library you are referring to is installed in the Python 2.7 interpreter, but not in the IronPython distribution.
You would have to download the xmlwriter package, extract it to a folder and run:
python setup.py install
using the IronPython executable - as shown in https://ironpython-test.readthedocs.io/en/latest/install/index.html.
Hope this helps!

What does IKVM actually need for a jar to run in C#?

I'm using weka for C#, and trying to port the weka.jar into c#-dll using IKVM.
The tutorial can be found here.
Now, here are what I got in my bin directory of C# program:
weka.dll --generated by IKVM
IKVM.OpenJDK.Core.dll -- from IKVM libs
JVM.dll -- from IKVM libs
and java/bin is in my PATH variable.
But the program breaks down at
weka.core.Instances insts = new weka.core.Instances(new java.io.FileReader("iris.arff"));
and the error is at initializing java.io.File
I think it is because some dll's are missing in C#/bin
I can solve it by copying every dll's related with IKVM and Java into the C#/bin directory. However it is so ugly.
Now comes my question: What runtime libraries does a Java ==IKVM==> C# program need indeed?
Update
I copied everything related into the C#/bin and it worked.
But do believe me that I dont't wanna do this.

Never without you can answer the question which parts of Java/IKVM your program need. You are the only person that know your program. A small program need approx 50% of the IKVM dlls. This is because the dependencies in Java are very large.
The minimum is IKVM.OpenJDK.Core.dll and IKVM.Runtime.dll. But I would not add dll by dll. Else I would remove it step by step. You can use the dll file names or Ilspy to see which dll do you probable does not need.
Here are some which are use rare and for which it is used. This can give you a hint:
IKVM.OpenJDK.Tools.dll - Java Compiler
*.exe - different tools
IKVM.OpenJDK.Jdbc.dll - SQL and database API
IKVM.OpenJDK.Corba.dll - Corba
IKVM.OpenJDK.Beans.dll - Plain Old Beans
ikvm-native-win32-*.dll, JVM.dll, IKVM.Runtime.JNI.dll - native stuff, if your Java code use already a dll
IKVM.OpenJDK.Naming.dll - Naming services like LDAP, DNS
IKVM.AWT.WinForms.dll, IKVM.OpenJDK.SwingAWT.dll - Images, Fonts, GUI

How to Create a python Dll file that should be used in C#.net?

I have to create a win32 python dll file which can used in C#.Net code.
And access the classes & functions present in the dll file through C#.
Is there any way to create a win32 python dll?
Please help me out....

You can compile your Python sources to a DLL with pyc.py, in the Samples directory of IronPython. However, you can't load this DLL from C# directly - you'll still need to host IronPython, but then you can reference the DLL with the IronPython engine and import from it.

Try do some investigation about Pyrex. I'm not sure if it will solve your issue, but at least I seen that some guys was trying to get it working.

You don't need any DLL, you just need to load your Python sources using IronPython

Use C# DLL as COM under Delphi

We got a DLL written by C# programmers, compiled to usable as COM object.
We consult these developers to get the function names, and syntaxes, and we can use it after we registered it with regasm.
This is ok, but we have more questions to produce faster development (on changes), and some things are not understandable or not working.
We used Delphi 6 professional, and assembly made by C# Visual Studio 2008 (as I think).
Let's see them:
1.)
I cannot use the typelib (TLB) of the C# code, because I cannot import into Delphi.
The result was:
"Hiba az OLE beállításjegyzék használata közben."
Translate ~ "Error occured on use OLE typelib/setting lib"
Possible sources of the error:
a.) Delphi 6 cannot import the new COM dll-s.
b.) We must force to C# generate an older formatted TLB.
We tried to re-generate the TLB with regasm, but we also got this error.
May this impossable, but if case b.) happens, what we need to say to C# developers - how to compile the DLL-s?
(DLL-s are unimportable by Delphi, because they don't have self init section).
2.)
Interesting:
All of the parameters correctly converted into variants vica-versa, but if the C# method does not have parameter, I got error in Delphi side...
For example (pseudo):
proc A():bool;
Calling of A is generating an error in Delphi side.
proc A(Dummy: bool):bool;
Calling of A(False) is working fine.
I don't know, why we got this.
What do you thing about this? Is this a C# compiling problem?
Thanks for your help:
dd

Best route here is to obtain source code showing the successful use of the DLL via COM using, say, C#. The developers of the DLL should be able to provide that. The DLL probably also has to be registered with regasm (not regsvr32.exe as it would be for a native COM DLL) before it will be accessible via COM. As always, without more actual code, it is very difficult to answer such questions.