I have three programs (one in C++ + WinAPI, another one in C# .NET and the last one in Java) with different functions. I am about to choose one and implement functions of the other two. Is it possible to somehow merge them? I need to have them in one GUI, under one process (at least visually). IPC isn't a problem.
Thanks for anything
I think the best/easiest thing you could do is make the GUI only in C#, in windows clients you could use Windows Forms or WPF, in web based you can use ASP.NET WebForms or ASP.NET MVC.
in all these cases except MVC (Razor) you have really good tools for designing and customizing the GUI within Visual Studio.
Your C++ code can be wrapped in a class library or as you say accessed via some kind of IPC if it has to run as application, same for Java but if you are 100% free to write and re-write things you could also imagine to port the Java code to C++, this could be easy, difficult or impossible depending on what the java code does.
at last resort if both C++ and Java applications must stay separated and must run in background on same or another machine and you still want to consume their services or methods from your C# GUI, as you mentioned, IPC is probably the way, not sure what you can do in Windows with Java and IPC, surely java can expose or consume XML web services.
The problem you will find is that each has its own process model, and you either need to get the process models to coexist or you'll need several communicating processes (though the user need not see them). With Java, eg, it can be "king", or you can set up a sort of sub-process in another process, or you can have it set up/take down its process model on every call. Which approach is best depends in part on the complexity of the operations you'll be doing in the "guest" language.
The one main thing, though, is that only one language can control the UI -- in general different language UIs don't coexist, and I doubt that you can have eg, a Java UI object in a C# GUI, at least not without treating it as a foreign window.
If you're talking about the best language to rewrite the programs in, that depends entirely on the primary function. If you mainly need it to integrate with Windows nicely, C# would be the obvious choice. If your main idea is to make it cross-platform, it'd make most sense in Java.
If you're talking about running them together and using IPC then yes, that's possible too - you could use anything from a fully blown IPC framework to a custom protocol over sockets on localhost. There shouldn't be too much of an issue there, though remember depending on how big the parts in other languages are, it may cost just as much in terms of time to rewrite them (and there's less of a maintenance burden that way too.) There's also complexities with controlling GUIs from other processes, it can be done ish by passing native canvas IDs around cross process, but it's hard to get working properly, may not be particularly safe and makes it quite difficult to work out what's going on from a maintenance perspective.
Related
First, some background:
I've decided to start a new project designed from the ground up to run on multiple platforms (Windows, iOS, OSX, Linux, Android). Since my background is mostly C++ I intend to write the core functionality using C++11. That being said, on each platform I'll need to write a platform-specific UI that can inter-operate with the C++ core.
The first platform I'm targeting is Windows (the second is iOS). I will have data stored in a SQLite database as well as user-supplied data that will be entered using a WPF DataGrid (inserting rows, manipulating existing data, etc.). This is my first time working with WPF (though I've used Windows Forms) and my first time working with C++ in a managed environment. I plan to make this an MVC-style architecture so in my mind SQLite is the Model, WPF is the View, and the C++ code is the Controller.
My question is this:
Are there any examples out there illustrating how to grab data from a C++ interface and display it using C# and WPF without destroying/mangling the C++ code itself (since it must work on multiple platforms)? I've read a tiny bit about P/Invoke (tedious, but works) and mixed assemblies (works, but will mangle my C++?) but Google hasn't been helpful when it comes to concrete examples (especially those involving populating WPF controls with data obtained via a C++ DLL).
Thanks!
EDIT: While searching for approaches to this problem I came across CXXI. I'm not very familiar with it but it seems like it may be a simple solution to my problem. Any thoughts? My grasp of all these concepts is limited.
Having worked with both XAML and WinForms, I don't think you'll find WPF to be feel much more "native" than your WinForms experience. In both cases, everything is abstracted by .Net. But if you want to learn WPF, then go for it.
P\invoke works just fine as does COM. As for other ways of getting data from C++ to other languages, consider approaching this as an IPC problem rather than a language one. Run one process as the child of the other and look at sockets and libraries such as 0mq/clrzmq (see this for 0mq on iPhone--this for Android) and Thrift to get C++ talking to the other process.
With sockets/0mq, you can use xml/json/Protobuf/Protobuf-net to serialize and deserialize objects from one language to the other. With Protobuf, you'll only need to create one set of json-esque data objects and use the langauge-specific tools for generating code. That'll take care of your data objects across platforms and languages, allowing you focus on the fun stuff. Serialization will work nicely with sql, too. All of these technologies are easy to implement and each has a score of language implementations, making it simple to wire things up to your next GUI.
In regards to examples, it all depends on how you want to move your data between the runtimes.
I have just finished my first real commercial application written in C++ / MFC.
The application consisted of agent installed on users workstations which in turn was controlled from a GUI Application on an administrators workstation. I choose C++ / MFC for these reasons.
Because I didn't know C#
Because I was not sure how long it would take for me to become as productive in a new lanuage
Because I did not want the hassle of installing the .NET runtime on workstations some of which might be W2K.
Now I am thinking of my second application which will again consist of an agent & a GUI Application. I am happy to continue on the same track with the agent for the reasons above but the GUI application will be much more complicated then the first. The first GUI app took a very long time to develop, was torturous and looked out of date even though it was freshly made.
Should I just bite the bullet with .net c# or look into something like QT.
TIA.
If you want really fast results, use .NET WinForms. Nothing beats the speed of putting together a GUI app and filling it with life, except maybe Delphi. The C# language and the .NET Base Class Library will also give you a huge productivity gain, even over the already great Qt framework. If you stick to the basic Windows Forms controls, it will even run on Mono.
WPF is even more productive once you're used to it, but getting used to it takes way more time than for Windows Forms.
.NET C# is a very good choice for GUI applications more generally. It's simple, to-the-point and there are vast resources on the internet.
The only thing against it I can think of, is platform compatibility, but if you're limiting yourself to C++/MFC, that shouldn't be a concern to you.
Even if you want to go platform-independent some time later, you can make a separate Gtk in .NET on Linux (Mono, the open-source .NET framework). Heck, there's even a Cocoa (Mac OS X) binding, I just don't know how mature it is. Furthermore Windows Forms is largely supported in Mono already... it really surprised me how mature it is when I was trying it out, although my primary experience with C# is on Windows.
For GUI application, you won't regret using C#. Even if you want to go cross-platform, and certainly not if you intend to only target Windows clients.
C# will almost definitely make you more productive!
Delphi. Produces stand-alone Windows executables which will work fine on Win2K (best OS Microsoft ever produced - this post is being written on it). Only disadvantage is Object Pascal, but if you know C++ it's very easy to pick up - and its was designed buy the guy who designed C#. The IDE is several orders of magnitude more productive than MFC with VS.
I've done them all - a monkey can use C#, it's all drag and drop interfacing and public accessors. I wouldn't wish using MFC upon my worst enemy, and QT just wasn't as intuitive as C# for me. It's also really easy to make C# look nice. Difficult things like changing colors and flashing controls are trivial in C#. It also has built in styles to use. I use it professionally daily. The only time I use C++ is if I'm programming a server where every microsecond counts.
The first question would be exactly what caused the difficulty in developing the GUI with MFC. Was it inherent to MFC, or what it because you were learning something new, and didn't really know what you were doing? To put it slightly differently, if you had to do it again today, how would the difficulty compare?
Make no mistake about it -- MFC is an old design with far more than its share of problems, shortcoming and design flaws. .NET is a lot newer, but has far more than its share of problems, shortcoming and design flaws as well.
Along with that, .NET is just plain huge. It's reasonably well organized, which helps, but it still takes quite a while to digest the sheer volume of information necessary to use it well. Likewise, while C# (for the most obvious example) is a perfectly decent language, learning to use it well isn't an overnight task either. This is probably a smaller issue though: C# doesn't really have many new concepts compared to C++. Just for example, a competent C++ programmer can easily read C# almost immediately, and while he may not use it optimally, can also write bits of C# immediately as well.
on which platform will your second app run on?
if it's XP and up i'll suggest C# / WinForms / GDI.
C# isn't that hard to adapt to, and there are literally a ton of examples online, and great books (the Head First one caught my eye as you can code a nethack clone and other fun projects). I've had to transition from C++ to C# myself, and it wasn't that rough at all (in fact it seemed like a pretty easy transition), and allowed me to rapidly prototype.
Good luck!
My friend and I are having a disagreement over an application development issue. It's a simple production management application.
According to my friend, the front-end stores data in XML, and a Java program will read the XML document, store it (at the back-end), and apply some business logic and again store the results into another XML document. And a C# front-end will display the result ( He wants to use sockets for communicating the status of XML ).
I think this is a bad idea. I suggested that whole application should either be written in C# or in Java.
Note: The application is standalone. It's not used over a network.
Have any of you tried this? Please share your thoughts :)
You're right and your friend gave a bad idea. In addition, from your question, I see there are several troubled issues, I don't know where to begin so I will just list them but not in any particular oder. But the ground rule for you to read on is you must agree that simpler is better as Einstein said "Things should be made as simple as possible but not simpler" (or something like that, I don't remember the exact quote).
The notion of front end and back end do not really apply to a desktop application. Rather, you want to use the MVC pattern for the separation of concerns. Wikipedia might be a good place to start learning or reviewing.
Why use of socket (which is totally unnecessary) if you don't have to. This is the first reason why it's a bad idea as you would not need using sockets if everything is done in language, running in the same process space (Your app is a desktop or standalone app).
Similarly, why XML (again unnecessary). No need because you can just pass Java or C# objects around. With XML, first there is the signal to noise issue as tags are added to the true data. Then there is the time to parse, to construct the XML, additional libraries potentially, etc. Thid would be all that code which are introduced in your friend's approach.
These are the most obvious reasons. There are other reasons from a manager's or company's perspective:
To maintain this application, the manager or company needs to hire 2 different skillsets. This might not be true as most programmers are multilingual anyway. But that's not always the case.
In term of deployment, now you force your users to have both the JRE and the .NET framework installed just to be able to run your application. And either of those is not exactly a small footprint.
Talk about making it complex. Either Java or C#. One really isn't a backend for another. They both 'do the same things' as languages. The only difference is whether you want to leverage the power of .NET, or the power of the immensely huge Java frameworks.
This is a desktop application that "is not used over a network"... I'm failing to see a need for a real "backend" at all.
Write the desktop application in a single language, and store your data in XML.
So your application is standalone and doesn't need to work over a network, but your friend insists on connecting the front and back ends of the app using sockets? Something is wrong with this setup, seems more complicated than it needs to be.
It sounds to me like your friend wants to use Java because he understands Java's XML handling framework better. Personally, I think interop between Java and .NET is overkill. You'll save yourself a lot of man hours and frustration by writing the app in a single language of your choice.
What your friend is suggesting is to keep things modular. It doesn't really matter what language you use, but if throw it together in one big project you might make it non modular.
For that type of app I would use one only one language.
It may be possible to leverage the power of C# desktop app on the front-end and Use Java Ejb+Web Service (Jax-ws) on the backend. C# apps can read SOAP wsdl to create the stubs and the interfaces to access Java backend implemented by Jax-ws.
This might seem like a ridiculous question since I'm quite inexperienced in .NET.
Is it possible to build components in C#, using .NET, which can be reused in ASP.NET. For example if one would like to port an application onto the web.
If possible, how portable are they? I.e. can GUI be reused in some extent? Is there an intermediate format to use as base or is it required to use C# components as binaries?
Thanks.
Edit:
Thanks for your input! I'm quite familiar with the design aspects of this problem, i.e. how to model components for reuse. However you made me realize that the question really is about - To what extent is .NET reusable between ASP and Windows? Can one say that certain packages of .NET components are independent of environment and some are platform specific?
Absolutely - a .NET class can be used in any kind of .NET application. However, it kind of depends on what part of the application you're talking about.
Generally, Windows Forms user interfaces are NOT reusable as ASP.NET user interfaces, because the design constraints are so different (i.e. web browsers only support a small number of controls, often use flow (not grid) layout, etc. Similarly, the events are different (a web form button isn't the same as a windows form button, etc.).
What you can reuse easily, though, if you do things correctly, is the business logic. Design your classes so that they don't internally know anything about whether it's a windows form or a web form (or a console application, or web service, etc.). That is, the classes should be pure implementations of your business logic. Then you can use those classes in any context you want to.
The short answer to your question is yes - simply separate out the code you want to share between the two views into a interface-independent class, preferably in a separate assembly, and include that assembly.
The long answer is more complicated - the ability to do this will vary between application and application. You'll be able to separate out less code for UI intensive applications that don't do much behind the scenes (such as, say, some sort of graphics game), than you will for a very simple UI application that does a lot behind the scenes (say, a UI that consists of a single button that then kicks off a complex data manipulation process).
In the end - .NET provides the ability for you to do this. Your actual ability to do this will be very dependent on your own design abilities and your particular requirements. There's a lot of writing available on this subject - I suggest starting by taking a look at Design Patterns (though the original book writes examples in C++, I believe that someone has done a book with examples in C#. I cannot, however, speak to the quality of it.)
I've never done it before, but i guess you can place the common code on a separated class. UI will need to be duplicated as windows forms and asp.net have completely difference programming approaches.
I have two programs. One is in C# and another one in Java.
Those programs will, most probably, always run on the same machine.
What would be the best way to let them talk to each other?
So, to clarify the problem:
This is a personal project (so professional/costly libraries are a no go).
The message volume is low, there will be about 1 to 2 messages per second.
The messages are small, a few primitive types should do the trick.
I would like to keep the complexity low.
The java application is deployed as a single jar as a plugin for another application. So the less external libraries I have to merge, the better.
I have total control over the C# application.
As said earlier, both application have to run on the same computer.
Right now, my solution would be to use sockets with some sort of csv-like format.
I am author of jni4net, open source interprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.
Kyle has the right approach in asking about the interaction. There is no "correct" answer without knowing what the usage patterns are likely to be.
Any architectural decision -- especially at this level -- is a trade-off.
You must ask yourself:
What kind of messages need to be passed between the systems?
What types of data need to be shared?
Is there an important requirement to support complex model objects or will primitives + arrays do?
what is the volume of the data?
How frequently will the interactions occur?
What is the acceptable communication latency?
Until you have an understanding of the answers, or potential answers, to those questions, it will be difficult to choose an implementation architecture. Once we know which factors are important, it will be far easier to choose the more suitable implementation candidates that reflect the requirements of the running system.
I've heard good things about IKVM, the JVM that's made with .NET.
Ice from ZeroC is a really high performance "enterprisey" interop layer that supports Java and .net amongst others. I think of it as an updated Corba - it even has its own object oriented interface definition language called Slice (like Corba's IDL, but actually quite readable).
The feature set is extensive, with far more on offer than web services, but clearly it isn't an open standard, so not a decision to make lightly. The generated code it spits out is somewhat ugly too...
I realize you're talking about programs on the same machine, but I've always liked the idea of passing messages in XML over HTTP.
Your server could be a web server that's ready to accept an XML payload. Your client can send HTTP messages with XML in the body, and receive an HTTP response with XML in it.
One reason I like this is that HTTP is such a widely used protocol that it's easy to accept or create HTTP POST or GET requests in any language (in the event that you decide to change either the client or server language in the future). HTTP and XML have been around for a while, so I think they're here to stay.
Another reason I like it is that your server could be used by other clients, too, as long as they know HTTP and XML.
I used JNBridge (http://www.jnbridge.com/jnbpro.htm) on a relatively simple project where we had a .NET client app using a relatively significant jar file full of business object logic that we didn't want to port. It worked quite nicely, but I wouldn't say we fully exercised the capabilities of JNBridge.
I am a big fan of Thrift an interoperability stack from Facebook. You said they code will probably run on the same machine so it could be overkill but you can still use it.
If they are separate programs and running as independent applications,you may use sockets. I know it's bit complex to define communication protocol but it'll be quite straight-forward.
However if you have just two separate programs but want to run them as single application, then I guess IKVM is a better approach as suggested by marxidad.
It appears a very similar question has been asked before here on stack overflow (I was searching Google for java windows shared memory):
Efficient data transfer from Java to C++ on windows
From the answer I would suggest you to investigate:
"Your fastest solution will be memory
mapping a shared segment of memory,
and them implementing a ring-buffer or
other message passing mechanism. In
C++ this is straight forward, and in
Java you have the FileChannel.map
method which makes it possible."