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).

VOIP in C#, asp.net or Java

Could you people please give some good resource / ideas of implementing VOIP in c#.net, Asp.net or Java.
Why I am specifying 2 different language platforms is we are yet to take up a call.
Basically we don't have the idea henceforth the concept is more important to us.
We are going to make a White board application and one of the client requirement is
White board should have VOIP
conferencing, chat image sharing and
ability to upload .pdf files

I reckon your looking into developing software like orange business webex or something similar. The software is not too difficult to develop. First, are you planning to write the entire application yourself or just purchase the components and integrate ? I would recommend you shop around for components and just integrate because VOIP is rather complex.
Here is a link for SIP communicator in java which supports VOIP

Doing simple point-to-point VOIP isn't too difficult. Basically, you need a codec on each end, and then typically use UDP to send encoded packets from one end to the other.
There can also be network connectivity issues, particularly related to NAT.
If you want to interoperate with existing VOIP-based systems, then you will need to support one of the underlying connection protocols, such as H.323, and you may also need monitoring and control over RTP. Those protocols are notoriously complex.
There are a bunch of tricks to play when doing this kind of thing with a managed language like C# or Java, particularly related to avoiding hiccups due to GC.

A link to a few more Java VOIP projects/components:
http://voip.dev.java.net/
One "gotcha" to beware of, in terms of future functionality, is that Java's (as opposed to JavaFX's) video support is something of an open question at the moment.

mobile ocr sample code

I was wondering if you can give me sample (or snippet) code in OCR for Mobile Phones because i need to have an idea how to start my project. i know how to code it for the use in desktop PC's but my partner told me that mobile phones has a different platform. We are planning to use .net for mobile on this one.. hope you can help me..:)

It looks like there isn't much for C#/.NET, according to this question. If you have written OCR code yourself using C#, it might work as is on the Compact Framework, or it might be made workable with minor modifications. The Compact Framework is a subset of the full .NET framework, so usually code written specifically for CF will run in regular Windows, but code written for Windows may or may not run in CF, depending upon what functionality has been utilized.
Your partner is sort of right, but there are lots of different platforms for mobile device development, and .NET is definitely one of them (and a good one at that).

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.

C# Game Network Library

I am developing an online strategy game using .Net v2. Although the game is primarily strategic, it does have some tactical elements that require reasonable network performance. I plan to use TCP packets for strategic data and UDP packets for tactical data.
{EDIT} I forgot to mention that I am leaning away from WCF and .NET 3+ for a couple of reasons. First, because I want to keep my download small and most of my customers already have .NET 2.0. Second, because I would like to have the option of porting to Mac and Linux and am unsure of WCF availability in Mono. {/EDIT}
I am looking for network library recommendations. I have found a few options, such as GarageGames' Torque Network Library (C++), RakNet (C++), and the lidgren network library (C#):
http://www.opentnl.org/
http://www.jenkinssoftware.com/
http://code.google.com/p/lidgren-network/
Does anyone have real-world experience with these or other libraries?
I just stumbled on RakNetDotNet:
http://code.google.com/p/raknetdotnet/
This might be what I'm looking for...

Microsoft's own .NET based XNA allows you to create networked games on Windows and XBox 360.

http://code.google.com/p/lidgren-network-gen3/
Lidgren.Network is a networking library for .net framework which uses
a single udp socket to deliver a simple API for connecting a client to
a server, reading and sending messages.

I'd also like to note that "Games for Windows", which XNA uses on windows with its Live! networking APIs is now free ... which means that if you write an XNA game that uses the networking features, your users do not have to have a gold membership :-)
http://www.engadget.com/2008/07/22/games-for-windows-live-now-free/

Why limit yourself to .NET 2.0. .NET 3.0 (or 3.5) contains WCF and is a solid, performant communications subsystem with good security. .NET 3.0 is just .NET 2.0 with additional libraries (WCF, WF, WPF).

You could take a look at Entanglar ( http://entanglar.dunnchurchill.com ) if you are looking for something higher level. Entanglar provides full entity lifecycle and sync.

Although this question is rather old, a somewhat higher level system developed specifically for games is APlay - among the supported platforms is also C#. There are evaluation versions and it is free for personal use.
You define your game objects in an UML alike fashion and an online code generator creates assemblies containing your game objects. Sending state updates is then as simple as calling setter methods.
Not the right thing, if you want to cope with sockets by yourself. Please also note that I am a developer of APlay so this is a biased answer.

An ancient question, but I'll put this out there for anyone else who stumbles across this. We're using OpenTNL for our game, Bitfighter, and I am consistently surprised at how well it works. And it's free if you can live with GPL.

If you're new to game development, I'd recommend XNA- it's easy to program with. The advantage of Torque, however, is it has asset creation tools, which can also be invaluable. For a higher end game or FPS, the Source engine is great.