Can SignalR send messages to a Borland C++ client and if so what is the oldest version of Borland C++ (ver 6/ ver 7)? How would a Borland C++ client receive a SignalR message if it is possible? If not what send technology would be best with Borland C++ as the client and C# .NET as the pusher?
It looks like there is a C++ client, but it's not actively maintained, so you might have to customize a lot of the code to make it work for you.
It might be possible to use node.js/socket.io with edge.js but it's probably not very straightforward.
I'd take a look at things like ZeroMQ or RabbitMQ.
I am searching for the same info but in a wider context. I m rather interested to know, if there exists a way using SignalR from a plain C++ in general without managed extensions. Compiler as such does not matter for me. I plan using MS Visual Studio 2005 or above.
Originally, I was sure that technology is fully .NET related. To my surprise, I have discovered C++ client wrapper on official ASP.NET source repository.
https://github.com/aspnet/SignalR-Client-Cpp
The code is for VS 2013. After a short review of code, I see no use of managed extensions or Microsoft specific coding. It looks that the code should be portable with very limited effort. I will try building it now with VS 2005 and will update this comment on results afterwards.
As of the date of writing, last commit into repository is only 15 days old. So it looks like the code is actively maintained and developed.
Related
I have developed a .NET 4.5 application using WinForms. I want my application to run not only on Windows, but also on Linux, so I decided to port it to Mono.
However, I can't find any information on how to use Visual Studio for Mono. I don't want to switch to MonoDevelop, since VS provides much of the functionality I want and I am already familiar with it.
There apparently used to be something called Mono Tools for Visual Studio, which David Lively insists works on current VS editions, but I don't want to run an extension that was deprecated 3 years ago. I don't even know where to download the extension - it redirects to Xamarin, and Xamarin seems like not what I want because while it mentions VS integration, it forces me to install a bunch of Android and Java SDKs (why?).
As far as I can see, .NET and Mono code looks fairly similar, and there are 3 main concerns:
Making VS use the Mono compiler instead of the C# compiler, so I can tell if non-Windows users can compile my source, and also get notified about missing libraries
Making IntelliSense suggest only Mono-supported things
Making the "Run" command run the application using Mono, not .NET, so I can test it correctly
Is there really no easy way of accomplishing these?
Note: I want to develop Windows and Linux desktop apps, with a WinForms GUI or equivalent only. I am not interested in mobile.
In general, you can just target .NET 4.5 and compile with Visual Studio and the resulting assembly works as-is on Mono (assuming you don't use platform-specific stuff via p/invoke, etc).
Mono's WinForms support isn't perfect though (and nobody actively works on it), so you still need to test by running the app directly on Mono. Missing APIs aren't usually the problem, it's more that the Mono implementation has different behavior/bugs.
Another alternative to WinForms might be Xwt.
I have a POS software and need to develop a collecting module for windows CE to run on a Honeywell Dolphin 6100 device.
I need to develop a simple application to run on a Honeywell 6100 device. This application should:
Get a list of products (code, description and price) from my POS software
Process Sales reading product's barcode showing Total due and number of items
Upload that sale to my POS software (via network, files, or something like that)
What are my options? Are there any Application builder for Windows CE? If not what could I use to develop such application?
You have a few options, but few (if any) of them will allow you to create the application without writing code. I'm aware of no "application builder" products that will get you there in Windows CE, and I've been working with CE for some time. That's not to say some obscure thing might not exist, but I am not aware of one.
You can write your application in .NET - either C# or VB.NET are supported - using the .NET Compact Framework (CF). For that you will need Visual Studio 2008 Professional and really little else, other than a device. There are lots of tutorials and online resources for CF development, so I won't put in a list of them here.
You can write your application in C/C++. For this, again you'd want to use Visual Studio 2008 Professional. Yes, there are options that use other compilers, but if you want to spend time actually writing the app and not building up a development tool chain and figuring out how to get it connected and debugging, then Visual Studio is the route you want.
If you'd like a non-Microsoft solution, there are others that are supported to more or less of a degree. NS Basic has been around a long time, so it's probably pretty robust and has reasonable support. I've never used it, but I've heard good things about it from those who have.
Anything else and you're a bit off the reservation. Support will likely be minimal at best, tooling will likely not be robust, support, tutorials and all of the other goodness that developers often rely on to move forward will be scant. You can likely get any language working under CE, given enough time and resources, but the options above are the most likely to lead to success.
Since you said you know Delphi and didn't want to learn another language, you can use Delphi Prism to write a client app to run on windows CE, pull the data you need, and post it to a webservice:
Is Delphi Prism a new version of Delphi .net?
http://en.wikipedia.org/wiki/Oxygene_(programming_language)
(edit) Just checked and it's now a part of this package:
http://www.embarcadero.com/products/rad-studio/faq
I am wondering what level of support the latest MonoTouch has for using SQLite. The closest information I can find is this article here which referes to limited support in v1.2 however it concedes that you may run into run time errors while using this.
This is what I found on the Xamarin website: http://docs.xamarin.com/ios/Guides/Advanced_Topics/System.Data
This really scares me. Is there any documentation out there indicating what current level of support Xamarin has for SQLite?
I can't speak about the changes in System.Data support past that article, but I think it's quite common for folks to use csharp-sqlite, or better yet sqlite-net instead. Csharp-sqlite is an independent port of SQLite. And sqlite-net is "better yet" in the sense that its a minimal library where you can drop a single file in your project and use it to support sqlite on the various mono platforms. Yet it has nice features still such as "strongly typed queries" due to reflection-based ORM. So if you don't need a full Sqlite driver its a good option.
Greg Shackles did a nice seminar on x-platform dev with Monotouch/droid back in April where he covers these and other libraries: http://blog.xamarin.com/2012/04/25/cross-platform-mobile-development-seminar/
This link is outdated, it's about MonoTouch 1.2 and the latest MonoTouch's version is 6.0.
I'm using Sqlite with Vici CoolStorage in two apps on App Store: easy and no problems at all. I've never see any runtime errors using Sqlite.
Does any one know in which programming language were Google Talk application developed.
yes am asking about the windows client application. :)
http://www.google.ro/talk/
googletalk.exe -> Compiled with: Microsoft Visual C++ 7.0 [Debug]
gtalkwmp1.dll -> Complied with: Microsoft Visual C++ 7.1 DLL
So GTalk is written in C++
You'll find http://www.peid.info/ pretty useful for this kind of stuff.
According to Steve Yegge, Google is using C++, Java, Python, and JavaScript. So the answer would be C++ :)
Google released an open source library for Google Talk called libjingle, which is written in C++. So logically, the Windows client would probably be C++ too.
Do you mean the client side, or the server side ? The talk protocol is Jingle and libraries are available in C/C++/Java.
Ideally the protocol would be language independent, and consequently both sides (client and server) would not be constrained to a particular language.
According to this Google-talk Wiki, it uses libjingle which they've implemented in C++. However, a company as big as Google is big enough to develop their own in-house compilers with support for whatever dialect they prefer. This would be a sensible thing to do for Google, to have something which could be compiled for every operating system that they want to support.
I don't have Google-talk but I checked the binaties of Picasa, another Google application. It mentions the Visual C++ Runtime Library so I guess I'm wrong and Google is probably just using Visual Studio instead.
In general, C++ is a platform-independant language, making it the most appropriate language to use to write new projects. However, depending on the desired functionality, you do need the proper libraries for all the platforms you want to support and make sure they all expose the same methods.
Java generates platform-independant binaries. As such, it's more powerful than C++ but those binaries depend on the Java Virtual Machine, which reduces their performance. This makes them less qualified.
There are plenty of other languages that could have been used but Google is most likely using a language that supports as many platforms as possible. (Including the future Google Chrome Operating System.)
When using 3rd party libraries/components in production projects, are you rigorous about using only released versions of said libraries?
When do you consider using a pre-release or beta version of a library (in dev? in production, under certain circumstances)?
If you come across a bug or shortcoming of the library and you're already committed to using it, do you apply a patch to the library or create a workaround in your code?
I am a big fan of not coding something when someone else has a version that I could not code in a reasonable amount of time or would require me to become an expert on something that wouldn't matter in the long run.
There are several open source components and libraries I have used in our production environment such as Quartz.NET, Log4Net, nLog, SharpFTPLibrary (heavily modified) and more. Quartz.NET was in beta when I first released an application using it into production. It was a very stable beta and I had the source code so I could debug an issue and there were a few. When I encountered a bug or an error I would fix it and post the issue to the bug tracker or author. I feel very comfortable using a beta product if the source is available for me to debug any issues or there is a strong following of developers hammering out any issues.
I've used beta libraries in commercial projects before but mostly during development and when the vendor is likely to release a final version before I finish the product.
For example, I developed a small desktop application using Visual Studio 2005 Beta 2 because I knew that the RTM version would be available before the final release of my app. Also I used a beta version of FirebirdSQL ADO.NET Driver during development of another project.
For bugs I try to post complete bug reports whenever there's a way to reproduce it but most of the time you have to find a workaround to release the application ASAP.
Yes. Unless there's a feature we really need in a beta version.
There's no point using a beta version in dev if you aren't certain you'll use it in production. That just seems like a wasted exercise
I'll use the patch. Why write code for something you've paid for?
There's no point using a beta version in dev if you aren't certain you'll use it in production. That just seems like a wasted exercise
Good point, I was also considering the scenario of evaluation of the pre-release version in dev, but I supposed that taints the dev -> test/qa -> prod path.
I'll use the patch. Why write code for something you've paid for?
What if it's not a commercial library, but an open source one? What if the patch to be applied is not from the releasing entity (e.g. your own patch)?
I use:
Infragistics (.NET WinForms controls)
LeadTools (video capture)
Xtreme ToolkitPro (MFC controls)
National Instruments Measurement Studio (computational libraries, plotting, and DAQ)
I've found significant bugs in every one of these, so I try to limit their use as much as possible. Infragisitcs is pretty good for what it is, and National Instruments is by far the best, although quite limited. I would avoid LeadTools at all cost.