I am currently developing an integration between a web app and a windows application, where everything works fine on standard setups. However, introducing Citrix to the equation complicates everything quite a bit.
The current solution
At the moment we have a POC (proof of concept) running with custom Uri Scheme registration to a little exe we have developed, and listing active instances with Global Atom (using this trick to list search all entries). This way, we can see if an instance of our application is running. If it is, we call it via SendMessage, and if not, we start the application in a new process, and wait for it to be ready, for us to call it.
The issues introduced with Citrix
Now, when using Citrix Desktop Sessions, we do not suspect we will run into any issues, but with Application Sessions (AKA XenApp) the Citrix documentation states: "URL redirection works only for desktop sessions, not application sessions.", and we have therefor run into a brick wall with our implementation. So to sum up, we now have issues with accomplishing the following steps:
Registering a custom URI Scheme handler: That might not at all be supported. The way we use it now, it points to an application on disk, but the Application is installed on a server.
Detecting if an instance is running: We do not know if Global Atoms are even possible in this setup, and I have been unable to find any documentation on this.
Calling a XenApp window with SendMessage: When running the simplest XenApp configuration we could reproduce, we can inspect the hosting process and get the handle to our application, but the application never gets the message sent at it.
Solving it within the current solution scope
Can the above scenario be accomplished in a Citrix environment using Application Sessions? If so, how? The tests I have performed so far, appears to confirm my suspicions that it is simply not supported within this setup.
Solving it in similar fassion
The POC we have developed is simple and modular, and changing how instances are located and communicated with is easily implemented and made configureable to our clients specific setup. It will then require other ways of detecting, launching and communiting with the primary application.
Just detecting a running application has proven difficult (another question hat has not yet been answered), and the Global Atoms approach does not seem to work.
Launching the app if it is not running, is something I have pretty much given up on, given how many different ways the app can be distributed in such a setup, so it will probably have to be a requirement that the application is already running.
Even though I can retrieve what the handle is for the mainwindow, I am not able to use SendMessage either in a Citrix setup. It simply does not process the message I am sending at it. Is that also something XenApp does not support? I could not find find any documentation on this. Alternative ideas to call into the hosted application are very welcome.
In the end the solution(s) was extremely simple for our citrix customers, as they could either:
Open our software first, launch a browser window from within (we have various links that opens browsers), and navigation now works flawlessly.
Customize a hosted browser application, to run in the same server environment as our software, and then our POC was able to launch our software as though it was a regular desktop environment.
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
I've been away from web development for 6/7 years now and I'm completely lost in regards to how to do things. I'm going through some tutorials on HTML5 and whatnot, but I was hoping to get a helping hand here.
I'm trying to build a (POC) website which would have the "server" monitor it's running applications and when a certain application is running change the content of a hosted page. I don't want the model to be PageLoad->Application Check, I'd rather have something like ServerStart->ApplicationHook->Callback->Model->PageLoad->CheckModel, so a hook is put in place when the server starts and the callback of the hook updates a model which the page uses to update. Although this architecture may not be the best way, in general I'm just looking for a way to have a long running process which starts when the server starts up. Eventually I'l move this to a Windows service which calls a webservice when changes are made, but for a POC I'd rather keep away from multiple applications interacting, as the Windows Service would need to be "called" by the server too and I can't think of an easy implementation of that at the moment.
So, if you were building a page which relied on events on the server and needed to be able to interact with an application on the server separately to an individual page, but the page needs to be able to "post" information back to that application what would you do?
My explanation has been a bit all over the place, so I hope at some point my question has come across clearly! :)
Maybe there're alternatives but I think your only option for this kind of setup is a Windows service. If you need to talk to it from other components, have it use sockets or listen for HTTP requests on a known port. Doing what you described from a web application is not impossible but it'd be certainly very hard since it's the web server (app pool executable) that controls what happens in the process, not your code. In a Windows service, you're in control.
Edit: here's an article about the different options for hosting a web service - it seems to me that using a Windows service is, indeed, your best choice. You may be able to use a WCF service but you'll have to talk to a local application on the server and that part may be easier to do just using a Windows service.
Im working on application for Windows Server 2008 R2 (.NET 3.5.1) that would work even after cold reboot, without requring someone to log on any account on the server.
Few words about application itself, it is written in c# application for registering employees work time at the company. Users (employees), have thier cards which are beeing scanned by barcode scanner, each scan means either "work started" or "work stopped", everything is serlialized into xml file which is later on modified and put into .csv but that doesn't matter.
Barcode scanner is working as a keyboard, so all codes are beeing "typed" like from a keyborad, to the PC. I made application read the keys despite the fact that console application is not in focus, or not visible at all.
What i need to do is to make that application work even after cold reboot, it has to be fully automatic.
So far i figured out 2 approaches to do it, one is to create a service which would keep another process alive (if its not working, just turn it on), i didin't have much luck with this one, i have already created service that launches another process for me, but the process is working differently, if i would run it myself, there is no communication with the process so i cannot even tell if its the right one.
Another one is to just put my app into registery /microsoft/windows/current version/run, and enable autologon for user with limited prividges. This actually could work but it is not perfect solution, because after all we do not want to have user logged in on server in company 24/7 right?
I know that most of you are way more experienced in programming than i am, so i would appriciate any solutions how to solve my problem
Lichoniespi
Your options depend on physical security of the system (whether passers-by can do much to it apart from scanning a barcode), but let us assume that it is an easily accessible desktop. In that case, you probably do not want a logged in user.
Use the service approach. You do NOT need a separate process for accessing the keyboard. Create a global hook of type WH_KEYBOARD_LL.
Declare your callback function like this and put it into place with SetWindowsHookEx.
I would use the first approach, create a service, and to comunicate with the running application i would be using a network socket or pipe. For the service be sure that you're using an existing user account (not System) and allow it to interact with the Desktop.
I have a requirement that a Windows Forms C# .NET 2.0 program running in user-space (not a service) must always be running. As I'm not infallible and make coding mistakes, I wanted to know of any extra safeguards I could use to ensure this requirement is met. The things I've been thinking of are TaskScheduler to check it every 5 minutes, A stub watcher or a secondary process. Are these good / bad ideas?
Thanks,
Richard
EDIT: The reason I didn't use a service (the obvious and sensible answer!) was the program runs in a kiosk type environment and has has a heavy GUI component. The service option didn't work well across Windows 2000 - W7.
EDIT: The second reason not to use a service was the app needs internet access and on some of our customer sites, proxies are set up to only allow specific users (not the local system account) so it would be tricky to ensure access if multiple users log onto the machine.
Task scheduler is a cheap solution for this which does work. I use this to keep our Perforce Proxy server running (had some issues with the service), and so far there's been no problems - though now I've said that the server's probably exploded!
However, the most complete solution is a Windows service which invokes your app. You can make that service catch error return codes from the app, restart it on failure and notify you by email, which may help you diagnose and fix those issues. I think the Task Scheduler does something similar but it won't be able to provide as much insight into your application as a custom service.
If you're unsure of how to do that, then something like this should work:
http://www.codeproject.com/KB/install/csharpsvclesson1.aspx
There are three approaches that you can take:
Heartbeat Message.
A heartbeat is useful in a distributed application and is simply message that is sent (from let say a client to server) to confirm that it is still healthy/running.
Manager Process
A stub program, implemented as either a user process or a service. It launches the main application, monitors any unhandled exceptions, reports errors, and restarts on failure.
An exception guard on the entry point.
A try-catch-all in the application entry point.
I would recommend either of the first two options; the third option, the try-catch-all, is a particular nasty hack for the lazy and inexperienced programmer (IMHO).
I have successfully used both heartbeat and manager process in a large distributed application.
UPDATE
As for ready-to-go™ restart managers, take a look at the Windows API Codepack as discussed in Emmanuel Istace blog post (http://istacee.wordpress.com/2013/09/21/automatic-recovery-restart-in-net-application/).
You can install the package from https://www.nuget.org/packages/WindowsAPICodePack-Core/
I have a Windows service which I want to periodically execute an external program. I'm currently doing this the usual way
Process program = Process.Start(#"C:\mpewatch\db_parameters\DBParameters.exe");
This doesn't seem to be working. I'm executing this from a separate thread which is started in my service's OnStart handler. Is there any conceptual problem with this? Is it not possible to execute external programs from a service like this?
You can execute external programs from a service, but there are security issues. For example, your service may be running under an account which does not have read access to the folder where the external program resides, even if your interactive account does have that access.
For test purposes, try to configure the service to run under your interactive account. If the program is invoked as expected, then the problem with the original account is that it does not have sufficient privileges to run the program.
Your question didn't indicate the operating system.
On Windows XP, you can configure your Windows service to interact with the desktop by opening the service control panel, double-clicking your service, selecting the Log On tab, configuring the service to run as local system, and checking the checkbox. It's pretty straightforward. You might try testing with something like Notepad.exe just to see if you can get it working.
On Vista (and presumably Windows 7), however, you may be out of luck. I have read that the ability for Windows services to interact with the desktop has been removed in Vista. I forget what the terminology is, but basically services will run in "shell 0," whereas users will occupy "shell 1". User applications will be able to communicate with services and vice versa using technology like WCF, but services will not be able to communicate directly with the desktop. For example, any error boxes that pop up will have to be dealt with by swapping to "shell 0." Again, this is based on something I read a few months ago, and I haven't gone looking at it again. For me, I've structured my Windows service to be configured using WCF via a front-end app.
I'm sorry I don't have a link for you, but if your service will eventually have to migrate to a newer OS (or you are already there), this is something to check on.
Another critical consideration with Windows Services is that there is no GUI. Technically, there is an option to allow the service to interact with a local GUI, but you will not see it. This is due to services running as the Local System user.
Within a service, any modal dialog box (OK, Cancel, etc) is considered an error.