C# - web or winforms?

[Lost User]

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.

[Michael P Butler]

Christopher Duncan wrote:

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?

I use C# mainly for Windows App development. I've never had any real issues and built several serious business applications using it. My one pet peeve, is that the UI is defined as imperative code rather than declarative. So a lot of my apps used MyXaml for defining the UI. I used to be a hard-core MFCer, but now I rarely touch it for desktop apps. C# and .NET has given me a wonderful toolset for building my kind of applications. I also use the Smart Client Application Software factory a lot now to give me a good solid application framework.

Michael CP Blog [^] Development Blog [^]

[Stuart Dootson]

Joe Woodbury wrote:

It was like a comedy where someone steps on a rake, turns and steps on another rake.

That'll be Sideshow Bob[^], then...well, it was that episode that I immediately visualised when you mentioned stepping on a rake :-)

[ednrgc]

I use C# for web only. I avoid C# for windows apps at all cost. For windows apps, there is (still) nothing that beats Delphi. It needs no runtimes. It's just single exe. Copy to another machine, and it works fine.

[Christopher Duncan]

John Cardinal wrote:

I think the whole concept of c# being first and foremost an asp.net thing is bizzarre in the extreme

Just a guess, but it probably came about from the first version of C# / Winforms. Version 1.0 of anything usually leaves a lot to be desired, and back in those days it wasn't a given that the .NET framework was installed on a machine. So, it wasn't an obvious out of the box replacement for MFC. On the web side, however, the difference between classic ASP and C# / ASP.NET is nothing short of monumental, making web development almost feel like real programming. In any event, it's good to see so many people I respect using C# for desktop development. Perhaps it's time to find that old bathing suit and take a deeper plunge... :)

Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com

[Jasmine2501]

Having gone through this myself, I'm gonna say it's a case of being used to doing things in wrong, screwed-up ways in MFC. Then when you try it in C#, the method is totally foreign to you, and C# will not let you play your old games, at all. In a lot of cases, you simply can't do things the old way, and this freaks out a lot of programmers, who then go off and say C# sucks. Yes, some things are different in C#, requiring you to take a new approach. When you re-think the problem and try a more object-oriented approach, usually the C# way ends up being much more elegant.

"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for freeware tools and articles.

[Jasmine2501]

Christopher Duncan wrote:

My initial interest in C# was due to the vast improvements it made in web development over classic ASP

You make it sound like C# is a web programming language. It's not. It's one of the languages you can use with ASP.Net, but as a language, C# stands on its own.

Christopher Duncan wrote:

how many of you are using C# for client Windows app development

I am using it for that, and for several other things, a screensaver, a link-checker and sitemap tool, and a DB-enabled customer service app for a loan company. See my web site for examples.

Christopher Duncan wrote:

does everyone tend to stay in a web browser?

C# has very little to do with that. It is a fully featured language all by itself. It is associated with programming libraries like ASP.Net and .Net Frameworks, but it's not tied to those permanently. The choice to do something as a web application is driven by other considerations, and a desire to use C# should not affect that decision too much.

"Quality Software since 1983!"
http://www.smoothjazzy.com/programming.html - freeware tools and articles.

[Member 96]

We have a very large, very successful commercial application that is written in c# and has a winform interface, an asp.net interface, remoting, an accounting application interface and is used globally in over 50 countries, but I won't anger the lounge gods by posting a link to it here. ;) Suffice to say there is really no good reason not to use C# for most desktop apps these days. Even Linux and Mac platforms are supported through MONO.

[Christopher Duncan]

I assume you have your business and communication logic in one layer and simply designed two separate UI layers for the desktop and web interfaces?

Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com

[Mardanian]

My personal experience... I've been using MFC for years, and I recently decided to write my first significant client app in C#/.NET. I have to say that I'm really pleased so far. There's is just so much more that's done for you already, and it really minimizes the amount of code you have to write/maintain. I would say that if your client app is heavily based around file access, UI, databases, or networking... then give C# a try. But if your app relies on a lot of direct memory access and processing type behaviors, then perhaps stick with C++/MFC. You could always try managed C++ and use forms in that way, but it just seems strange to me, personally.

[Member 96]

Yup. In fact it's definitely not perfected yet. We designed and wrote a rough business object library at first, then developed it and the winform UI layer in parallel up to release. Then I wrote the asp.net UI layer. Doing a second UI after the initial one was completed resulted in not noticing some redundancies in the UI layer. Next time around I'm going to introduce another layer which resides between the UI and the business object layer and acts as a more UI centric interface to some of the methods in the business object layer. There is a lot of housekeeping and UI centric features that are common to both asp.net and winform UI's but don't really fit in the business object layer. I highly recommend you check out Rockford Lhotka's CSLA book for more on this if you are interested: http://www.lhotka.net/cslanet/default.aspx[^] It's open source (I've modifed it quite extensively for my purposes) but it really gives you everything you need to know to properly stratify applications, goes into remoting, asp.net and winform ui's, scaleability etc. IIRC it presents three different interfaces to the same application.

[Stephen Hewitt]

Captain See Sharp wrote:

I would love to see more performance critical apps written in C#.

The real question is would users want to use them. C#, and dotNET in general, has many advantages over native code but, in general, performance and resource usage are not amongst them.

Steve

[huyanping]

Good! The key point is how do you use C#. We should obey some new rules. Generally,It's a new approach.

hello, life

[Stephen Hewitt]

Captain See Sharp wrote:

cout << "Test"; Things like that just does not seem the correct way to make a console input/output class

This syntax has advantages over something like this:

Console.Write(“Test”);

One is that you can chain multiple writes together. Like this for example:

int res = /*Some calculation*/;
cout << “The answer is = “ << res;

The other is that it enables the use of manipulator functions. i.e.

cout << “In hex that is: “ << hex << res;

The biggest advantage is that it allows the mechanism to be extended. For example:

class CMyClass
{
};
 
ostream& operator<<(ostream &stm, const CMyClass &rhs)
{
stm << “CMyClass”;
return stm;
}
 
// Now I can write code like this:
CMyClass mc;
cout << mc;

This is a lame example but hopefully you’ll get the idea. In a way a similar result can be achieved in dotNET by overriding the Object.ToString method but using the C++ method allows the stream mechanism to be extended without modifying the stream classes or the type you’re streaming. This is often a very useful property and an example of the Open Closed Principle[^] It's easy to remember once you get used to it: think of the "<<" as arrows pointing in the direction of information flow.

Captain See Sharp wrote:

Why is it named cout instead of something like ConsoleOut?

To save typing the longer "ConsoleOut" all the time I'd wager.

Captain See Sharp wrote:

Why must they name namespaces "std"???

Namespaces can have any name. std is just the namespace the standard C++ library is in.

Steve

[nilotic]

I began tinkering with WinForms first, with no knowledge of web programming. I wanted some apps, so I made them, and I found myself making nicer GUI's than necessary because its so easy. Great. I then quite upset when I made a website. I reckon most of the provided GUI bits don't work properly with Firefox, and don't render nicely in the Design View. eg. When I put an in, it needed a 'margin' tweak to obey form layout, and I can't see the items within the table panels in either the Form Outline or the properties window. Dreadful. Also I'm a bit upset about CSS not rendering nicely in the Design View, when using themes. All in all I find it hard to believe that VS2005 was designed for Web Apps at all, other than an afterthought, after building the excellent Windows App side of things.

A chance to die; to turn to mode - bowie

[Lost User]

I understand. I was just trying to point out that .NET although more verbose is easier to learn and discover what you need. It takes longer to remember all the abbreviations and little things in C++.

█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██

[Stephen Hewitt]

I guess it a bit of a "religious debate" but I've never had any trouble remembering "cout", "cin" or "std" and what they mean. Your mileage may vary. If I had to find faults in C++ and the standard library they wouldn't even make it on the list.

Steve

[Lost User]

Stephen Hewitt wrote:

I guess it a bit of a "religious debate" but I've never had any trouble remembering "cout", "cin" or "std" and what they mean. Your mileage may vary. If I had to find faults in C++ and the standard library they wouldn't even make it on the list.

Although I have never done any serious programming in C++ I found it easy and natural to use cout, cin, and easily remembered std and the various #includes needed to to basic things. I was just trying to point out the elegance of C# compared to C++. I would very much like to develop some apps in C++ but dealing with the Windows API or MFC is a pain. I also do not like making heavy use of pointers, they are hard to avoid in C++. In C# pointers a very useful for large array coping and image editing and I only need to use them in certain scenarios. I can create a window with a very small amount of code that is very easy to understand. I'm not against C++ at all but I think C# is the way to go for general purpose applications, especially with C# 3.0 on the way. I cant wait to use C# 3.0.

using System.Windows.Forms;

namespace SeeSharpProgram
{
class Program
{
static void Main()
{
Application.Run(new TestForm());
}
}
class TestForm : Form
{
public TestForm()
{
this.Title = "Test Form";
this.Width = 640;
this.Height = 480;
}
}
}

█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██

[Stephen Hewitt]

In C++ there are many ways you could do this depending on what framework your using (MFC, ATL, WTL, Qt, etc…). Some would be just as short and easy to understand. There’s no rule that says you have to use straight Win32 API.

Steve

[Lost User]

Stephen Hewitt wrote:

In C++ there are many ways you could do this depending on what framework your using (MFC, ATL, WTL, Qt, etc…). Some would be just as short and easy to understand. There’s no rule that says you have to use straight Win32 API.

Yes, but there are also things such as properties, indexers, delegates(easier and more functional than raw function pointers), iterators with foreach and creation of enermable classes with the yield keyword. There are also things such as cross language interoperability, metadata, reflection. It all adds up to be a great tool to develop your applications on, even with C++. I'm not really saying C# is better, I'm saying that the CLR is a great foundation to build upon in any language.

█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██