I am making a function in C# that takes C# code as a string, and compiles it into an EXE file and then can pass info to the EXE when executed. Is there a way that I can compile code in C# (from C#) without making a compiler for C#?
Certainly is possible, check out https://learn.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.csharp.csharpcompilation.create?view=roslyn-dotnet. You can create the syntax tree from your code using the syntax parser (https://learn.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.csharp.syntaxfactory.parsesyntaxtree?view=roslyn-dotnet).
Related
I am beginner in using SCIP. I want to solve a simple MILP written in C++. I developed a simple makefile to compile and run my model but I realized there many nested header files when you call SCIP. I was wondering there might be a sample makefile to solve MILPin C++ using SCIP.
Thanks
You can use a makefile from one of the SCIP examples, e.g. scip/examples/TSP/Makefile. The C++ files of your project should be then added to the MAINOBJ variable.
I have a body of 'normal' C++ code which I'm trying to make usable by a C# client. I have successfully compiled this with /CLR. I now know that this isn't enough: I have to introduce managed wrapper classes ("ref") to make the code callable from managed code. This question is about what happened before I introduced the ref classes.
I found that the native C++ classes were visible from the C# project, and that I could write
MyNativeClass mnc = new MyNativeClass();
... although any attempt to call a method on the instance was rejected by the compiler. I found that when I ran the C# code, the MyNativeClass constructor was never called - indeed the attempt to instantiate mnc seemed to produce no code at all, so completed without error.
How was C# interpreting the native types in my project? Why did the compiler apparently allow me to instantiate an instance? Why were methods treated differently to the types themselves?
You made two mistakes to make this code work. First is that you declared the C++ class public, like this:
public class MyNativeClass {};
This is not syntax that makes sense in C++ but it is allowed by the C++/CLI compiler. Omitting public would have produced an error message in your C# code, CS0122: "Foo is inaccessible due to its protection level".
Second mistake is that you compiled your native C++ class with /clr in effect. Which works fine, any C++03 compliant code can be compiled to IL and gets just-in-time compiled to machine code by the jitter, just like managed code. And executes fine as well. It is however not efficient to do so, you lost the advantage of having the compile-time optimizer available to produce the best possible code. It still gets optimized, but now by the jitter which doesn't have the same luxury of time available to do as good a job as the C++ code optimizer can do. You avoid this by moving the C++ code in a separate source code file so you can compile it without /clr in effect. Or by using #pragma managed in your source code.
Anyhoo, what you ended up with was an assembly that indeed contains a declaration for MyNativeClass that any managed compiler can see. Something you can see for yourself by running ildasm.exe on the assembly. You'll see that it gets embedded as a value type type. Just a blob of bytes with no constructor and no methods. Which is a decent match for a C++ object from a managed point of view, just bytes that can be stored anywhere a value type can be stored. Declaring a variable of that type in C# works but doesn't do anything useful, it just creates the blob with all bytes set to 0. The only possible use of this declaration is that you can declare a typed pointer to the class and pass it around, that's all.
I can't seem to understand how it works.
I see there is an option /assembly available to the Script# compiler which procuces a .dll file with the .js file as a resource. Here is an example from http://www.nikhilk.net/ScriptSharpIntro.aspx:
ssc /ref:sscorlib.dll /ref:Script.ScriptFX.Core.dll /debug /assembly:HelloWorld.dll /out:HelloWorld.js HelloWorld.cs
Can I get the same result using Script# Visual Studio templates? How do I enable this option for my Script# project?
There isn't a way to produce an assembly with script embedded in it.
I think the /assembly flag might be a remnant, or is there primarily for the script# compiler to know where the assembly produced from the same code as produced by the c# compiler exists.
If you want to embed the script in that assembly, you'll need to do a two pass c# build - in pass 1, there is a placeholder script, and then in pass 2, the real generated script.
Alternatively I can think of some approaches involving ildasm, add script resource reference, and then ilasm'ing to get back a new assembly.
What is your scenario? I am curious. I've debated whether to make the two pass build be supported out of the box... but never gotten around to it, since the embedding a script was a nice-to-have.
I am using T4 for generating code. With Visual Studio I could generate code in C# or VB. What is required for generating code in Ruby or Java ?
I have a some utility classes that is required in multiple language (C#, Ruby and Java). I am looking for defining T4 templates...
Thanks
With a standard T4 template, you can generate any code, but what comes out is part of your project. While you can generate any kind of text, this is really most useful if you're compiling the code that comes out.
With VS2010, you can now use a T4 PreProcessed Template. Instead of generating a text file, you generate the generator. Making the generator instead of the resulting code should give you lots of flexibility with integrating your Java/Ruby output.
Anything can come out of the generator, but I think you still have to write the actual T4 code in VB or C#.
You can generate code in any language using T4 or indeed any other textual artifact.
You just need to start with an example of what you want to generate and begin to parameterize it.
Only the code generation control code inside the template needs to be in C# or VB.
I'm creating a package that is going to be used by R (the statistical program), I'm not an expert using this application but I have managed to create a very simple package, using the following logic, I have some classes in C++, as the code has to be compiled using the R compiler and it only allows C code, I have a wrapper C code that call the C++ methods, and later I have an R script that call the methods exposed by the C code, so basically is a communication like R <-> C<->C++.
The full tutorial that I used to create this package is found here, I add it as a reference.
Now my problem is that I need to add some functionality to the package that I already created, what I need to do is to add code for late binding to a COM object which is another product that I created and that is registered using regasm tool.
This is the c++ code that I'm using to try to late bind to the COM object, I'm trying to use IDispatch to do so:
{
...
CLSID clsid;
HRESULT hr = CLSIDFromProgID((WCHAR*)"My Com object ProgId", &clsid);
if(FAILED(hr))
return;
...
}
I didn't paste the whole code because only with these lines the compiler is giving me troubles already, the command I use to compile is
R CMD SHLIB Cclass.cc C++class.cc
Where "Cclass.cc" has the C code that call the c++ methods and "C++class.cc" is actually the C++ code.
When I compile these classes the compiler says "undefined reference to `CLSIDFromProgID#8'collect2: ld returned 1 exit status"
I"m sure I have added all the header files that I need, that's why I believe my problem is that I'm not including ole32.lib and oleaut32.lib which are static libraries.
So, my question is, how can I include this libraries in order to be able to use the methods for late binding, like CLSIDFromProgID(...) or QueryInterface(...). Also if anyone believes that my problem is not linking this libraries, but something else, it would be great if can point me to which my problem may be.
Also have in mind that I need to link with those statics libraries in a way that they can be compiled without problem by the R compiler, which if I'm not wrong is a merely c compiler.
I've not tried doing this with C/C++ but rather with Fortran. I had a similar problem in that some standard IO libraries weren't being included in the library I was created. In the end I just included them all and compiled using the Fortran compiler. I didn't use any of the R compiler utilities, just compiled as if I were compiling a static Fortran library normally for use with anything else. This worked fine.
A debug path might be to compile as a static library using gcc (or whatever you're using) then try to include and call that static library from another C program, then if that works try with R.
Hope this is helpful, writing these R packages is pretty hard unless you're using vanilla C or Fortran as far as I can tell.