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.
Related
I am running C# project which use result of python file. I'm using IronPython to run python file in visual studio. But the error above come up. Please help me. Many thanks!
Sorry you cant access third party functionalities/packages (like Pandas here)
The reason:
Pandas / numpy use great parts of c code, that is a no good for IronPython (.NET).!!!!
If you need to use the power of pandas, i suggest you to create a dialog (send/reveive datas or by file or by calling an external python prog) between your IronPython Project and a program python including pandas.
I'm trying to set up a bunch of managed C# dlls to work inside Unity3D, but I'm struggling to get that done:
Imagine having C# managed Platform.dll for platform A and Platform.dll for platform B.
Now I want to build a C# managed dll, say Core.dll, that depends on Platform.dll, but does itself not have any Platform-dependent code in it. I thought that it should be possible to build a single managed C# dll, which looks up the right Platform.dll at runtime (given that only one of the Platform.dlls is enabled).
Is this possible and if yes how? Or do I have to stick with different Core.dlls which are again platform-dependent, because the underlying Platform.dll is?
If you setup your dlls in Unity correctly (i.e. in-/exclude them for the relevant platforms), Unity should only include one Platform.dll into the build. If Core.dll doesn't use any interface that is only present in a subset of your Platform.dlls, it should work fine. Otherwise you'll get an exception when trying to build the Unity project for any platform where the respective Platform.dll is incompatible with the Core.dll.
I ran a 3rd party Android library through CodenameOne's version of IKVM and successfully imported the output .dll as a reference to my UWP app in Visual Studio. Upon trying to compile the project I get a single build error:
(from the Error List window)
Cannot find type System.ApplicationException in module CommonLanguageRuntimeLibrary
(from the Output window)
Program Files (x86)\MSBuild\Microsoft\WindowsXaml\v14.0\8.2\Microsoft.Windows.UI.Xaml.Common.targets(352,5): Xaml Internal Error error WMC9999: Cannot find type System.ApplicationException in module CommonLanguageRuntimeLibrary.
From what I've read System.ApplicationException is depreciated in .Net for UWP and instead you're supposed to just use System.Exception
I don't know how to work around and/or correct this since it's coming from a library and not my own code.
Thanks in advance.
Our port of IKVM isn't quite turn-key. IKVM is compiled using .Net 2.0, and some things (e.g. reflection stuff, some date things, threads, etc...) are factored out using interfaces that need to be included in the UWP project that uses it.
If you haven't implemented these interfaces, or you are using code paths that we don't need for CN1, then you may be embarking of parts of the JDK or IKVM runtime that use .Net 2.0 classes (e.g. this exception).
Currently there are only two interfaces that need to be implemented in your UWP project:
RuntimeReflectionHelper.
NativeThreadHelper
You can see, in the CN1 port how they are initialized here
Here are the implementations for the RuntimeReflectionHelper and NativeThreadHelper
Implementing these inside the UWP project gets around fact that IKVM is compiled for .Net 2.0, so that these implementations can use UWP APIs directly.
Even with this, you will probably run into issues. This port of IKVM is evolving along side the CN1 port, and it is really only tested for our uses cases. Some common methods may be unimplemented if we didn't require them for CN1.
Some other limitations you should be aware:
The IKVM-compiled code in a project needs to be part of a single .dll file if you want it to refer to each other. E.g. If you compile two libraries, lib1.jar and lib2.jar to lib1.dll and lib2.dll, then code from lib1 can't references classes from lib2 and vice versa. In CN1 I bundle all .class files into a single .jar before running it through IKVM so that isn't an issue for us (hence why I didn't spend much time trying to fix it).
If your goal is to publish to the Windows store, there is currently a bug in their DotNetNative toolchain that causes it to choke on synchronized methods that include try/catch blocks. This will likely be fixed by Microsoft in future releases, but I get around this by running a pre-transformation on all classes to convert all such methods into a form that is acceptable to their native toolchain. Here the part of our ANT task that applies this preprocessing. Here is the class preprocessor project for the ANT task that this uses to do the actual preprocessing.
As I said before, expect to run into difficulties if you're exploring outside the trails that have already been blazed.
I'm trying to use the Neural Network of matlab in c#.I have compiled the code to .Net Assembly then I call the matlab functions in c# ,and then I got the Exception:
... MWMCR::EvaluateFunction error ...
Error using nnetParamInfo (line 28)
FCN is not the name of a function on the MATLAB path.
the exception throwed at the line that I simply create a network:
net = elmannet();
So, I think this problem is due to the wrong path configuration of toolbox.
I tried to issue path command in Matlab and got a long list of toolbox and other things.
How can I solve this problem?
Any help will be appreicated !!
Not all of Neural Network Toolbox is supported by the deployment products, including MATLAB Builder for .NET. See the Compiler Support page for details. In particular, you can only deploy functions that apply pre-trained networks - you can't deploy the functions that create or train new ones.
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.