I'm interessted in writing an application that is running on windows mobile. I've allready a winform application that is hosting an WCF service. I wan't to port the application to windows mobile (6.0) and up. MSDN is hosting an article about WCF on Compact Framework, but it says hosting is not an option yet.
Do i have to write it all by my self over a TCP Listener?
Bye Marco
Basically, yes; you'd need to do a lot of this yourself using TcpListener. Even HttpListener isn't in Compact Framework, which is a shame (otherwise it would be easy).
There may be pre-canned solutions available, however.
For interest, I have an open-source framework that is nearly there - it has all the serialization / dispatch / etc code, but I haven't yet added raw TcpListener support, which is a shame. But maybe soon.
Couldn't you port the mono HttpListener class to the Compact Framework. At least you'd be starting with a pretty well tested code base and as baseline.
Related
What is the best approach to communicate between UWP app (client app) installed on phone and WPF app itself installed on local machine if they are connected to the same router? Files should sync from client to server and vice versa.
As I investigated before there are WCF, Sockets, and Web. So what is the best one to use to create such functionality?
It does not matter if the app is WPF or UWP. To choose framework like WCF or Sockets you need to know how complex your scenario is. If it is rather simple, I would advice agains WCF. It can be unnecessary complicated for basic usage. You can try web api - lite system using JSON. Generally speaking, I do recommend the framework enabling http protocol as it is reusable for almost every scenario. But that is not filter that would help you much :D
For UWP that have not allowed calling localhost and you can use it to communicate to local wpf app.
More details here and here.
But you can make the uwp communicate to local wpf app in debug, see Deploying and debugging Universal Windows Platform (UWP) apps - UWP app developer | Microsoft Docs
If you want your uwp app can use localhost in release that you should use checknetisolation and you can see some way to use wcf in the article.
Im creating a web application that can view a few database tables. You can even update the tables from the web application. Everything works fine, but I want the tables also to be updated in realtime when the tables are changed from another client! And even from my windows application. I've heard that you can use websockets between clients. But Can you also use websockets from a windows program to communicate with a webserver? (on the same computer)
All client examples Ive found so far uses javascript, so I think the answer is no, but hope Im wrong. I was planning to use signalR.
Im writing in C#.
Yes. Websockets are not natively in the .NET library for clients. But there are good 3rd party libraries which are free.
I have used WebSocket4Net. https://websocket4net.codeplex.com/
WebSocket is an official IETF wire protocol that can be used by any language. WebSocket is also a W3C official JavaScript API, but there are other language bindings that mimic the JavaScript standard, e.g., Java, C#, C++, iOS, Android, et al.
The Kaazing Gateway has C#/.NET bindings for WebSocket. Here's the 4.0 binary: http://developer.kaazing.com/downloads/byop-edition-download/
Search for "Kaazing" in Github to get the src.
Full disclosure: I work for Kaazing.
I am looking at writing a WinForms app and getting stumped over what seems to be simple issue.
There is a server and database (SQL Server) Open ports are HTTP, HTTPS
There is a WinForms client. It needs to connect a TCP/IP stream (possibly HTTP, SOAP, REST) to the server.
Sometimes the WinForms client goes off-line and then the WinForms client stores its data in a database.
When the WinForms client goes on-line to server, it synchronizes data to the server, gets all the latest data from the server and updates local database.
How do I do that?
Newbie question
As you've conceded, this question shows you might not know where to begin looking for how to architect this kind of application.
I'd start here: http://msdn.microsoft.com/en-us/library/ms973279.aspx
The offline architecture you've described is a little tougher for a newbie than not supporting this, consider making the application only work online first, then add offline functionality.
Also, if you have a web server you will almost always use HTTP, SOAP and REST are strategies that sit on top of HTTP. I cannot recommend that a new developer look at any server communication using direct TCP/IP.
Edit: Answer to related question - there are tons of ORMs and service builders, not a lot of them have built in support for offline workflow but ODX does, but it might be a bit out of date. NHibernate and any of the projects in the Castle Project are very popular components for what you're looking to do also.
No idea how actively this is still being supported by Microsoft, but you might check out the Smart Client Software Factory, it seems to support offline mode and smart reconnecting like you need.
http://msdn.microsoft.com/en-us/library/ff709809.aspx
You could approach this with a 'Service' mindset - Write a WebService (preferably a WCF service) - that forms the synchronization tier between your Winforms app. and remote database.
So, you would have your
1. Local WinformsApp. with a local database (as functional/lightweight as you want it to be)
2. WebService
3. Remote app./DB
Here are some links to tutorials/resources:
http://www.codeproject.com/KB/architecture/three_tier_architecture.aspx
http://services.community.microsoft.com/feeds/feed/query/tag/n-tier/eq/tag/visual%20basic/eq/and/locale/en-us/eq/and
http://msdn.microsoft.com/en-us/library/bb384570.aspx
http://msdn.microsoft.com/en-us/library/bb384398.aspx
IMHO this isn't usually as simple as it may sound
If you were able to go DB to DB, then SQL replication could be the simplest mechanism for synchronisation.
However, since it sounds like you are using a SOA approach, you might need to look at frameworks which have offline support built in, such as the Ent Lib Composite Application Block and Smart Client Software Factory
You might also look at using Queues (e.g. MSMQ) to accomodate network connectivity problems.
Microsoft Sync Framework (http://code.msdn.microsoft.com/sync) + WCF solution here:
http://code.msdn.microsoft.com/sync/Release/ProjectReleases.aspx?ReleaseId=3762
Database synchronisation is not an easy task to get started with, by any means. Good luck.
Generally, you need a local database, or at least a local cache.
I'm looking for some input on my current project architecture. There are three components: Server, Desktop, and Mobile Device.
I have 2 goals:
1) Send data (Approx. no more than 100 KB of text) from the Desktop (multi platform client application running on windows XP/Vista/7, and Mac OS X) to a server (Windows Server 2008, IIS 7, WCF RESTful service) to save in a database (Sql Server). The services need to be scalable because the number of desktop devices and frequency they send data is unknown.
2) A service to retrieve data from the database (Sql Server) and send to a mobile device(Iphone and Android application. Message size no more than 100 KB of text). Service needs to be scalable because number of mobile devices and frequency they connect is unknown.
My proposed solution:
Server Side (Sql Server and Windows Server 2008):
I'm looking at a WCF RESTful JSON services to communicate with Desktop App(s) and Mobile App(s). I like WCF because I am most proficient in C#, have some experience implementing WCF, after doing some research it appears all technologies used for the platforms(Windows XP/Vista/7 and Mac OS X) can easily communicate with the WCF RESTful service.
Any high level fundamental issues with the WCF service in this scenario?
I have only implemented WCF on a Windows Server 2003 machine with ~800 devices connecting every 15 minutes. The server was a physical in house server running on a private network. I need this solution to be hosted and scalable. Any recommendations for hosting a Windows Server 2008? Is there a better technology to host the service? (I'm not very familiar with how the cloud stuff works)
The services will be saving and retrieving data from a SQL server. I would like to use LINQ to SQL as my data access layer. It's my understanding there are large licensing fees tied to SQL server so I may need to go with SQL Server Express for now.
I'd prefer to keep the WCF services and database hosted separately (2 diff machines). Any recommendations for hosting sql server(or express)? Is there a hosting service that can scale better for my database? Does it make sense to keep these on 2 diff machines?
Desktop (Client Side)
I am required to develop for Windows XP/Vista/7 and Mac OS X. I plan to write a .net application to run on the windows machine(s). I"m still up in the air if i'm going to write (and learn :P) XCode or try mono. Any cross-platform ideas?
Should I expect to have any fundamental problems getting the desktop applications to talk to my WCF RESTful services?
Mobile Applicaitons
I am required to developer for the IPhone and Android. There are many examples of making WCF RESTful service calls using Objective C and the Android SDK. I'm considering trying a cross platform (ie. Appcelerator). From a high level it appears these mobile cross platforms have built a Java script layer that works with both IPhone and Android!
Any thoughts on using the cross platform technology to write ONE mobile app to run on IPhone and Android?
Any fundamental issues calling the WCF RESTful service in javascript?
Sorry for the somewhat long post. I have never designed a solution of this size. All feedback is appreciated.
Thank you!
As you are clearly wanting to use Microsoft technologies - the suggestions about Mono probably make sense to you and will certainly make things easier.
However I think you may find that you compromise elements of the user experience for Mac and iPhone users which is not ideal as these users tend to have the highest expectations for great user experiences.
I understand that we don't live in an ideal world but if we did you would develop a separate client for each platform - optimised to the needs of each platform. Unless you application is doing a lot of data manipulation the data layer is now abstracted to the server viw your JSON interface so you will not gain much from sharing the data objects across implementations.
As it seems you are implementing the project in a small team (yourself?) then I would suggest that you look at implementing a web solution with the HTML javascript communicating with the server over JSON.
The other option is that you use a flex/air client on windows and mac and flash on the android and Adobe's solution to compile flex/air into iPhone code.
Good luck though.
For your client side you may consider using Appclerator because it will run on all of the platforms that you need with little to no extra code, and it is designed to be used for web app type applications
You should consider MonoTouch for the iphone. You'll be able to share much of the desktop code. I would use Mono on the Mac for the same reason. Android is the odd man out. Eventually someone might create something like MonoTouch for Android but not soon enough to help you out.
With .Net what is the best way to interact with a service (i.e. how do most tray-apps communicate with their servers). It would be preferred if this method would be cross-platform as well (working in Mono, so I guess remoting is out?)
Edit:
Forgot to mention, we still have to support Windows 2000 machines in the field, so WCF and anything above .Net 2.0 won't fly.
Be aware that if you are planning to eventually deploy on Windows Vista or Windows Server 2008, many ways that this can be done today will not work. This is because of the introduction of a new security feature called "Session 0 Isolation".
Most windows services have been moved to run in Session 0 now in order to properly isolate them from the rest of the system. An extension of this is that the first user to login to the system no longer is placed in Session #0, they are placed in Session 1. And hence, the isolation will break code that does certain types of communication between services and desktop applications.
The best way to write code today that will work on Vista and Server 2008 going forward when doing communication between services and applications is to use a proper cross-process API like RPC, Named Pipes, etc. Do not use SendMessage/PostMessage as that will fail under Session 0 Isolation.
http://www.microsoft.com/whdc/system/vista/services.mspx
Now, given your requirements, you are going to be in a bit of a pickle. For the cross-platform concerns, I'm not sure if Remoting would be supported. You may have to drop down and go all the way back to sockets: http://msdn.microsoft.com/en-us/library/system.net.sockets.aspx
If this is a tray app, and not a true service, be wary of how you set up your communications if using pipes or TCP/IP. If multiple users are logged into a machine (Citrix, Remote Desktop), and each user launches a tray app "service", then you can run into a situation where you have multiple processes trying to use the same well known port or pipe. Of course this isn't a problem if you don't plan on supporting multiple pipes or if you have a true service as opposed to a tray app that runs in each user shell.
Have your service listen to 127.0.0.1 on a predefined port with a plain old TCP stream socket. Connect to that port from your desktop application.
It's dead simple and it's completely cross platform.
Did any one of you actually try remoting with Mono? It works just fine. You might bump into some corner cases, but this is highly unlikely. Just test your application for cross-platform (MS.Net <-> Mono) remoting from time to time to catch any possible glitches. And start with a recent Mono, 2.4.2 is current.
Remoting is an option, but it's not cross-platform. Some other ways are to use named pipes, IPC, or kernel events.
Funnily enough I was going to suggest Remoting! The Mono 1.0 Release Notes (from archive.org because the original location is missing) mention System.Runtime.Remoting.dll as a supported library and doesn't say anything about known issues.
If remoting is out then you probably have to implement your own TCP message framing protocol. Windows doesn't have an equivalent of UNIX-domain sockets for communication on the same machine.
Most services that have a GUI component are run as a named user, and are allowed access to the desktop. This lets you access it via COM or .NET but only locally (unless you want to get complicated)
Personally, I open an ordinary old socket on the service - its cross platform, allows multiple clients, allows any app to access it, doesn't rely on Windows security to be opened up for it, and allows your GUI to be written in any language you like (as everything supports sockets).
For a tray app, you'd want a simle protocol to communicate - you might as well use a REST style system to send commands to it, and stream XML (yuk) or a custom data format back.