What would be the best choice for new client-side apps?

  • Thread starter Thread starter Ray
  • Start date Start date
R

Ray

Hello,

I've been reading MSDN to find out the answer for the question above,
but I think I should ask in this newsgroup (since nearly everything I
read in MSDN Seems to recommend me to move to .NET).

Here's the scenario:

We're creating a desktop application (that is, no client-server, no
three-tier, no nothing, just a simple plain old desktop application).
Instead of being shrink-wrapped it'll be distributed online. As such the
size of distribution is important, if possible we don't want to add
another 20MB download with the app for .NET runtime.

What would be the best way to go forward? Should we just bite the bullet
and use C++/CLI? Or MFC is the way to go?

Thanks,
Ray
 
Ray said:
Hello,

I've been reading MSDN to find out the answer for the question above,
but I think I should ask in this newsgroup (since nearly everything I
read in MSDN Seems to recommend me to move to .NET).

Here's the scenario:

We're creating a desktop application (that is, no client-server, no
three-tier, no nothing, just a simple plain old desktop application).
Instead of being shrink-wrapped it'll be distributed online. As such the
size of distribution is important, if possible we don't want to add
another 20MB download with the app for .NET runtime.

What would be the best way to go forward? Should we just bite the bullet
and use C++/CLI? Or MFC is the way to go?

Thanks,
Ray
Click to expand...

Ray:

If you are concerned about deployment size

MFC
Static linking
InnoSetup

will do the trick. My ever-growing application, complete with .chm help
file and a bunch of sample document files, weighs in at about 700 KB.

David Wilkinson
 
David Wilkinson wrote:
Ray:

If you are concerned about deployment size

MFC
Static linking
InnoSetup

will do the trick. My ever-growing application, complete with .chm help
file and a bunch of sample document files, weighs in at about 700 KB.

David Wilkinson
Click to expand...

Thanks David!

Cheers
Ray
 
What would be the best way to go forward? Should we just bite the bullet
If you are concerned about deployment size

MFC
Static linking
InnoSetup

will do the trick. My ever-growing application, complete with .chm help
file and a bunch of sample document files, weighs in at about 700 KB.
Click to expand...

<to David>
What is the reason for not using one of the deployment types that are
available with Visual Studio?
I have never had a problem with them. (only used them since VS2003 though).

<to Ray>
As for choosing MFC, it all depends on whether you assume your customers
have the .NET runtime on their system or not, and whether they have
broadband or not.
You already assume they have internet, since you offer your app for
download.
Don't most people have broadband these days? If your customers are companies
and power users, it would be safe to say that the large majority has
broadband, so downloading the .NET runtime is no big deal if they don't
already have it.

And if you choose for .NET, you have to judge if you need a lot of interop
with native code or not.
If you don't, then I would personally choose for C#. It is easier to learn,
and more user friendly.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"
 
Bruno said:
<to Ray>
As for choosing MFC, it all depends on whether you assume your customers
have the .NET runtime on their system or not, and whether they have
broadband or not.
You already assume they have Internet, since you offer your app for
download.
Don't most people have broadband these days? If your customers are companies
and power users, it would be safe to say that the large majority has
broadband, so downloading the .NET runtime is no big deal if they don't
already have it.
Click to expand...

Hi Bruno, yes, you're right that having internet is a requirement for
them--I think it's quite safe to assume that we won't be dealing with
56k modem users (I hope!). Our app is a desktop app that won't need to
interop with native code--it's built from the ground up.
And if you choose for .NET, you have to judge if you need a lot of interop
with native code or not.
If you don't, then I would personally choose for C#. It is easier to learn,
and more user friendly.
Click to expand...

Are there any reasons why one would choose C++ over C# if it's just for
a desktop app that's not computatively intensive, does not require 3rd
party native libraries, but need to access Windows UI functions such as
the taskbar notification and stuff? We were just assuming that it was
going to be C++ because most of us come from C++/Java background actually.

Do you feel that making a transition to C# will pay off better in the
long run in this case?

Thanks,
Ray
 
Ray said:
Hi Bruno, yes, you're right that having internet is a requirement for
them--I think it's quite safe to assume that we won't be dealing with
56k modem users (I hope!). Our app is a desktop app that won't need to
interop with native code--it's built from the ground up.


Are there any reasons why one would choose C++ over C# if it's just
for a desktop app that's not computatively intensive, does not require 3rd
party native libraries, but need to access Windows UI functions such
as the taskbar notification and stuff? We were just assuming that it was
going to be C++ because most of us come from C++/Java background
actually.
Do you feel that making a transition to C# will pay off better in the
long run in this case?
Click to expand...

I think that depends very much on your MFC/Win32 API experience. If you're
already proficient with MFC, then use it. But if you're not, the learning
curve for WinForms (.NET) is an order of magnitude faster than MFC. In .NET
1.x, winforms wasn't really "ready for prime time". lacking good support for
such basic things as toolbars. But in .NET 2.0, it's quite possible build a
nice looking, globalized, "Designed for Windows"-compliant end-user
application.

Now, as for "taskbar notifications and stuff". There's no direct support
for the shell notification area (aka taskbar tray) in winforms 2.0, but I'm
sure you can find any number of examples on the net of how to interact with
the shell notification area from a .NET application. "and stuff" is a bit
harder, as it depends a great deal on exactly which "stuff" you're
interested in. For example, if you need to implement any of the shell
extension interfaces (e.g. IShellFolder), then you'll have a very hard time
doing that from C# because there's no type library for those interfaces -
they're defined directly in C++ header files and basically unusable from any
other language. For general Win32 stuff, .NET generally either already has
a nice wrapper (e.g. for the file API), or can readily use Win32 via
P/Invoke.

Lastly, you can always choose to build a hybrid, using C#/winforms for the
bulk of the UI and C++ for the meat of the application and for building
interfaces to parts of windows that aren't already well covered in .NET.

-cd
 
Ray said:
As such the size of distribution is important, if possible we don't want
to add another 20MB download with the app for .NET runtime. What would be
the best way to go forward? Should we just bite the bullet and use
C++/CLI? Or MFC is the way to go?
Click to expand...

I see that David, Bruno and Carl have already offered good advice.

I'd just like to make two points.

1) In case it is not clear, if you were to go the C++/CLI route you would
need the 20MB runtime anyway because C++/CLI is the dialect (my word) of C++
that targets the .Net runtime. It is ISO C++ that generates native code.

2) MFC is long in the tooth. The WTL

http://sourceforge.net/projects/wtl/

and ATL

http://msdn.microsoft.com/library/d...n-us/vcmfc98/html/_atl_atl_class_overview.asp

libraries are far more modern examples of the use of the language.

And in the hands of experts, chances are either WTL or ATL would produce an
executable that is a large as necessary but no larger. The wildcard is how
long it takes to achieve that level of expertise. I don't know because,
well, because neither is my forte and I have never gotten there. :-)

The dude with lots of good stuff here

http://www.viksoe.dk

looks to my eyes to be an expert at both.

Regards,
Will
 
Bruno said:
<to David>
What is the reason for not using one of the deployment types that are
available with Visual Studio?
I have never had a problem with them. (only used them since VS2003 though).
Click to expand...

[snip]

Bruno:

You mean MSI? After avoiding .NET and keeping my deployment size down
with static linking, why would I want to bloat it up with MSI? Actually,
even an old copy of InstallShield Express was working fine for me until
it was derailed by the 64-bit OS's. Inno is a fabulous product, so much
better than anything by InstallShield or Wise. And free. Only drawback
for me is that you have to learn some Pascal.

David Wilkinson
 
William said:
I'd just like to make two points.

1) In case it is not clear, if you were to go the C++/CLI route you would
need the 20MB runtime anyway because C++/CLI is the dialect (my word) of C++
that targets the .Net runtime. It is ISO C++ that generates native code.
Click to expand...

Yes, I am aware of that :)
2) MFC is long in the tooth. The WTL
Click to expand...
<snip>

Thanks for the good pointers, Will!

Cheers
Ray
 
Carl said:
I think that depends very much on your MFC/Win32 API experience. If you're
already proficient with MFC, then use it. But if you're not, the learning
Click to expand...

<snip>

Thanks much for the very informative reply, Carl!

Regards,
Ray
 
Ray said:
Are there any reasons why one would choose C++ over C# if it's just for a
desktop app that's not computatively intensive, does not require 3rd party
native libraries, but need to access Windows UI functions such as the
taskbar notification and stuff? We were just assuming that it was going to
be C++ because most of us come from C++/Java background actually.
Click to expand...

The main reasons (IMHO) for writing native C++ over C# are:

1. The target computers don't have (and won't get) .NET installed. Depends
on the hardware and corporate policies.
2. The application needs to run extremely fast - usually for
computationally intensive time-critical operations. Usually not a huge
factor for WinForms apps, although some of the functionality might need to
be tweaked. You can always interop with native code for time critical
functions.
3. The size of the executable needs to be extremely small (i.e., target
computers have very little memory). Again not usually a huge factor.
Do you feel that making a transition to C# will pay off better in the long
run in this case?
Click to expand...

I have to write a lot of back-end applications in C++ (native) and C#
myself, and I find that the C# apps are much easier to maintain over the
long haul. The savings in maintenance costs and shortened development time
more than justify conversion and new development in C# in my situation.

For your customers without high-speed connections (if there are any), you
could probably snail-mail them your app. installation package on CD...
 
Back
Top