I have an old software development source code to transfer data from PC to and specific hardware.
This code use the method outb(value,port) to write value in the specific port. I can't use the binary files in modern operative system so, I thought make a new version with C#, porting this C code to C# code.
I'm not familiar with System.IO.Ports namespace. Someone knows how I can use a method similar to outb() in C#?¿
Thanks
Related
is there a way (other than network(i hate io-streams)) to communicate between 2 process? one in c++ and other one in C# or VB.
my problem is, im writing a AVR program using c++, but for debugging purpose i need a GUI to test different inputs. since i donno anything about GUI in c++ ( and i have no plan to learn it), i want to write the GUI using .net and somehow connect it to my c++ code.
since i have 2 running process i cant use p/invoke and other similar methods. If i could share my variables between 2 process or call a function in c# from c++ (from running process to running process), that would solve my problem.
anything other than sockets?
Since you mentioned .NET you probably on MS Windows. You may use DDE (Dynamic Data Exchange):
https://msdn.microsoft.com/en-us/library/windows/desktop/ms648774(v=vs.85).aspx
You can find .NET tutorial for it here:
http://blogs.artinsoft.net/Mrojas/archive/2009/06/10/DDE-in-NET.aspx
If you want fast dummy solution that will work for you just for debugging not as real solution. You may share your data by writing them to the hard disk and reading it from it again. It is not hard neither complicated.
What about databases? if you are using MS you can try MSSQL.
Its absolutely free for small databases i think :)
I have a problem with two projects. My main project is in C++. Another one is in C# and it is measuring current network bandwidth (updated every second). What I need to have is that C++ project can get those values.
Mt first thought was to let the C# export calculated values to .txt file. Another project could read those values. But problem is that it would mean that both would use that file at the same moment what seems to be impossible (or maybe I could synchronize it somehow?)
I was reading a lot about creating and using library, but it looks complicated to me.
Are there any other ways to do that?
Please, I need help...
The simplest way is using stdin / stdout for this purpose. Just write the values to Console from the C# program and read it from pipe in the C++ program.
Or maybe you'd like to extend your project to C++/CLI (.NET-based C++ extension) and directly reference your C# library.
As well as the other options outlined by the others, you also have the option of making the functionality of your c# code into a DLL and then calling that from your C++ code to allow you to use the functionality of the DLL to get network information. I have a how-to type link here on how to create a C# DLL. You can then reference said DLL in C++ and utilise its functionality as needed.
Hope this helps, and let me know if you need any further information:)
Is there a way for a Shared Object file written in C and built on Unix to be called from C# P/Invoke?
Or do I need to use Java or something like that?
Mono has the ability to integrate with native libraries from within C# built on top of dlopen(3). You just have to use the DllImport statement with the name of the library (i.e. 'libform.so.5'), then wrap the native code and data types with a friendly C# class that takes care of all the low-level stuff. This page has a good overview with lots of information on how to deal with marshaling pointers and other unsafe types.
Once you've got your wrapper class written, you can just use that without worrying about the fact that it's using a native shared library underneath.
I would say at the least there's likely to be no easy way, especially if you mean C# on Windows. In that case you would need something that would be able to decode the shared object and get to the code in it, sort of a re-implementation of the ABI for GNU/linux. Also, any other libraries would have to be present and usable as well, such as the C runtime library and the like. This would likely be a very significant effort.
As for doing it directly under linux/Mono, see this answer: Calling UNIX and Linux shared object file .so from c# .
You could also try to see if what open office does, http://packages.debian.org/lenny/cli-uno-bridge could be helpful; but this is more of an interface rather than directly linking the two together.
I have a solution with 2 projects:
a c++ main project
a c# project (display simulator)
Today these 2 apps share data using a loopback TCP client/server connection, but that's not very optimal (timing issues..).
I was wondering if there was a way to access the c# data from the c++ project directly and vice versa? (It seems to be possible with 2 c# projects..)
If it's not possible, what's the best way to implement this with shared memory?
thanks!
Michael
EDIT: thanks for the answers. The 2 projects used to be independant solutions and are both executables - I'm actually trying to merge the 2 into 1 solution / executable.
For info: The c++ app is a PC version of an embedded app - the c# app is a lcd/HMI simulator.
Converting the C++ project to a C++/CLI project might be the easiest way to go. Note however that some code doesn't play well with C++/CLI (we've had problems using libraries that use boost::thread in a managed executable).
You can use COM Interop or Platform Invoke to access native code in C#.
If that's not what you're asking for, please elaborate.
Named Pipes?
For interprocess communication via named pipes you can check out the .NET 3.5 feature
http://msdn.microsoft.com/en-us/library/system.io.pipes.aspx for the C# side. From the C++ side, I assume you know the equivalent :).
There are two ways I know of to get direct access to memory between c++ and c# without the overhead of marshaling/demarshaling and com. If it is required to keep the c++ part of your code native then the only way I know to achieve this is to host the clr from your c++ application. A relatively complicated undertaking. Google "hosting the common language runtime". Then you can load your c# code as an assembly, call into the c# code and provide a common shared memory style interface. Although you will have to write all of the shared memory support yourself as I have found no direct support for shared memory in c#/.net.
The other way is to compile your c++ code with common language runtime support. This is by far easier and will allow you all the power and glory of c++ while allowing access to clr based data types, and the ability to call back and forth between your c++ and c# code. See "Language Features for Targeting the CLR" in your VS2008 documentation. pin_ptr will become your close friend and ally in this process.
Like a lot of places my workplace has legacy code floating around along with more modern applications. For example we have a server application that still uses the Microsoft Fortran77 compiler. The less old parts of the application are written for the Visual Studio 6 C compiler and lately there have been runours of writing some new libraries with VS .Net 2008 C++. The programs/libraries have a number of different mechanisms to consume/communicate each other including static linking, shared memory (Windows memory mapped files), name pipes and TCP sockets.
What's to stop a C# application from being able to use any old library such as one of the Fortran77 ones written in a procedural langauge?
If my C# application understood the file format of a Fortan77 or C library and was able to locate the procedure call it wanted could it marshal the managed objects across, call the procedure and unmarshal the result?
If I copied a .so library file from Linux to Windows and my C# application understood the file format could it call functions from that library?
I think the answers are to do with the various Fortran, C etc. runtimes that are needed to initialise each library/program. If that's so then at a fundamental level are those runtimes the broadly similar to the CLR (realising they have different features such as memory management etc. etc. in the CLR's case)?
Edit:
To put my question another way. If an alien dropped in and gave me a binary library file and a file format specification could I use it from C#?
If the DLLs are valid DLLs and the functions exported use well-known calling conventions, then there should be no problem as long as you get the method signature in .NET right i.e: correct argument types and return type. CLR doesn't (and can't) care what language was the library written in.
As for the Linux shared libraries, if you have the sources of the libraries, it should be possible to compile them for windows using either Cygwin or MiniGW.
I don't know about Fortan77 or .so library from Linux, but I do know that you can use PInvoike with C libraries for method calls. Also you may want to look at the unsafe keyword in C# for the shared memory applications. It allows you to drop out of memory management, which may be what you need. Named Pipes and TCP sockets can be done from the System.Net namespace.
Basically everything you have said can be done. I don't know how hard or easy it will be to accomplish, but you should be able to access all these native apps from your C# application.
You can also create a C++/CLI DLL (/CLR option when compiling) which will allow you to write both in managed and unmanaged code. This allows you to do just about anything you could do in native C++, and also interact with .NET components. I am doing something like this to bridge an old C application with a C# DLL by having the C++/CLI dll essentially sitting between them.