Click here to Skip to main content
15,890,438 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
One of the other teams at work has a webserver executing some C# code. They have some other code in C++ which they compiled into an executable exe file. Using the C# code they execute the exe function in the code and pass arguments. They do have the source code for the c++ code and they didn't want to mix c++ and c# in CLR or did not know how to.

My question is whether there is any disadvantage in doing this versus including the c++ code in a CLR function and calling the code. Is there any extra memory loss etc because of calling an executable in the web server?

This particular c++ code gets called at least 200 times every 1 hour per user. I estimate that there about 100 users only for the webpage. So total of 20000 per hour.
Posted
Updated 6-May-14 18:13pm
v2
Comments
gggustafson 6-May-14 23:27pm    
Homework?
nitrous_007 6-May-14 23:52pm    
excuse me?
gggustafson 7-May-14 11:20am    
Sorry that was a comment to another question. I must be more careful. No sleight intended.
_Asif_ 7-May-14 1:20am    
What is the issue that triggered u to think alternatives? I agree with Bryce, If its working, don't change it.
nitrous_007 7-May-14 9:02am    
This is not my project but another teams. I am trying to understand why this scenario is bad from a programming perspective for an application.
Also the other team mentioned that they were having issues keeping up user demand. I am familiar with the their architecture. So that's why i am posting the question

The disadvantages of using EXE is so serious that you should avoid this option by all means. "Solution" #1 provides the worst advice. It means separate processes, and processes are highly isolated. The only benefit of using EXE is the simplicity of the use of some simple 3rd-party utilities (usually console-only) via a command line, but this is not your case.

You can have pure CLI code, or you can use native code in managed by using P/Invoke:
http://en.wikipedia.org/wiki/P/invoke[^],
http://www.xinterop.com[^].

This CodeProject article can also be useful: http://www.codeproject.com/csharp/EssentialPInvoke.asp[^].

Another option is using C++/CLI. You can create a mixed-mode project (managed+unmanaged). From the CLR standpoint, this is a regular .NET assembly which can be use normally by other assemblies. At the same time, it can contain unmanaged code which you can wrap in "ref" CLI classes to expose them to .NET.

—SA
 
Share this answer
 
Comments
nitrous_007 7-May-14 9:04am    
Hi,Does the separate processes use more memory? I am familiar with CLR and PInvoke but I would have to convince the other team to change it.
Sergey Alexandrovich Kryukov 7-May-14 9:41am    
Yes, of course, but this is not the point...

Please, deal with your team by yourself. :-)
If some people are both ignorant and stubborn, you cannot always deal with them, may consider working with some other team.

Anyway, will you accept my answer formally (green "Accept" button)?

—SA
I'd probably go the c++ exe option - because basically it works so leave it alone :)

you can probably port the c++ code to c# and call it from within your app as opposed to starting that exe, but i dunno if its worth the effort if your server is handling everything ok

If you port the exe to c# or whatever then you also have the overhead of testing to make sure you haven't stuffed anything up.

Bryce
 
Share this answer
 
Comments
nitrous_007 7-May-14 0:09am    
I dont have to port it to C#. I could call the C++ code as CLR from C#. I just need to know if its worth it.
ok - does it work?

a) yes

My choice would be to leave it alone - the theory being if it ain't broke dont fix it

Bryce
 
Share this answer
 
Comments
nitrous_007 7-May-14 17:39pm    
I agree that time, money, motivation etc are all factors. Too many hours are wasted by trying to write perfect code :)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900