C# - web or winforms?
-
My initial interest in C# was due to the vast improvements it made in web development over classic ASP. However, for client apps I instinctively reach for C++ simply because of the years I've been doing it. I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios. Is C# / Winforms suitable for serious client side development, or does everyone tend to stay in a web browser?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
Christopher Duncan wrote:
using C# for client Windows app development
Yes, definitely. Apart from the spiffier controls, first class access to the .NET library is a welcome change. I've definitely noticed an improvement in my productivity - i.e. imho it's easier (and faster) to use C#/.NET to build a robust front end and concentrate on my app's business logic. /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
My initial interest in C# was due to the vast improvements it made in web development over classic ASP. However, for client apps I instinctively reach for C++ simply because of the years I've been doing it. I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios. Is C# / Winforms suitable for serious client side development, or does everyone tend to stay in a web browser?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
I've tried writing several client side apps with C# / Winforms and have almost always ended up throwing in the towel and switching back to MFC. One important note: these apps are not database centric. To repeat, these are not "business" apps. Just a few weeks ago, I tried porting an important applet I was working on to C# to see if provided any significant benefit. I ran into a problem which would have required very complicated P/Invoking. So, I chucked the feature an immediately ran into another problem. It was like a comedy where someone steps on a rake, turns and steps on another rake. I ended up tossing it and going back to MFC (which saved the company a measurable amount of money in terms of my time.) One problem is that C# is still missing a whole bunch of small things us MFC app developers have taken for granted. .NET 2.0 made big improvements in this area. I anticipate .NET 4.0 will make more.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
My initial interest in C# was due to the vast improvements it made in web development over classic ASP. However, for client apps I instinctively reach for C++ simply because of the years I've been doing it. I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios. Is C# / Winforms suitable for serious client side development, or does everyone tend to stay in a web browser?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
The SmartClient in .net 2.0 was the technology that moved our department to predominantly WinForms. We are C# 99.9 percent of the time with a brief venture into VB.Net in some .net 1.0 prototypes that went production. We use MVC and SOA extensively with the ability to move (for the most part) between ASP.net and Windows Forms if needed. We ask for justification for applications to be used on the web instead of Windows Forms simply because of the usability of the UI. The majority of the applications are less than 50 concurrent users and are very database centric business applications running on an intranet. The clients use a Outlook type application framework which loads the applications(.dll assemblies) using reflection. The purpose of this is security and ease of deployment. Early on the organization made everything web apps because it was stylish for management to talk about but the applications were not very user friendly. Last year we churned out about 11 applications with a strong level of acceptance from the business users and we are looking at least that many this year plus some that are rumored.
-
I've tried writing several client side apps with C# / Winforms and have almost always ended up throwing in the towel and switching back to MFC. One important note: these apps are not database centric. To repeat, these are not "business" apps. Just a few weeks ago, I tried porting an important applet I was working on to C# to see if provided any significant benefit. I ran into a problem which would have required very complicated P/Invoking. So, I chucked the feature an immediately ran into another problem. It was like a comedy where someone steps on a rake, turns and steps on another rake. I ended up tossing it and going back to MFC (which saved the company a measurable amount of money in terms of my time.) One problem is that C# is still missing a whole bunch of small things us MFC app developers have taken for granted. .NET 2.0 made big improvements in this area. I anticipate .NET 4.0 will make more.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Yeah, this is kind of the scenario I was suspecting. With MFC and C++, I have a language that won't tell me "no" regardless of what I'm trying to accomplish. However, there are much more jobs out there these days for C# than there are C++ / MFC. I was curious as to whether client side C# would be as fun as C++ always has been, or if it would be as incredibly limiting as browser based development. From your description, it sounds like even native app development with C# is still akin to working with one hand tied behind your back compared with C++. I'd truly like to get excited about the C#, but it's really hard to go backwards in power and flexibility.
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
-
The SmartClient in .net 2.0 was the technology that moved our department to predominantly WinForms. We are C# 99.9 percent of the time with a brief venture into VB.Net in some .net 1.0 prototypes that went production. We use MVC and SOA extensively with the ability to move (for the most part) between ASP.net and Windows Forms if needed. We ask for justification for applications to be used on the web instead of Windows Forms simply because of the usability of the UI. The majority of the applications are less than 50 concurrent users and are very database centric business applications running on an intranet. The clients use a Outlook type application framework which loads the applications(.dll assemblies) using reflection. The purpose of this is security and ease of deployment. Early on the organization made everything web apps because it was stylish for management to talk about but the applications were not very user friendly. Last year we churned out about 11 applications with a strong level of acceptance from the business users and we are looking at least that many this year plus some that are rumored.
KevinMac wrote:
Early on the organization made everything web apps because it was stylish for management to talk about
I suspect this is the driving force behind at least 50% of the web apps out there. I think you guys are right on the money in defaulting to native apps and requiring justification for browser based ones. HTTP was not intended to serve as an application development environment.
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
-
My initial interest in C# was due to the vast improvements it made in web development over classic ASP. However, for client apps I instinctively reach for C++ simply because of the years I've been doing it. I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios. Is C# / Winforms suitable for serious client side development, or does everyone tend to stay in a web browser?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
Heck, i've been using C# to write WinForms apps that host HTML-driven UIs in the Webbrowser control. Just 'cause i'm sick of writing UIs in procedural code. Of course, these are mostly internal apps, so it's not like having a slick UI is for anyone's benefit besides my own. Huh... that's two replies i've written today without actually answering your questions... :doh:
-
Heck, i've been using C# to write WinForms apps that host HTML-driven UIs in the Webbrowser control. Just 'cause i'm sick of writing UIs in procedural code. Of course, these are mostly internal apps, so it's not like having a slick UI is for anyone's benefit besides my own. Huh... that's two replies i've written today without actually answering your questions... :doh:
You're nothing if not consistent. :)
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
-
My initial interest in C# was due to the vast improvements it made in web development over classic ASP. However, for client apps I instinctively reach for C++ simply because of the years I've been doing it. I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios. Is C# / Winforms suitable for serious client side development, or does everyone tend to stay in a web browser?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
I have found C# and .NET 2.0 to be really easy and fun to work with. Sometime when you are programming away you may not be aware of a class or some API that you need that is in the .NET framework and end up using p/Invoke. I like C# more than C++ because it makes sense to me. Everything seem consistent and logically organized. I always found C++ to be confusing. cout << "Test"; Things like that just does not seem the correct way to make a console input/output class. Why is it named cout instead of something like ConsoleOut? Why do I have to use an overloaded operator when I could use ConsoleOut.Println("Test"); ? Why must they name namespaces "std"??? Thats why I like C#. Its clean, organized, logical, and it seems pretty fast for a managed language. C# even has full support for pointers.
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
-
Heck, i've been using C# to write WinForms apps that host HTML-driven UIs in the Webbrowser control. Just 'cause i'm sick of writing UIs in procedural code. Of course, these are mostly internal apps, so it's not like having a slick UI is for anyone's benefit besides my own. Huh... that's two replies i've written today without actually answering your questions... :doh:
-
Heh. Maybe someday. :)
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
My initial interest in C# was due to the vast improvements it made in web development over classic ASP. However, for client apps I instinctively reach for C++ simply because of the years I've been doing it. I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios. Is C# / Winforms suitable for serious client side development, or does everyone tend to stay in a web browser?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
Christopher Duncan wrote:
I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios.
I use C# exclusively for WinForm development. I haven't encountered any reason to miss MFC or C++.
Christopher Duncan wrote:
Is C# / Winforms suitable for serious client side development
I would say yes, qualified by what you mean by "serious". The only app I will continue developing in C++, and for that I'm hoping to migrate the UI and DB parts to C#, is a tool that analyzes switch rings for communication satellites, which needs to be as fast as possible. Even that though is best optimized by understanding the problem rather than hacking out a solution and hoping it runs fast enough. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Heh. Maybe someday. :)
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
I've had a play, just wish my computers were a bit faster then the designer would be more usable. But still they're power-houses compared to the stuff I usually write software for, maximum power one of those has was 40MHz. But then again, could you run a Core Duo off two AA batteries for 50,000 hours? :cool:
I have no idea what I just said. But my intentions were sincere.
-
KevinMac wrote:
Early on the organization made everything web apps because it was stylish for management to talk about
I suspect this is the driving force behind at least 50% of the web apps out there. I think you guys are right on the money in defaulting to native apps and requiring justification for browser based ones. HTTP was not intended to serve as an application development environment.
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
I have nothing against web applications but it seems that business users decided to apply them across the board as "what works" in every instance. Not trying to start a war here but I have seen the same thing with Java and MS solutions. I pointed out in a requirements meeting the other day that both languages are OO so saying all outward facing websites must be Java since they are more secure is not fact. I offered that it has more to do with how the languages are used that determined the security of the web site. Guess I will not be invited back but that is ok I was feeling a little lonely anyways. There are some really strange opinions in the business community regarding technology.
-
My initial interest in C# was due to the vast improvements it made in web development over classic ASP. However, for client apps I instinctively reach for C++ simply because of the years I've been doing it. I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios. Is C# / Winforms suitable for serious client side development, or does everyone tend to stay in a web browser?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
And some webservices only dabbling into the ASP.NET side when forced to. Personally Winforms is infinitely better then VB6 for client-side business apps. Even some hard logic apps and visualizations. In fact with Direct X and Open GL c# can be a potent game language as well. In fact with the ease of deployment and myriad of remoting options available I find it really amazing that people even want web apps anymore. (Ok, that goes to far because there are other OS'es)
File Not Found
-
My initial interest in C# was due to the vast improvements it made in web development over classic ASP. However, for client apps I instinctively reach for C++ simply because of the years I've been doing it. I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios. Is C# / Winforms suitable for serious client side development, or does everyone tend to stay in a web browser?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
I'm usng Winforms. It's just quicker.
Christian Graus - C++ MVP 'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
-
Christopher Duncan wrote:
I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios.
I use C# exclusively for WinForm development. I haven't encountered any reason to miss MFC or C++.
Christopher Duncan wrote:
Is C# / Winforms suitable for serious client side development
I would say yes, qualified by what you mean by "serious". The only app I will continue developing in C++, and for that I'm hoping to migrate the UI and DB parts to C#, is a tool that analyzes switch rings for communication satellites, which needs to be as fast as possible. Even that though is best optimized by understanding the problem rather than hacking out a solution and hoping it runs fast enough. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
I'm hoping to migrate the UI and DB parts to C#, is a tool that analyzes switch rings for communication satellites, which needs to be as fast as possible.
I would love to see more performance critical apps written in C#.
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
-
My initial interest in C# was due to the vast improvements it made in web development over classic ASP. However, for client apps I instinctively reach for C++ simply because of the years I've been doing it. I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios. Is C# / Winforms suitable for serious client side development, or does everyone tend to stay in a web browser?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
Christopher Duncan wrote:
Is C# / Winforms suitable for serious client side development
Absolutely.
Christopher Duncan wrote:
in a web browser?
That is to be avoided at all cost.
-
My initial interest in C# was due to the vast improvements it made in web development over classic ASP. However, for client apps I instinctively reach for C++ simply because of the years I've been doing it. I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios. Is C# / Winforms suitable for serious client side development, or does everyone tend to stay in a web browser?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
Both. Winforms is fine unless you are some sort of control freak who cares more about fiddling bits than getting the application into the end user's hands in good working order. I actually started with winforms and then moved on to asp.net. I think the whole concept of c# being first and foremost an asp.net thing is bizzarre in the extreme and I don't know where that idea came from in the first place. Maybe they were the earliest adopters?
-
Yeah, this is kind of the scenario I was suspecting. With MFC and C++, I have a language that won't tell me "no" regardless of what I'm trying to accomplish. However, there are much more jobs out there these days for C# than there are C++ / MFC. I was curious as to whether client side C# would be as fun as C++ always has been, or if it would be as incredibly limiting as browser based development. From your description, it sounds like even native app development with C# is still akin to working with one hand tied behind your back compared with C++. I'd truly like to get excited about the C#, but it's really hard to go backwards in power and flexibility.
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
I have never been told "No" by C#. The .NET BCL and WinForms often tell me no, but not C#.
-
Marc Clifton wrote:
I'm hoping to migrate the UI and DB parts to C#, is a tool that analyzes switch rings for communication satellites, which needs to be as fast as possible.
I would love to see more performance critical apps written in C#.
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
It has not worked well for me -- writing performance-critical applications on .NET. Regardless of what I did to improve performance, C++ always remain ahead by a large margin. Maybe, as Marc suggested, C++ could be used only for the peformance critical code.