Develop Reference

How to navigate from browser to application in Citrix

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.

Access local DB on user pc from a remote application running on "Azure Server"

I am fairly new with MS Azure and developing remote apps.
Have read and viewed some learning stuff.
I use c# as my developing language, and as I have understood, its fairly simple to develop a windows application to run on an Azure server as remote app, which users anywhere on earth can run from their pc as if it was installed locally on their pc's. But in reality, it is more like, an RDP hiding behind the app.
The problem is that a database will be running on every users pc instead on the azure server. It is suppose to be like that by design, don't ask me why.
We tend to use "ms access" for the local DB, since everyone already have MS Office.
Anyway, back to the problem. What I am wondering is, how can I make my remote application on azure server communicate with the database installed locally on user(s) PC?
I have drawn a simple figure to explain what I mean.
http://snag.gy/ybyed.jpg

Back in the days when people used Modems to connect their PC's to the tubes, this would be theoretically possible (although maybe not a good idea). Nowadays, very very few PC's are connected directly to Internet.
In an Office, a PC will be connected via the company intranet to an external gateway and the PC will not be visible to anyone outside that gateway. The same is true at home, where the gateway is the router.
It would be possible with a lot of work to allow external access (from Azure) to the individual PC, but it would not be easy to set up. Further, you would need to write a piece of software to run on the PC which will listen on the correct Port for calls from Azure, will then run the appropriate SQL queries, and return the data to Azure. You might as well install SQL Server full edition on each PC.
Even if you do that, no security professional is going to let you actually open up the ports and firewalls to the internet; it's a lot of work doing that and you might as well just install random viruses on the PC - you'll get to the same point but faster and with less wasted time.
TL;DR: Not easy without a significant investment, and your PC will probably get trashed if you do.

This is actually possible by the magic of RDP protocol :)
Azure RemoteApp supports redirection for Windows machines as documented here: https://azure.microsoft.com/en-us/documentation/articles/remoteapp-redirection/
So, once you create an Azure RemoteApp collection, you can download the PowerShell cmdlets, enter your subscription ID and then you can enable drive redirection. This results in the local disk being mapped on the remote machine. You can try it out and see if performance is good enough.
The other alternative is that the database lives in an Azure storage account, as documented here: https://azure.microsoft.com/en-us/documentation/articles/remoteapp-anyapp/ .
You should NEVER store data on the Azure RemoteApp local machine.
/cd

online database for C# window application

I'm going to develop a POS system for medium scale company
and the requirement for me is to make all data on time for all of their branches
while in my mind, move the server from local to web would solve this problem
but, i never done any online server for window application
may i know what is the best option for use as secure database ?
such as SQL can handle this well ?
i tried to google but all of the result return is not what i want
may i know what will you do when you facing this problem ?
my knowledge on coding is just VB and CS
also SQL for database
i would like to learn new if there is better option
i hope it is impossible to access by anonymous and it is store secure at back-end only

What you probably want to do is create a series of services exposed on the internet and accessed by your application. All database access would be mediated by these services. For security you would probably want to build them in WCF and expose them through IIS. Then your Windows application would just call these services for most of its processing.
If you design it properly you could also have it work with a local database as well so that it could work in a disconnected manner if, for example, your servers go down.

Typically you don't move the server off of the site premises.
The problem is that they will go completely down in the event your remote server is inaccessible. Things that can cause this are internet service interruption (pretty common), remote server overloaded (common enough), basically anything that can stop the traffic between the store location and your remove server will bring them to their knees. The first time this happens they'll scream. The second time and they'll want your head due to the lost sales.
Instead, leave a sql server at each location. Set up a master sql server somewhere. Then set up a VPN connection between the stores and this central office. Finally, have the store sql boxes do merge replication with the central office. Incidentally, don't use the built in replication, but an off the shelf product which specializes in replicating sql server. The built in one can be difficult to learn.
In the event their internet connection goes dark the individual stores will still be able to function. It will also remain performant as all of the desktop app traffic is purely to the local sql box.
Solving replication errors is much easier than dealing with a flaky ISP.

I would recommend you to check Viravis Platform out.
It is an application platform that also can be used just as an online database for any .NET client with the provided SDK. It has its own generic windows and web clients and some custom web solutions for some specific applications.
You may be using it as a complete solution or as a secure online database backend.

Distributed application (WCF/Remoting/web servervices) Vs Web application

I am making a medium sized standard LOB application. Currently its a web application but I am formulating a proposal to revamp it into a Desktop remote application. By this I mean that the database and the application server will be hosted in a remote location. The client application will communicate with the server via the internet through (either WCF / Webservices / Remoting).
My question is this: The only reason I am shifting this from a web platform is due to the constraints of the web (I dont want to do AJAX or Java scripting to minimize those constraints, so please no JS/AJAX recommendations). I have made traditional desktop applications and they are considerably fast but i have never made a remote or a distributed application. I am not sure weather the speed of the application will be faster then the web or not.
As I understand it, the remote desktop application would be much faster. For one, there wont be any post backs involved, (I hate them so much). The data will obviously come via internet, so in that respect, is it better to shift to the remote desktop just for sheer speed and power?
Any help in the right direction would be greatfull. Many thanks.
Zeeshan

I think biggest advantage of desktop clients over web applications is freedom in UI design, and you don't have to worry about any inconsistencies in the client environment, although those are not an issue if you are using a client that runs on silverlight.
Personally I don't like web applications that requires a lot of user interaction, there are some of them that is a pleasure to use but I think it is very easy to do it the wrong way and end up having a buggy or not so responsive application (probably because of the incompatibilities in browsers, I have IE, Firefox and Chrome installed on my computer and I use one for some websites because they run faster on it, and others for other sites because web pages show up correctly only on them). Though this might not be an issue for a silverlight client.
In case of network speed, depending on the things that goes on the wire even with binary serialization remoting might have quite a bit of overhead. For example along with the data it writes full class names, library names and their versions so it can get pretty big and slow even for small amounts of data (although it should still be smaller then HTTP). It also has the same problems that HTTP has over unreliable connections because it uses a similar protocol. For one project we had to write a custom serializer for some objects because binary serialization alone was generating 200K, but our custom serializer for those objects were generating 50K. Then we ended up writing our own network protocol because the one that comes with the runtime was frequently stalling over unreliable wireless networks, and remoting doesn't give any control on the socket created by it (which makes sense in terms of encapsulation but you can't close it and force it to open a new one).
(I am assuming that you are asking about remoting vs web app. not remote desktop vs. web apps, because of your note about post back, you can't avoid it with a remote desktop session)
Rewriting an application just for sheer speed? No, because probably user won't see much difference in response time.

You are somewhat ambiguous with your terminology - do you want a client app that runs on the user's machine, or do you want an app that runs on the server and the user connects via remote desktop (RDP)?
If you are talking about a client app that communicates to the server via WCF etc., then yes it will be faster than a standard web app, although it will still be slower than a native desktop app. It will be faster than the web app not just because of the lack of postbacks, but also because you will be sending pure data through the wire, not a massive amount of HTML/Javascript combined with your data. With a client app, you have several options so consider them carefully - do you want Silverlight, WPF, or a native WinForms app? Each have their positives and negatives.
If you were talking about having a client app running on the server which the user then access via RDP, then you have other considerations to think of. For any more than two concurrent users you will need to consider buying CALs so the users can connect to the server. At this point you should also be considering whether you should be running a terminal server or Citrix type setup instead of using remote desktop.
Edit
When using WCF over a WAN (internet) you will certainly have to consider how you will secure it. WCF makes it trivial to secure the channel, but you need to consider how you will do authentication - there are a couple of different ways, but you can easily google that stuff yourself. The method you choose will be important due to the limited resources or skill-sets of the users.
As for what you write it in, you can't argue with Winforms if that is where your experience is. Personally, i would never again use ASP.NET/Ajax/etc for a web type application, it would be WPF or Silverlight all the way (i would only use ASP.NET for simple web sites). You can use the express (free) versions of Visual Studio to write it in, you don't need Expression (it's just a nice to have, and is more aimed at the design side than the actual coding side). Deploying the app need not be difficult - Silverlight or WPF xbap are delivered via the web, the user has to do nothing (except for the simple install of the Silverlight plugin or installing the right .Net framework for WPF - check this link). Winforms or stand-alone WPF require slightly more work, but you can avoid most issues by writing a good installer.
Whichever you choose, make sure you don't under estimate the time for development (because you will have a bit of a learning curve), and also make sure you budget enough time for testing it - especially the security side of it :)

I have been in a similar situation, although started with a Winforms LOB application.
Heres what we found with WinForms...
It's going to be harder to deploy in your release cycle, to all client machines.
WinForms can't be run on other operating systems easily. (with the exception on mono)
WCF endpoints can get complicated, and you need to manage an endpoint for release/version of your application.
Authentication, Authorization and Security can be tricky to get right!
Heres why you should stick to a html web application.
it's going to be easier to deploy, as you just need to copy one set of DLL's into the bin folder. Can be scripted from a continuous integration or staging server.
Security is going to be easy, by using a SSL certificate.
Silverlight/Flash should fill in the gaps that HTML leaves out.
Microsoft has also combined the connected systems in .net 3.5, they now call it WCF (ASMX/Remoting/etc...). It's got quite a learning curve 4-5 weeks.

Windows App (One Click) Vs Web App

We are moveing our old Access VBA / SQL 2005 application to new technologys and have 2 options do we build a Windows Form Application with Microsoft One Click Deploy or a ASP.Net Website?
The application is a work force mangement system booking jobs dynamic scheduling gantt chart components. It will be used by 400 + Users over 20 Locations.
Can you give me some feedback on these options.

If you want the application to be maintained in one central location and accessed by the users over the web...go with a web application. If your team is more familiar with Windows Form applications, there's going to be a learning curve involved with this option (maintaining state, dynamic controls, page events, the DOM, etc.) so the time investment is going to be greater.
If you want the clients to have a rich interface installed on the desktops that you can manage easily from a central location...go with Windows Forms (or WPF to provide a nicer user experience). Using ClickOnce for deployment will make sure that the client applictions stay up to date. It sounds like this would be the more familiar option for your team and produce the best product in the shortest amount of time.
If your users are all inside your corporate network, either option can use a central SQL Server database (or shared Access/SQL Server Compact Edition/SQLLite database).
Don't get caught up in the hype. Web appilcations aren't always the best option.

I would create a web application. This will provide the benefits of a central location to manage. With 400+ users and 20 locations a windows app will take more time and headaches for updates and maintenance.

Provided all your users have good bandwidth to the hosting site (10mb at least) then the port route to a Click-once app is probably the easiest, and should give your users the shortest learning curve.

Have you looked at silverlight as an option? This will give you the benefits of a web application but will allow you to create a richer UI.

I have deployed a ClickOnce app to over 110 locations with 500-600 users, and ClickOnce does a nice job handling deployment, maintenance and updates. A couple of things to keep in mind:
ClickOnce apps still are software running on users' machines rather than in a browser, so even though in most cases it is just as easy to support as a Web app, there will be occasional maintenance problems you won't normally have to support with a Web app (corrupt registry, local machine security snafus, hard drive issues, etc.). You also have to maintain certificates for the ClickOnce assembly permissions, which is an additional area of administration/support.
With the advent and gradual maturing of Silverlight and better AJAX tooling, the UI gap between Windows and Web is getting smaller and smaller
The bigger your app gets, downloading of updates can take some time, particularly at remote locations that may not have the fastest network access speeds.
You will need to weigh the benefits of deploying a Windows solution over a new Web one; in our case, the application we were replacing was a Windows app, and we wanted to reproduce a lot of the screens and workflow to look/act the same as the older version for productivity and training purposes, so we picked ClickOnce. I don't have any regrets, ClickOnce worked well for us.