Managed C++ server side executables ?
-
Hi all Is it possible to run MC++ apps from (for example) a C# .NET web application ? I'll be checking with the host but was wondering if anyone else had done this or similiar. BTW the app in question 'brands' .EXE files for registered customers and I'd prefer not to port the existing code to C# etc. TIA Jerry
-
Hi all Is it possible to run MC++ apps from (for example) a C# .NET web application ? I'll be checking with the host but was wondering if anyone else had done this or similiar. BTW the app in question 'brands' .EXE files for registered customers and I'd prefer not to port the existing code to C# etc. TIA Jerry
-
Why do u wanna run it as an app? Just load it as an assembly reference! :) leppie::AllocCPArticle("Zee blog");
Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.Go on. Gimme a bit more detail :-))
-
Go on. Gimme a bit more detail :-))
One of the major benefits of Microsoft® .NET is that it provides a language-independent development system. You can write classes in Visual Basic®, C++, C#—whatever—and use them in other languages; you can even derive from classes in a different language. But what happens when you want to call some old-school unmanaged DLL? You have to somehow translate .NET objects into the structs, char*'s, and function pointers C expects. In techno lingo, your parameters must be marshaled. Marshaling is a big topic, but luckily you don't have to know much to get the job done. To call a DLL function from C#, first you must provide a declaration, something programmers using Visual Basic have been doing for years. In C#, it's DllImport: using System.Runtime.InteropServices; // DllImport public class Win32 { [DllImport("User32.Dll")] public static extern void SetWindowText(int h, String s); } In C#, you use DllImport to tell the compiler where the entry point lives and bundle your wrapper functions inside a class. You can give this class any name you like; I chose Win32. You can even put the class inside a namespace. To compile Win32API.cs, type: csc /t:library /out:Win32API.dll Win32API.cs Now you have a Win32API.dll you can use in any C# project. using Win32API; int hwnd = // get it... String s = "I'm so cute." Win32.SetWindowText(hwnd, s); Practice sesquipedalianism! ;)
-
Go on. Gimme a bit more detail :-))
The .NET Framework includes the base class library (BCL) and the common language runtime (CLR). The CLR just-in-time compiles (jit's) intermediate language (IL, or more specifically MSIL) and executes it. Languages that target the CLR (MC++, C#, VB.NET, J#, PERL.NET, etc.) compile to IL in the form of assemblies, which are executable files (.exe, .dll) that contain 0 or more modules (compiled code), 0 or more embedded resources, various assembly attributes, and a manifest (like a plane or boat passenger manifest) of all that stuff in the assembly. So, it doesn't matter which language you use they all compile to assemblies using IL. Make yourself a Managed DLL project for MC++ and puts some classes into it. Make a Windows Forms application (or something) in C#. If both of these projects are in VS.NET in a single solution, right-click on the Windows Forms project and click Add Reference. Click the Project tab and select your other project. Otherwise, click the .NET tab and browse for the MC++ assembly. Use classes from the MC++ assembly and compile your app. Viola'! This is - in essence - no different from library bindings in Win32 or any other programming platform. It's all in the docs! Consider yourself educated - now go out and read the docs to further your education! :rolleyes:
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
One of the major benefits of Microsoft® .NET is that it provides a language-independent development system. You can write classes in Visual Basic®, C++, C#—whatever—and use them in other languages; you can even derive from classes in a different language. But what happens when you want to call some old-school unmanaged DLL? You have to somehow translate .NET objects into the structs, char*'s, and function pointers C expects. In techno lingo, your parameters must be marshaled. Marshaling is a big topic, but luckily you don't have to know much to get the job done. To call a DLL function from C#, first you must provide a declaration, something programmers using Visual Basic have been doing for years. In C#, it's DllImport: using System.Runtime.InteropServices; // DllImport public class Win32 { [DllImport("User32.Dll")] public static extern void SetWindowText(int h, String s); } In C#, you use DllImport to tell the compiler where the entry point lives and bundle your wrapper functions inside a class. You can give this class any name you like; I chose Win32. You can even put the class inside a namespace. To compile Win32API.cs, type: csc /t:library /out:Win32API.dll Win32API.cs Now you have a Win32API.dll you can use in any C# project. using Win32API; int hwnd = // get it... String s = "I'm so cute." Win32.SetWindowText(hwnd, s); Practice sesquipedalianism! ;)
Indeed and Thanks. My question was obviously not well phrased. Given that I have a working VC++ console app I could compile it for IL instead of native code. Would this package then run on a remotely hosted .NET server along with my Web Service ? Would this be true for an unmanaged (but still compiled to IL) DLL ? I am all too familiar with marshalling etc :-)) And I must confess that I took the plunge and wrote an analogue in C# on the grounds that it would have to be done one day ! Jerry
-
The .NET Framework includes the base class library (BCL) and the common language runtime (CLR). The CLR just-in-time compiles (jit's) intermediate language (IL, or more specifically MSIL) and executes it. Languages that target the CLR (MC++, C#, VB.NET, J#, PERL.NET, etc.) compile to IL in the form of assemblies, which are executable files (.exe, .dll) that contain 0 or more modules (compiled code), 0 or more embedded resources, various assembly attributes, and a manifest (like a plane or boat passenger manifest) of all that stuff in the assembly. So, it doesn't matter which language you use they all compile to assemblies using IL. Make yourself a Managed DLL project for MC++ and puts some classes into it. Make a Windows Forms application (or something) in C#. If both of these projects are in VS.NET in a single solution, right-click on the Windows Forms project and click Add Reference. Click the Project tab and select your other project. Otherwise, click the .NET tab and browse for the MC++ assembly. Use classes from the MC++ assembly and compile your app. Viola'! This is - in essence - no different from library bindings in Win32 or any other programming platform. It's all in the docs! Consider yourself educated - now go out and read the docs to further your education! :rolleyes:
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
Thanks Heath. PLease see my reply to the previous post. Jerry
-
Indeed and Thanks. My question was obviously not well phrased. Given that I have a working VC++ console app I could compile it for IL instead of native code. Would this package then run on a remotely hosted .NET server along with my Web Service ? Would this be true for an unmanaged (but still compiled to IL) DLL ? I am all too familiar with marshalling etc :-)) And I must confess that I took the plunge and wrote an analogue in C# on the grounds that it would have to be done one day ! Jerry
Just because something is written "in .NET" doesn't make it remotable. It has to extend
MarshalByObjectRefor be a value type and be serializable (in most cases, attributed withSerializableAttribute). Something has to host the remote object, too. For instance, just having a console app won't work. Now, a console app that registers a well-known object (WKO) either via code or a config file (latter is preferable for easy changes) and keeps itself running (waits for a quit command of sorts) would work. Clients would connect to that WKO. The documentation about .NET remoting is okay, at least if you already have some idea of what it does. If you don't, I suggest you get the book from MSPress entitled .NET Remoting (at www.microsoft.com/mspress/books/6172.asp).-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
Just because something is written "in .NET" doesn't make it remotable. It has to extend
MarshalByObjectRefor be a value type and be serializable (in most cases, attributed withSerializableAttribute). Something has to host the remote object, too. For instance, just having a console app won't work. Now, a console app that registers a well-known object (WKO) either via code or a config file (latter is preferable for easy changes) and keeps itself running (waits for a quit command of sorts) would work. Clients would connect to that WKO. The documentation about .NET remoting is okay, at least if you already have some idea of what it does. If you don't, I suggest you get the book from MSPress entitled .NET Remoting (at www.microsoft.com/mspress/books/6172.asp).-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
Sure but I was not asking about remoting. Can a .NET service invoke (using the Process class) a process written in unmanaged C++ but compiled to IL rather than native code ? Jerry
-
Sure but I was not asking about remoting. Can a .NET service invoke (using the Process class) a process written in unmanaged C++ but compiled to IL rather than native code ? Jerry
The
Processclass can start any process executable, regardless of how it compiled (i.e., it doesn't matter if it is a VB executable, unmanaged C++, managed C++ or other from any other languages targeting the CLR, compiled PERL exectable, etc.). Also, any C++ application compiled to IL is managed (save the purely native functions). You can't compiled to IL and have an unmanaged executable.-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----