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.
Related
Hi i have a C# WinForms app. I wrote essential methods on C#. But I need a login form and its not safe since apps like dotpeek can inspect the source code and hack it. Can i communicate with another application that is written in another language (java,c,python etc). I need to send input data from WinForms C# to another app then it should connect to database and check if login succesfull then return a value back to C# WinForms app. Is that possible, how can i implement that? I dont want to write all application in another language since C# has good methods to process images/pixels and gui support with very small memory usage.
I got the point you are trying to make.
One thing to admit is that you can't completely avoid decompiling of apps. C# or C++, no matter anything can be reverse engineered.
If you still need it, a comparatively safer approach is to not put the checking app at the client's machine. Create an API and host the database on a server.
Then initiate just an Http Request to the server from your Windows Forms app.
Then you have the full control of Login API and database. Many applications use OAuth similar to this. Another examples are apps verify it's license using an online API.
You can get a LightSail Windows server in around $10 a month if you want to setup. Try exploring
Your concern is not baseless. C#, or for that matter, any .net language running on the CLR, will be easier to inspect than a language like C or C++.
Having said that, no app will be completely secure, and communicating between apps has its own problems. How does one app verify the other? etc. You can create a web service that would communicate with the database (and communicate with the web service using HTTP or WCF) which would mean your app wouldn't have direct access to the database, but that would only protect the database from your app, it would still allow someone to inspect your app and use the web service, impersonating your app. Also, you would need to host the web service on some web hosting service, and then you would have to trust that service to not inspect your app...
You can reduce the problem by storing the password etc. as byte arrays, but regardless of what you do, I don't know of a way to completely safeguard your app. If a malicious app/actor is on your computer they can inspect your app.
As for your question itself - look into WCF or named pipes (includes a simple example).
I've been developing an application that interfaces with PowerShell for Windows. So far, everything has worked great. However, it connects to MySQL directly (I guess that's not good practice?) and also connects directly to the local PowerShell instance. My goal for the future, however is to make it cross platform. I currently purchased a book on cross platform development (mono based I believe) to get a handle on have a best practice common services layer for some basic things. However, I can't get my head around how I'll do that with PowerShell.
My question is, is there a way to host a server somewhere that accepts Powershell connections remotely via web requests from multiple connections at once? Otherwise, I don't see how I can port such an application to Android and the likes.
Also, I wouldn't be opposed to some basic links for best practices on web requests and the likes.
Have a look at PowerShell Web Access.
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.
I have a question that is perhaps slightly towards architecture and design rather than syntax problem....
I have a c# winforms app on my desktop which I have built which is similar to a CRM. I make updates to customers records as they submit orders/invoices etc and what I would like to do is to build (or buy) a module that will update a remote database that sits behind a website onto hich registered clients log in. I want the clients to be able to see the status of their invoice/purchase etc as I have updated it on the winforms app.
I can think of a couple of options of the top of my head but would like to know more if you have done something similar
Things I am considering are;
>Replication - I think this is overkill as the updates are not
huge, are one way only, and not
critical they are in real time, and
also I am running SQL express on the
winforms app. This can be changed
but rather not
>create a text/xml file that gets created and uploaded to the web
server to a location that is
monitored every 5 minutes and then
updates the web database. - I am not
hosting the website myself so I do
not have complete control over what
I can install but I suspect I can
install a .NET 'filewatcher'
Anyway, I would appreciate your thought on my 'problem'
thanks
I think your best bet is to create a web service of some kind (I like using ServiceStack.net to create simple REST ones, much cleaner imo than WCF). This will sit on the server and be responsible for the server-side sync piece.
On the client, you could either have the winforms app fire off the call to the web service based on some threshold of activity, or you could have a windows service that you install with the winforms app which does it in a scheduled job or on a timer.
You'll want to be sure that you're doing all your calls over SSL of course, and make sure you're authenticating the clients, but that's the basic architectural approach I'd take.
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.