What is best way to convert desktop app to web app?
-
BobishKindaGuy wrote:
Also, I want whatever I do to look way cool
No, you don't. You want whatever you do, done right. A working Windows 3.1-application will always beat an exception in Silverlight 6 in terms of usability. Make sure you produce a car that can be used for driving, before you start pimpin' it.
I are Troll :suss:
Eddy Vluggen wrote:
No, you don't. You want whatever you do, done right.
I hear you. The first priority is to produce a stable working model, then shine it up afterwards. But the shine must come before you show it to the world, at least in some environments, wouldn't you agree?
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
-
I work alone, and I have developed a huge desktop app, probably a quarter million lines of code, that has evolved for well over 10 years. I keep thinking it would be nice to convert it to a browser UI, but have watched many technologies go by, like asp, ajax, and now there's webmatrix, and sometimes I wonder whether I should take the leap, or whether it may cost me another 10 years to rewrite it for the web. It uses .NET remoting, and is multithreaded, so wcf and parallel programming come to mind as well. Fear promotes a lack of action, but knowledge defeats fear, so I thought I'd submit this general question to the "big team" out there in the code project universe. :)
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
Correct me if I am wrong, but it seems to me that web applications are mainly for publishing type of applications. In other words, if your desktop applications involve a lot of user interactions, then they may not be suitable for the web. Otherwise, it is not too bad to port them using either of the current available technologies.
-
If you don't like the xaml then forget RIA, seems to want to move everything into the xaml. Also the latest MS demos seem to lean almost exclusively to EF as the DAL, I find that distressing and chucked the entire RIA concept out. We are just about finished our MVVM code generator so we should be getting a bit more production. My first .net book was on Dotnet Remoting, trying to learn dot net and remoting from scratch, what a nightmare. Eventually someone slapped me and pointed me to an ordinary winforms app and I never looked back.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
the latest MS demos seem to lean almost exclusively to EF as the DAL
Sorry, what is EF?
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
-
When the app is well-structured into several layers (UI/presentation, business logic, data access), you could reuse most layers unmodified, and simply modify/add another presentation layer. If it isn't well-structured yet, now is the time to spend the effort. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
modified on Wednesday, July 21, 2010 9:18 AM
A well developed .NET desktop app should be easily ported to ASP.NET. You do however want to analyze the server requirements and the load that it may encounter. If it's a calculation intensive application (ie: Scientific, 3D graphics, etc) then it may be better as a desktop app.
-
If you don't like the xaml then forget RIA, seems to want to move everything into the xaml. Also the latest MS demos seem to lean almost exclusively to EF as the DAL, I find that distressing and chucked the entire RIA concept out. We are just about finished our MVVM code generator so we should be getting a bit more production. My first .net book was on Dotnet Remoting, trying to learn dot net and remoting from scratch, what a nightmare. Eventually someone slapped me and pointed me to an ordinary winforms app and I never looked back.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
someone slapped me and pointed me to an ordinary winforms app
If you get a mo, could you point me to some article or resource that exemplifies this experience? I would love to see that too. Slap me !!
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
modified on Thursday, July 22, 2010 1:06 PM
-
Eddy Vluggen wrote:
No, you don't. You want whatever you do, done right.
I hear you. The first priority is to produce a stable working model, then shine it up afterwards. But the shine must come before you show it to the world, at least in some environments, wouldn't you agree?
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
-
Correct me if I am wrong, but it seems to me that web applications are mainly for publishing type of applications. In other words, if your desktop applications involve a lot of user interactions, then they may not be suitable for the web. Otherwise, it is not too bad to port them using either of the current available technologies.
Cloud computing or SAS proponents would say the opposite. Salesforce.com would be considered very user interactive.
-
My question is: why is there such a huge gap?
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server.peterchen wrote:
why is there such a huge gap?
Please elaborate on what you mean by gap, since that is probably a question that needs answering.
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
-
BobishKindaGuy wrote:
I keep thinking it would be nice to convert it to a browser UI
Why?!? Why does everyone think creating a web app is the solution to every problem? :( :sigh: :doh:
Thin client apps are so much easier to administer. 1) Changes to the app don't have to be rolled out to 100's of possible users by installing something on their computer. Then when 98% of them are updated and you start getting calls from people who don't read email or don't click yes to update their software when prompted you start pulling your hair out. 2) No installation involved so it involves less helpdesk time. 3) Less worry that someone may leave your company with proprietary software on their laptop. 4) The ability to log in any where any time from any computer. 5) Less of a requirement for users to have high end computers because the load is transferred to a server or a cluster that is centrally managed. 6) the list goes on... I speak from experience having to currently support and develop desktop and web applications. If given the choice, 100% of the time I would prefer to make a web application from a support standpoint. The only time I would consider a desktop application is if it were something that was not used by many people, was calculation intensive and there were no spare servers available for it.
-
Why not just make it a Click Once "Smart Client"? Then you can keep it a windows application, but deploy it from the web like a Java Applet. You'll probably need very little code changes, it's more of a deployment option really and simple to implement. Unless you have a customer willing to finance the effort, it's probably not worth the massive amount of coding you'll need to do. You can do smart client in a day. The beauty of Smart Client apps is that you have a single install location (on the web server) to keep up to date. When the user clicks the icon, it automatically goes out to check for a new version and downloads it before starting up the app. It's really best of both worlds...
MachineGun wrote:
Why not just make it a Click Once "Smart Client"?
Hmmm! Do you have an article in mind that might help me analyze this option? Or would it be sufficient to wade through help do you think?
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
-
Reminds me of something I did several years ago with a VB6 application...seperated it into logical modules, made each module a user control ocx, then hooked them up on a simple web page. The customer wanted a web application, and that's what they got...an spplication that is run in a web browser (IE only though) but behaves as a desktop application. In addition, the web page and controls could be run in offline mode (not so critical these days) and updates were automatically downloaded to the client. This setup worked extremely well for many years.
Thanks for this suggestion, kmoorevs! Yeah, probably an easy to implement solution, but since this is a commercial app with lots of shiny UI, I doubt this would end up looking cool enough. I have no choice really - have to consider that aspect! But sometimes I wish I'd kept the whole thing in VB6 anyway - trying to surf all the changes over the years has probably been the most time-consuming part of my work. And for what? I wanted to "keep up with the times". Or - maybe I bought into the hype. But I must admit that VB6 alone may have led to some dead-ends, so maybe I did do the right thing. Good ol' VB6, gotta love it !!!
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
-
I work alone, and I have developed a huge desktop app, probably a quarter million lines of code, that has evolved for well over 10 years. I keep thinking it would be nice to convert it to a browser UI, but have watched many technologies go by, like asp, ajax, and now there's webmatrix, and sometimes I wonder whether I should take the leap, or whether it may cost me another 10 years to rewrite it for the web. It uses .NET remoting, and is multithreaded, so wcf and parallel programming come to mind as well. Fear promotes a lack of action, but knowledge defeats fear, so I thought I'd submit this general question to the "big team" out there in the code project universe. :)
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
I've done a lot of work in both web and desktop; mostly web though. I would seriously consider why you want to make this change. If you've made it 10 years, then I'm guessing it's not something that is urgent or needed. Sounds like more of a nice-to-have right? However, if web is truly something needed, then ignore my post ;) We all know the benefit of why people choose to write an app as a web app instead of a desktop app. But, what people often underestimate is the benefit of why people would choose to write an app as a desktop over a web app. Two HUGE things come to mind. First, is the responsiveness of the app. A desktop app will always be more responsive than a web app regardless of what some web zealots say. The other is the rich environment a desktop offers. The web is catching up here, but IMO still isn't as fully featured as a desktop app. Especially when you get into 3rd party controls like Infragistics... In fact, there's several internal apps at my work that are web apps that are SUCH a pain to use simply because they run in a browser. If they were just done as desktop apps, it would be so much better. On a side rant, with the improvements of RDP and VPN, I think making intranets apps web based is less important these days... If you feel like you need web, then I would consider what one of the posters suggested. That as, just start with small bits of your app as web.
-
I work alone, and I have developed a huge desktop app, probably a quarter million lines of code, that has evolved for well over 10 years. I keep thinking it would be nice to convert it to a browser UI, but have watched many technologies go by, like asp, ajax, and now there's webmatrix, and sometimes I wonder whether I should take the leap, or whether it may cost me another 10 years to rewrite it for the web. It uses .NET remoting, and is multithreaded, so wcf and parallel programming come to mind as well. Fear promotes a lack of action, but knowledge defeats fear, so I thought I'd submit this general question to the "big team" out there in the code project universe. :)
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
-
ely_bob wrote:
restructure your code base to enforce a presentation layer
My wife and I were discussing this last night, and that is exactly what I realized would be the first step! A windows form has 3 files, the resx (which is the pics, which a web page also fetches), the designer, which is the layout, which a web page also must generate, and a code file, which a web page also has. If I create that 4th file, a class that has all the real code in it, that is the file that will ultimately go on the server side.
ely_bob wrote:
pull all the presentation layer off into a separate solution
Hadn't thought of that point of putting it in a different solution. Perhaps you could share the motive for separating it to that degree. Excellent practical advice, thank you!
ely_bob wrote:
all the necessary controls displayed on that single form
Why a single form? I'm sure you are saying this from experience.
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
BobishKindaGuy wrote:
Why a single form?
Well this makes setting up the PageBase class easier and allows for placement of session variables(or however you decide to persist user info).. all this will happen as a approximatively 1-1 mapping from a single form.. (basically this will allow you to write less code in your webapp. The reason for a separate ui solution(s) is common in the XNA community, it allows/forces all the (business) logic to be centrally located, and is just a safeguard to taking the easy road as opposed to conforming to a set of best practices. this will also allow you to do a compare against your existing code base, as long as you follow the basic solution and page layout (can be very handy for debugging unexpected behavior).
I'd blame it on the Brain farts.. But let's be honest, it really is more like a Methane factory between my ears some days then it is anything else...
-
Correct me if I am wrong, but it seems to me that web applications are mainly for publishing type of applications. In other words, if your desktop applications involve a lot of user interactions, then they may not be suitable for the web. Otherwise, it is not too bad to port them using either of the current available technologies.
George from Saanichton wrote:
web applications are mainly for publishing type of applications
My feel for this is that, like it or not, things are generally moving to the cloud (the web). Whether that ends up benefiting humanity is another question. I'm quite cynical about the whole thing. But it's not so much what kind of app is suitable for moving to the cloud. In my mind it's about the IT people in an org. They want to adopt applications for their org that can be supported centrally, not on every user's desktop. So the browser is the ideal desktop app - it is conceptually a window into the cloud, where the real app resides, and needs no updating. When there's a version update, the app vendor (me) just sends them an update to the app on one of their servers. The user receives the benefit of that the next time they launch the app using their browser. There are other benefits (and drawbacks) too, and CodeProject and many other sites are full of those discussions I'm sure. Thanks for taking the time to share your thoughts on this!
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
-
I work alone, and I have developed a huge desktop app, probably a quarter million lines of code, that has evolved for well over 10 years. I keep thinking it would be nice to convert it to a browser UI, but have watched many technologies go by, like asp, ajax, and now there's webmatrix, and sometimes I wonder whether I should take the leap, or whether it may cost me another 10 years to rewrite it for the web. It uses .NET remoting, and is multithreaded, so wcf and parallel programming come to mind as well. Fear promotes a lack of action, but knowledge defeats fear, so I thought I'd submit this general question to the "big team" out there in the code project universe. :)
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
Have a look at the MVVM pattern that is in common use in WPF coding. It's basic selling point is that it completely separates the UI from the business logic. You could re-code separate pieces of the app over time, with no change on the UI. This would allow your users to act as a last line of defense against UI-breakage ("Hey, after the last update, XYZ broke"). Then, when you're finished with this separation, your Web UI will be a mechanical process of coding UI's for each piece. You said that the app is multithreaded. Does that imply that it is computationally intensive? All business logic will be centralized so your server will have to be beefy enough to deal with it.
Before .NET 4.0, object Universe = NULL;
-
Thin client apps are so much easier to administer. 1) Changes to the app don't have to be rolled out to 100's of possible users by installing something on their computer. Then when 98% of them are updated and you start getting calls from people who don't read email or don't click yes to update their software when prompted you start pulling your hair out. 2) No installation involved so it involves less helpdesk time. 3) Less worry that someone may leave your company with proprietary software on their laptop. 4) The ability to log in any where any time from any computer. 5) Less of a requirement for users to have high end computers because the load is transferred to a server or a cluster that is centrally managed. 6) the list goes on... I speak from experience having to currently support and develop desktop and web applications. If given the choice, 100% of the time I would prefer to make a web application from a support standpoint. The only time I would consider a desktop application is if it were something that was not used by many people, was calculation intensive and there were no spare servers available for it.
Well put, MatrixDud ! Now if only what you said had been part of a course in high school, my app would have been in the cloud long ago! But I went down another road and now, I've got this huge pile of (cool) code to push around into other smaller piles, I guess. :-D Thanks for taking the time to share your very relevant perspective to this discussion! Bob
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
-
I work alone, and I have developed a huge desktop app, probably a quarter million lines of code, that has evolved for well over 10 years. I keep thinking it would be nice to convert it to a browser UI, but have watched many technologies go by, like asp, ajax, and now there's webmatrix, and sometimes I wonder whether I should take the leap, or whether it may cost me another 10 years to rewrite it for the web. It uses .NET remoting, and is multithreaded, so wcf and parallel programming come to mind as well. Fear promotes a lack of action, but knowledge defeats fear, so I thought I'd submit this general question to the "big team" out there in the code project universe. :)
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
You have already received lot of nice replies. I hope mine too adds something. BTW I am a windows forms fan so I would avoid doing this. 1. Your application must be divided in to layers I suppose. So reuse existing code after refactoring. 2. Do not try and achieve similar experience in UI as in windows application. It will be tough to give similar experience. 3. If it is related to some business process, have a look into work flow as well. 4. Do not forget to rewrite what deserves to be rewritten. 5. You can use use WCF but do not think of replacing remoting with that, try and make it SOA compliant for in future, you do not need to worry much.
-
BobishKindaGuy wrote:
But the shine must come before you show it to the world, at least in some environments, wouldn't you agree?
I'll agree that there are environments that judge a car by it's paintjob :) Good wine needs no bush.
I are Troll :suss:
Yeah, I hear ya! But a few years ago, I was in the market for a car, and I did hesitate to buy the Lada. Could have been a good car, it even shipped with a toolkit so you could fix it yourself. But something about it didn't inspire confidence. Philosophizing here: What we really need is a "car", instead of all these throwaway junk boxes. Capitalism! Competition! It's creating huge scrap heaps! Whereas "cooperation" would produce a nice solid, reliable, simpler, and durable product, like say a stainless-steel car. I think it's similar here. What we need is a reliable product, not a glitzy one. But some of the grace built into a product to make it look cool also can end up making it seem more intuitive to the user. I've always put a lot of thought into the UI. Maybe too much, and I'm sure your comment is meant to help us balance the two concerns. I am listening!!
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
-
MachineGun wrote:
Why not just make it a Click Once "Smart Client"?
Hmmm! Do you have an article in mind that might help me analyze this option? Or would it be sufficient to wade through help do you think?
____________________________________________________________________________________ The Vulcan Science Directorate has determined that time travel is impossible.
This is a good overview of what a Smart Client is: http://msdn.microsoft.com/en-us/library/ms998468.aspx[^] This is a starter how-to: Click Once Deployment Technique[^] This article is missing one huge step though - Signing your app with a certificate and running the MAGE.EXE command on the deployment server. It'll work in VS, but then when you move it to a real web server, you have to include the certificate file and then run the MAGE commands to "certify" it on that machine. For instance; Say your application is called "BobsApplication" You would copy up the deployment files that VS outputs AND the certificate file (.pfx) that you need to generate under the "signing" tab. (in the Project->Properties->Signing tab), and the MAGE.EXE program up to your web server. You can put the cert. file and mage.exe in the same folder as your application. Then run the following MAGE commands at the DOS command line: mage.exe -Update BobsApplication.application -pu http://YourServerName/BobsApp/BobsApplication.application mage.exe -sign BobsApplication.application -cf BobsApplication_TemporaryKey.pfx ** Where BobsApplication_TemporaryKey.pfx is the certificate file that you generated under the Project->Properties->Signing tab. I also assumed you created an aliased folder in IIS call BobsApp in the first mage command. MAGE.EXE comes with Visual Studio, you can find it in the SDK folder (C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin) Then, to Run your application, you would go to the browser and type: http://YourServerName/BobsApp/BobsApplication.application I would also search Google for something like: "Building your first ClickOnce application" or "Building your first SmartClient application" Hope that helps!