I have an Outlook add-in and a separate winform app. These two apps need to "talk" together sending/receiving notifications.
Sometimes they are on the same computer and sometimes they are on different computers. Sometimes several instances runs on the same computer by different users (RDS server). Maybe later they will need to talk to mobile apps too.
If I do no want to play around with TCPIP, what is the best and easiset way? I don't mind buying some server software that will make it easier. It must be plug-and-play.
I thought about Microsoft Notification HUB, but it doesn't seam like it works with winform.
Then there is Amazon SNS, but I have no experience if this works in winform.
Do you have any suggestions?
Well you can use SignalR to develop real time notification system it easy and you can use it cross platform because it uses websockets like node js
Related
Our company uses a system of which I am the sole developer. It is a C# based desktop application that is run on some 50 workstations or so and all connect to one central SQL Server database.
Our network administrator is now looking at presenting the application through Terminal Services, something that I know nothing about, yet.
As I started Googling around I saw that, apparently, some applications do not work under Terminal Services. MS Paint is mentioned as an example. So this got me wondering, what does a developer need to know to make sure that his/her application works in Terminal Services?
I don't have the time right now to investigate TS in depth but I'm hoping there might be an article somewhere that is written for developers. As in "Things not to do when you develop an application that will be run in Terminal Services".
Terminal Service RemoteApp works pretty well if you application is designed to be multi-user compatible. so you will need to ensure user session related data is not shared, but placed in isolated storage with IsolatedStorageContainment set to DomainIsolationByUser for example.
here are some useful links:
http://www.fmsinc.com/microsoftaccess/terminal-services/remoteapp.htm
https://www.youtube.com/watch?v=Nf20-76dMcg
https://msdn.microsoft.com/en-us/library/3ak841sy%28v=vs.110%29.aspx
Looked for a long time and didn't find anything that showed this, so I apologize in advance I missed something.
I have an android app running on KitKat (Android 4.4.2) and a Winforms application running Windows 7. I need to send messages between the two of them.
Clearly GCM works to get the message to the Android device. I have code that sends from Winforms to the Android Device using GCM. I cannot find a way to have the Android App send anything BACK though. Is it possible to have a Winforms app RECEIVE a GCM Message? Do I have to use Azure? (All examples there seem to focus on the Windows App store and Windows 8.1 neither one of which can be a solution in this case due to client restraints.)
I'm putting this here in case anyone stumbles across it and has a similar question. This is not really an answer. Still hoping someone comes on here and shows that I am wrong. But after 26 days, no one has even offered a suggestion, so I'm guessing not.
There is no way that I have seen that allows for this the way I had hoped. Windows 7 doesn't have this built in to it (AFAIK). Windows 10 should have it built in, but Windows 7 pre-dates the huge shift to the cloud, and didn't have it in the design. If I were working with something like Xamarin -- which is a cross-platform tool, this might be possible. But there is no concept in Windows 7 for receiving messages from the Cloud.
In order to accomplish this, there would have to be some sort of server added to the mix that could take messages and pass them along via a REST API. This is beyond the scope of what I wanted to code.
The solution I found, and that works for me, is to use Microsofts API that wraps a REST service. This allows for communication to OneDrive, for example. That is what I am using as my intermediary REST server.
Microsoft LIVE SDK
This has a pretty good sample list of Android examples, and can be used for what I need. The good thing is the Upstream is just a simple call, and I don't need to have the Android device poll anything (which kills the battery). The laptop will need to poll OneDrive, but its plugged in so there is no battery life concern.
One thing to be aware of, though, is that Microsoft sort of hints that they don't want a bunch of traffic headed to OneDrive. This is from the overview doc:
Throttling
OneDrive has limits in place to make sure that individuals and apps do
not adversely affect the experience of other users. When an activity
exceeds OneDrive's limits, API requests will be rejected for a period
of time. OneDrive may also return a Retry-After header with the number
of seconds your app should wait before sending more requests.
Although, I have never seen what those limits actually are, so YMMV.
This isn't exactly a code question as much as it is an advice question. I currently working on a program for a small business. This program does a multitude of things from updating their local access database, edits and updates Word and Excel docs, etc. Now I have the WPF/C# based program running on a Windows 8 computer but they would like to be able to run it from multiple computers. My first instinct was to make the project again as a WPF Browser application. My questions is how would one set something like that up? Would I have to dedicate a computer with special software to handle just this program, the database, and their documents? Any Suggestions or tips would be greatly appreciated.
It doesn't have to be a WPF Browser App to run on multiple PCs. I suggest using Click Once deployment, where all users automatically get the latest version from a shared folder on an office server or just one of the other PCs in the office.
If they want all of these instances of your application to connect to a common data source or sources, then you will need one computer that hosts the server application and its database (you'll now have 2 projects: the server application, which might run as a Windows Service and have no UI, and the client application, which is the WPF app).
This computer be an existing Windows server in the office or it can even be just one of the PCs in the office, but that PC must be kept on for others to use the app and if anyone reboots it in the middle of the day others could lose some of the data they were updating.
Fundamentally, you need to alter the WPF application so that it fetches and sends its data from/to the "server," most likely using WCF services.
It is a lot to digest, but in incremental steps you can get there. The biggest hurdle will be getting your first successful WCF communication between server and client. Once you cross that threshold you'll be well on your way!
I have a WCF service which exposes SOAP and REST endpoints and we have WPF,Android,Windows Phone(in future),ASP.NET applications on top of our WCF service, so many users can use many apps from different parts of the world.
Right now we have a big issues with the freshness of data we are using some old school polling techniques to look for the updated data, is there a way to create a system which push data to the connected apps regardless of the platform and location if any data update occurs on the server from any application.
I have already looked into the Duplex Callbacks but that is not possible with android and has some other limitations.i also know about the GCM for android but dont know how to make it working with other platforms apps.
GCM only works for Android devices. There are similar push notification services for Windows Phone and iOS. There are several solutions such as PushSharp and Windows Azure Mobile Services, which allow you to push notifications to several devices.
As for what to use the push notifications for. I strongly suggest not to use them to push data, as you cannot always be 100% sure if the notifications ever reach the device. Hence only use them to notify the client about new data is available, and then fetch it. Use push notifications along with polling.
It is not entirely clear what your application does, hence I do not know when and how often you need the new data. Just keep in mind that iOS for instance does not allow using a permanent background service, like Android and Windows Phone does, however the WP one does only allow for updates every 30 minutes.
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.