|
Wow, thanks MachineGun, for going to all that effort - excellent reply!
I recently implemented an auto-update feature in my app, based on this article:
Application Auto Update Revisited[^]
The main app checks, downloads the update, and if that all goes well, launches another app. All the second app does is replace the main app's executable, and then launch the main app.
It seems to be working. I used that because I read some negative stuff about ClickOnce, I forget where. But I wonder whether you have a comment on whether the procedure you have outlined in your message has some advantages in your opinion.
Thanks again for the reply! I will analyze it! I noticed there was some command line stuff to do. I guess the VS installer project could implement that somehow. This is a commercial app, where I would prefer that the installer does everything so the IT folks don't need to do any tweaking. But that is only from a quick perusal of your post. As I say, I will take the time to read the references you included.
Bob
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
Take a look at visualwebgui.
There's a screencast transforming a winformsapplication to a webapplication with their
softwarestack. 
|
|
|
|
|
Thanks Ralph.Popp!
I went right away to the site and visualwebgui does look quite painless. The price is right too.
Now this discussion was started to discuss strategies for making my app be a browser app, so please don't be annoyed if I include some philosophy here -
Maybe I'm wrong, but I'll bet their product requires me installing their dlls on my customer's server. Just so you see the workings of my tiny cynical mind: Since the visualwebgui folks are on version 6.4, that means they had versions previous to that, and in all likelihood, will also have versions 6.5, 7.1, and so on. My concern is that if I don't have the source code, I become dependent on other developers outside my "team of one" when there are problems with compatibility. Then my customer is mad at me, and then I have to get mad at the visualwebgui people, and of course then the problem escalates, and I end up sneaking around at night in my black ninja outfit, getting revenge by letting the air out of their tires. Ha ha. But seriously, I really try to do it all myself if possible. That philosphy has served me well, although at the cost of my time, a lot of it, which I realize could be saved through using a more "convenient" 3rd party app. In fact the same goes for those devexpress free controls. I can't use them, cool as they are, because I have no control over the source code.
Let me know your thought on this, if you see a gap in my reasoning, and thanks again for your reply.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
I would say before you dive in, restructure your code base to enforce a presentation layer, and if feasible (or not already accomplished) pull all the presentation layer off into a separate solution. this will make the development of even code behind faster. if you can, get everything scrunched down to one form, with all the necessary controls displayed on that single form.
once you've accomplished this the mapping of winforms to webpages is quite simple (and if your comfortable spending about a week slopping code around flagrantly) you can etch out a crude close approximation first gen WebApp rather quickly. Really the "functional template" has already been written (legacy code) and you want to float a new UI on it, so Hack together a minimal UI (in appearance only) and then focus on getting everything to stitch together...
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...
|
|
|
|
|
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...
|
|
|
|
|
Thanks again, ely_bob!
I have quite a few tabbed-dialogs and wizards.
What do you think of the idea of a webpage that aligns those vertically so the user work their way from the top down?
There's a notepad replacement app that does that, and it looks really cool. (Of course, that app is a desktop app ha ha ha)
Regarding the separate solution for the UI, do you mean separate project or separate solution completely?
Either way, I guess the code in the form would look something like (air-coding here):
Public Class WizForm1
Private m_UI_Handler As SomeUIHandlingProject
Private Sub Done_Click (e,sender) Handles btnDone.Click
m_UI_Handler.WizForm1_Handlers.DoneClick
End Sub
End Class
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
modified on Thursday, July 22, 2010 5:35 PM
|
|
|
|
|
well Personally I hate to do more vertical scrolling then absolutely necessary...
I'd recommend either a presenter approach (the page reloads with what you want to present) or use a layout similar to what you describe, and use tags to hide/show just "like" you would be doing in a tabbed document(this makes layout easier and I prefer the approach because it is a lot more straightforward.)
If the wizard is a fundamental part, you may want to treat that as a flash app(however I am not familiar with these approaches), that way you can take control of the entire screen, grey out the background browser, and have a specialized solution just for your wizard. and this would be plug-able into your webapp...so...
I meant a one solution with ~3 projectss, a library(or folder of libraries), and 2 UI: winforms & webapp. then if you want to make some kinda mobile app down the road you can just add it to the solution, and add some dependencies and probably reuse a lot more code that way...
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...
|
|
|
|
|
Cool!
Your suggestions are definitely part of the solution to this problem. Isolating the UI from the rest of the logic, still within the desktop app, will make it a lot easier to move everything to a web app. The hurdles I encounter during this process will probably force me to think it through with the web app in mind. (E.g. passing certain parameters along with the call, etc.)
Thanks for taking the time to make these suggestions.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
I've been intrigued by Morfik. I was "forced" to learn TurboPascal to support manufacturing systems and that migrated to Delphi which I use for my own personal work apps (nothing commercial). The ability to reuse a large part of the existing code is very attractive to me but I haven't really studied Morfik in depth to see how easy/hard a conversion could be.
Just a thought...
|
|
|
|
|
|
Machaira wrote: Why does everyone think creating a web app is the solution to every problem?
Good question! I wish I didn't have to consider it.
But there are some good reasons. See my answer to Ray Cossack.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
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. 
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.
|
|
|
|
|
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.
|
|
|
|
|
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'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.
|
|
|
|
|
|
Bindows!
Interesting!
Thanks, squeek, I will study that.
____________________________________________________________________________________
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;
|
|
|
|
|
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.
|
|
|
|
|
Thanks very much d@nish!
d@nish wrote: You can use use WCF but do not think of replacing remoting with that
It sounds like you have had a problem that leads you to this conclusion, am I right? My app is heavily using remoting. I was under the impression that WCF was supposed to do everything remoting does. Also, could you please expand the acronym, SOA, I'm not familiar with that.
When you mention "work flow", I assume you mean using visio or similar.
Again, thanks for taking the time to provide such a thorough reply.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
Sorry for the late reply.
BobishKindaGuy wrote: It sounds like you have had a problem that leads you to this conclusion, am I right?
No. All I am saying it do not restrict it to remoting. If you rewrite things as a web service, your application will become network independent. You can then very well use it with clients in other technology as well.
BobishKindaGuy wrote: Also, could you please expand the acronym, SOA, I'm not familiar with that.
It is Service Oriented Architecture. Maybe a quick read on MSDN would help understanding.
BobishKindaGuy wrote: When you mention "work flow", I assume you mean using visio or similar.
With .Net 3.0 and above, we have Workflow Foundation. It suites if your application deals in business processes. Something like leave approvals where you have a series of dependent activities happening with human interventions here and there.
|
|
|
|
|
Thanks again, d@nish,
I have considered a webservice in the past, but to create a responsive interactive experience such as is possible with two-way remoting, would be difficult with a webservice, since the client would be "pinging" the webservice way too often. Or maybe others have achieved that... It certainly would simplify things though. Thanks for the clarifications on SOA and workflow foundation. I'll look into that.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
