Develop Reference

Can C# Mono create tunnel interfaces multiplatform?

I haven't been able to find a solution answer on this for the past 2 days:
Can C# Mono, or a supported third party framework, be used to create and manage layer 2 tunnel over a virtual interface across the 3 major platforms (OSX, Windows, Linux)?
At a high-level an application like Hamachi or Tunngle would be a real world example for what I'd like to achieve at a basic level.
The intention behind this question is whether it would be possible to write effective cross-platform code or whether I would have to resort to platform-specific code to implement the virtual interfaces.

That depends. Since L2TP is actually accomplished using UDP datagrams, there's no reason why you can't implement it in C#. However, integrating it with the operating system (as a virtual interface driver etc.) is more or less impossible - I'd expect the only real way would be to have a small native wrapper that calls the managed code that does most of the work.
In other words - you can write Hamachi in .NET just fine. Writing the Hamachi Network Adapter is the tricky part. Also, if you just want to add L2TP capabilities to your applications, there's no problem (instead of TcpClient/UdpClient etc., you'd just use your own class that communicates with your L2TP class). However, integrating it to the IP infrastructure does require you to write a driver, which is usually a native-only territory.
It might be that there are some ready-to-use solutions that have the virtual network adapter which can call DLLs, but I'm not aware of any. A very unsafe way would also be to create hooks on Socket calls, but I'm not going to elaborate since that's extremely tricky and a bad idea overall :D
In other words, you have the option to use a hybrid approach - have the minimal native drivers for all the platforms you want to support, and let them call your managed library to do all the real work - the managed library can then be platform independent (as long as Mono is supported there :)).
Now, each OS probably has its own VPN client, which you could concievably use from .NET. However, that also means that your application will have to be able to support each of these OSes and their different VPN clients separately - and that will be tricky.
If you want to go the way of writing your own network interface driver, a good way to start on Windows is the Driver Development Kit, which has some sample source code for NIC drivers. Windows uses NDI (http://en.wikipedia.org/wiki/Network_Driver_Interface_Specification), which has some support even on *nix family of OSes, so it might be possible to do this relatively easily - but don't forget, you're still writing a driver. Unless you have significant experience with C/C++/ASM and OS kernels and driver models, you're probably out of your league here. This is the stuff that leads to BSODs :)
There's also some related technologies like TDI (Transport Driver Interface) or WFP (Windows Filtering Platform) which could be used to do all this in user-space, rather than kernel/driver-space. However, those are Windows technologies. You'll have to find the equivalents on the other OSes you want to support, and you'll have to do some magic to make it all work in one cross-platform application. And while doing all this, you want to maintain performance - which requires very careful programming in .NET (it's easy to write reliable code in .NET, but it's harder to get cutting-edge performance. C/C++/ASM is quite the opposite - it's relatively easy to do things fast, but reliability suffers).

Run C# code from Java and vice-versa

I have a game server which is made in Java. I want to make a plugin system that loads a .NET DLL and calls events / functions inside that DLL, then inside those I'll have to call functions in the game server (Java). The only part that is giving me trouble at the moment is how to interface java and a .NET dll.
I've been searching and found some things but they were all based on products and I want to make my own interface for that. Ah, not to mention it needs to have high performance, the code will be called a lot of times in a second if it has to. Could someone point or give-me ideas how could I work this out?
EDIT:
To make it more explicit:
Game Server (Java application) calls a function in .NET dll
The .NET function just called by java, calls multiple functions from Game Server (Java Application).

Take a look at jni4net if you're targeting Windows. It's an alpha quality release, but Robocode already uses it to run .NET robots inside the Java runtime.
Another option is to use a high-performance messaging approach. You'll need a second process - likely a .NET plug-in host. That process then exchanges messages with the main Java game process. Messaging libraries like 0MQ are pretty darn fast but may not be fast enough for what you have in mind. In addition, you'll have to create a lot of message plumbing which may be cost/time prohibitive.

Try using iKVM:
IKVM.NET is an implementation of Java for Mono and the Microsoft .NET
Framework. It includes the following components:
A Java Virtual Machine implemented in .NET
A .NET implementation of the Java class libraries Tools that enable Java and .NET
interoperability
http://www.ikvm.net/

If you only have a few methods you are calling you might just use JNI and do it yourself instead of a 3rd Party tool (though I admit I don't know the details of jni4net). Just a word of caution, the project I'm on had to do a similar thing (C# -> C/C++ -> Java via JNI) and we had nothing but problems with it. Problems mainly because the java api didn't have any good documentation so that might have been part of it. If at all possible try to keep it to one language but if that is not possible, make sure you do lots of error checking. When the app crashes, it is very hard to find the problem (unless you own both the java and C# sutff). Just my $0.02...

Windows Mobile development: C++ or C# -- which one is better? why?

While doing Windows Mobile development, which language should I use? C# or C++ or something else? Why one is better than others?

It depends what you're coding.
Making native calls to the OS are possible via P/Invoke from C#, but extensive use is probably easier via native C++. You'll also require C++ for using some hardware that has not been wrapped by the Compact Framework.
Most hardware (GPS, camera, etc.), is available via CF. If you're working with a Win Mobile 6.x device, you're probably better off with C#. In addition to hardware, Pocket Office's (POOM) object model is also available to C#, so you can integrate with it.
It's worth noting that most references to Windows Phone 7 refer to managed code and the possibility of Silverlight. With Silverlight in the mix, you'll have to code with C#.
Unless your app is high performance or is extremely miserly with memory, use C# or VB.NET.
Scott

It depends on task mainly.
c++ has following pros/cons:
Direct access to resources, faster programs
Can access very deep OS parts, not needed for high level applicaiton
harder to develop and requires to manage resources by developer
C#:
Runs under virtual machine (CLR), that's why is slower
Faster and easier application development
Rich build-in library

There is no right answer for this, becasue there is no one-size-fits-all "better" definition. If you know C++ and have a lot of C++ code assets already, C++ sure looks appealing. If you know c# and not C++, then C# sure looks appealing.
C++ applications load faster, but for many applications, that's not relevent. C# applications can certainly be written faster, but they also don't have determinism. I'd never even attempt a UI in C++ any longer, nor would I think about doing database access in C++. I wouldn't write a driver in C# though, or a shell extension.
Generally speaking, most solutions I've ever delivered were a mix of the two. C# has its strengths. It's fast to write, easier to debug and unit test, hard (though not impossible) to create leaks and for some operations (like data access or XML parsing) it's just easier.
C++ has its strengths too, like speed of execution (though C# can be made to go just as fast for many things), determinism and the ability to plug in to things that want native entry points.
So my answer? You need to know both, and likely write your solutiuon using both. The percentage of each you end up using depends on what your end goal is.

It depends.
At least present a specific use-case. And possibly use SO search? :)
C++ or C# to program mobile barcode device?
Edit:
Apparently others were faster to the draw, and gave more articulated answers. Nevertheless, I still recommend reading the above SO thread.

From my experience it is easier to start with c#, and if the api provided by the compact framework is enough for you then you are ok.
On the other hand if your project is somewhat complex, or if you want to do something that is not in the compact framework you may end needing to create a helper .dll in c++. Even in this case you maybe good doing your main program in c#, and programming helpers dll in c++.
If you go directly to program in c++ you may benefit from the fact that you have a raw performance better than c#, which is good if you are doing a game.
But you will also suffer more from the limitation of windows mobile OS. Like a maximum of 32MB per process, or that all .dll share the same address space.
So in the end it really depends on what are planning to do and the experience you have.

What advantages are there to developing a Win32 app in C++ over a .NET app in C#?

I learned windows programming using Visual C++, and the Win32 API. Nowadays, it seems most apps are being developed in .NET using C#. I understand that most of the time there isn't much performance difference between native code and managed code. So I'm wondering, if I were to start writing a new desktop app today, is there any reason (other than the fact that I'm more familiar with C++), that I might want to write it in non-managed C++ instead of .NET? Are there still some advantages to using C++ and native code? Or has that method been more-or-less replaced with .NET on the Windows platform?
Of course I know that people who are writing low-level device drivers and similar programs wouldn't do it in .NET. I'm asking with reference to typical client-facing apps that don't make direct hardware calls.

IMO the most important one for small downloadable applications is that native code does not need the .NET runtime. While broadband becomes more and more common not nearly everybody has it yet.
Some people may be disappointed to see that your 2 MB application actually requires another 20MB of framework download and a bothersome installation process to run. If they are not sure whether or not they really need your application in the first place, they might just delete it before even giving it a try and turn to a competing product.

Performance (certain situations, such as graphics)
Memory footprint (as Mancuso said)
Use of existing libraries
No need for a runtime
Finer control
To list a few.
However, you may also want to look at the question from the opposite angle to fairly evaluate which language to use.
Additionally, you could use C++/CLI to incorporate both native and .net code.

If your application needs to be able to run without an installation (i.e. if you can't or shouldn't do something like install the .NET framework), you can't count on .NET being on a windows machine (pre-Vista). Lots of utility applications can fall in this category.

I would recommend to write every desktop application in managed code. .NET/C# is a great platform to do so.
My reasons:
Performance penalty is negligible. Google for benchmarks if you don't take my word. What matters more is the code itself. You can write O(n^m) algorithms in C++ or .NET/C#. JIT engines are very mature these days.
Unmanaged C++ has major drawbacks when it comes to unit testing, mocking and refactoring. It's very cumbersome and inflexible. Reflection allows managed code to make such things very convenient.
Deployment is a small issue. However, creating a setup which checks for the necessary .NET preconditions and installs them automatically is a no-brainer.
Compilation is quicker, no linker! It even happens in the background when you edit the code.
.NET library support is way better and cleaner than STL, MFC and boost.
No header files and macros. They are just error prone.
Security! Good bye buffer overflows, bad pointers, uninitialized variables...
Exceptions. Clear exception hierarchy in .NET. C++ exceptions are messed up.

Memory footprint. But unless you're developing for a severely handicapped machine memory-wise, it really shouldn't be an issue for most applications.

If you can afford the dependency on the stack, go for .NET
Modern, elegant, powerful and as a result much quicker to develop for.
But realize that you chain your app to it - to the language and the framework, if you forsee a future where you may want to escape this, then better think twice.
Win32 is old and clunky, but it works on virtually any Windows version without extra dependencies, and your code can be in plain, portable, C/C++.

+1 for not having to require a .NET package/install on the target machine(s). This is still a big issue.
When all machines have mono or NET it won't be such a big deal.

Two things that I can think of.
Protection of intellectual property. It's infinitely harder for someone to reverse engineer an Unmanaged C++ app. Managed .Net or Java apps can be easily de-compiled this is not the case with Unmanaged C++.
Speed. C++ is closer to hardware and has a smaller memory footprint as the other comment mentioned. This is why most video games continue to be written in C++ and inline assembly.

.Net programs also have a support lifetime, where native do not really. Native will run for many years across different OS's without requiring updates.
.Net programs can be hosed by bad .Net configuration, native just keeps on running and is hardly effected by OS updates.
.Net programs startup slow and feel sluggish, native starts quick and runs quick.
.Net has to be coded for lowest common denominator (most distributed framework version), Native compiles all code into application - so use what you want.
Use Delphi for Native, not C++. .Net is partially based on Delphi RAD and Java backend.

C++ or C# to program mobile barcode device?

I will be developing some applications using mobile barcode scanners and need to choose between C++ and C# for coding on the scanners.
I am considering Intermec's CK31 or similar for the combination of wifi, scanning choices, programmability and user interface options. It runs Windows CE .NET 4.2 according to their spec sheet.
Intermec's Developer Library comes with .Net and C++ SDKs. My previous Win CE 2003 experience is in C++ (MFC GUI, sockets and serial comms). I'm comfortable in C# with WPF and can learn other GUI frameworks if I have to. That gives me freedom to choose a language - any recommendations one way or another?
I am NOT looking for answers advocating C++ over C# as languages in general - my productivity in either is similar and I have enough experience to be able to create complex, robust C++ solutions.
What I would appreciate are war stories or factors to put into our platform evaluation, about programming on these devices. eg: battery life of C# apps vs C++ apps, memory consumption or other environmental impacts of the language choice. If there are specific versions of .Net CE to avoid, that would be a good tip.

I've been designing and developing software for Windows Mobile and Windows CE in C, C++ and C# for quite a few years now. Moreover, I been doing so for Honeywell (formerly Hand Held Products, purchased by Honeywell in 2007) where I've worked on nearly all aspects of the devices, from drivers and services to Line of Business GUIs and utilities.
First of all, I won't tell you one language is better than the other... I probably spend a 50/50 split of my time with each, and each platform definitely has their own place in the mobile development.
I will however, give a suggestion that you likely stay away from any device that runs an OS as old as WinCE 4.2, especially if you are even considering .NET development. The reasoning for this is that 4.2 only has, at most, .NET CF 1.0 embedded in ROM (part of the OS ROM image), meaning that you would require a ~5MB CAB file to install at least .NET CF 2.0 Yes, you could develop with CF 1.0 but, truly, it's not worth the pain of using such an old framework. Most WinCE 5.0 devices these days come with CF (Compact Framework) 2.0 installed in the ROM so I would at least look for that.
On that same vain, you may even want to consider using a device with Windows Mobile 6.0 or 6.1 as they are easy to program with and will always have CF 2.0 pre-installed. In case you're wondering why I have not mentioned CF 3.0 or CF 3.5, it's just because the first Mobile platform to be release with those versions will be Windows Mobile 6.5, which is not out yet. Though you can always install the framework if you want (~8MB CAB).
Granted, WinCE definitely gives you a more "Windows" look and feel to its GUI over its Windows Mobile cousin, so that is all a matter of your programming preference and what your end users want and need.
Regarding kgiannakakis's comments on SDKs being only a thing layer, this is just not true. If you have a proper SDK you should have all of the same access to any devices or drivers that you would in C++ but with the ease of C#. For example, Honeywell provides an extensive SDK for all of our devices in C++, VB and C# and the C# portion of the SDK actually has more functionality than the C++ portion. You will never have to do a P/Invoke with our code from C#.
If you want to take a look at the SDK I'm talking about, it's freely available to download here and has some great examples.
IMHO I would actually consider the provided SDK as more important than the hardware in many cases since, most of the time, the hardware for the devices is pretty much the same. They all have ARM CPUs, WiFi, Bluetooth, Laser or Image based scanners, etc.
Though, I looked at the Intermec link you posted and it doesn't look like that unit actually has a built in scanner...are you using an external scanner hooked to the device?
Take a look at the Honeywell offering if you want here. We've got devices with probably the best imager based bar code scanner in the business, built into all of our units. And we have a rock solid SDK (I should know, I wrote a lot of it). And the SDK provides .NET extremely access to all of the hardware on the device. Ok...I'll stop my sales pitch now.
As for one language over the other...it really all depends on what exactly you want to do.
Drivers and services cannot be written in anything but Native (Win32) C or C++. So .NET is out for anything like that.
C and C++ can absolutely be your friend on mobile devices in terms of keeping things lightweight, since you don't need the whole .NET framework to run the add. Remember, you have a maximum of 32MB of memory for any process (not including DLLs..that's another lecture) so if your application is going to be processing a ton of data, C++ may be the way to go.
One of the major disadvantages I've found to C and C++ on mobile systems, however, is that making a GUI is way harder than it is with .NET Actually, most of the C++ apps I write are completely headless and have no GUI at all... .NET CF does not have WPF (yet), and is stuck with WinForms, but it's really easy to pick up. Pretty much drag and drop in the designer. And also remember, like I mentioned before, that WinCE has a completely different GUI paradigm than Windows Mobile. However, sometimes the Windows Mobile way is kind of nice, since it forces you to keep your GUIs simple and to the point.
Memory consumption can be higher when using .NET, but not always. For one, having a device with the version of the CF you are going to use stored in ROM will mean that you will generally have no more memory used on a .NET application vs the equivalent C++ app. In some cases, .NET will even use less memory. For example, a .NET app vs a C++ app that uses MFC can often use less memory because the C++ app has to load up the MFC framework (since it isn't already loaded by the OS...).
Also, since C# is managed, you will often end up with less memory usage because the garbage collector is freeing up memory that you may have forgotten to do in a C++ app.
Execution speed on more modern devices is generally no different between the two. Granted, you will always have little parts of each language where one will be faster than the other, but .NET is mature enough at this point that the speed is not really a concern. I have programmed extremely fast applications with highly interactive, animated GUIs that ran just fine on a device with 128MB RAM and a 420MHz ARM CPU. I even wrote one app that I had to slow down because it was calling into a native DLL via P/Invoke and the .NET portion was essentially getting "Impatient."
I have never seen any issues with battery life in one language vs the other. But I've never specifically tested for it either.
I really think that, in the end, it still comes down to the SDK that comes with your device of choice. If it has poor .NET support then you will find your self doing a lot of extra work getting everything to work, in which case I would go with C++. But if it has great .NET support (like the one I work on) you will find yourself with a lot less work and probably get the job done significantly faster.
Also, remember that it's not just the SDK of the hardware vendor you have to take into account. While you need that specific SDK as each device is different (i.e. the SDK I linked to earlier will not work on that Intermec device) all of the non-hardware related OS stuff is pretty much standard across the board, which is where the Windows Mobile or Windows CE SDK from Microsoft comes in. Their C++ support is pretty good, but they are really pushing all things .NET these days, so as updates are made to the OS, less updates are made to the C++ SDK and much more functionality now relies on using .NET Not that you couldn't do it in C++, it's just that they haven't done a lot of the work for you that they did do in the .NET SDK.
Ok...that was long, but I was trying to dump the finer parts of my years of experience into one thing. I hope it made sense.

The answer to your question has to do with the type of your application. If your application is mainly around communicating with the hardware and only a thin layer of business logic and User Interface is needed, then C++ would be a better choice. To interact with the scanners you need to talk to a driver. This is better and faster achieved with C++. The .NET SDK will actually be a wrapper of C++ code using a ton of P/Invoke, which makes the code performing less faster.
If on the other side your application requires a significant business layer and/or a User Interface, then .NET (and specifically C#) is a better option. In that case the productivity gains far out weight the performance gains of C++.
Another important factor is the type of the devices the application is going to be deployed to. Are you targeting Windows Mobile devices only? Then .NET is a safe option. For Windows CE devices you need to investigate whether the compact framework is pre-installed or not. Also, some Windows CE devices may not support all .NET namespaces.
Finally, I recommend reading Mobile Architecture Pocket Guide, which is a recent document about architectural decisions for mobile applications.

First I'll strongly echo Adam's recommendation against running anything based on CE .NET 4.2 at this point for essentially the same reason. At this point it's an ancient version of the OS and unless you are getting the terminal for free it's not worth it and if you choose to do C# development the download of the CAB to run .NET 2 is just painful.
We've developed a lot of applications for both Motorola(Symbol) and Intermec devices. The current set of APIs for both of them work reliably so I'd worry more about the suitability of the device than the specific APIs. They also both provide reasonable sample programs that make it easy to cut and paste a solution.
I have noticed one other big difference between Motorola and Intermec. On the Intermec devices I've worked with (in C#), it takes about a second for the decoder for each symbology to be loaded. This typically isn't a big deal if you use a limited number of symbologies and setup the scanner at the start of the application, but can cause significant delays if you change the decoders(symbologies) within the application.

I've been developing for about 15 years. Approx 5 years in C++ and 3 years in C# (which currently is my language of choice). In C++ I always used stdlib, and sometimes boost.
I have cut my development time with a third since I switched from c++ to c#. That was done because of a couple of things (nothing scientific, just my opinons):
.Net is a more complete framework and easier to use than stdlib and boost combined.
C# has a better structure which make easier to read others code and to code.
Unit testing in .Net is light years from unit testing in C++, especially with Resharper and xUnit (xUnit got clean syntax, resharper let's you test specific test methods directly inside dev studio).
I mostly code servers, GUI programming should be even faster.