By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,364 Members | 1,272 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,364 IT Pros & Developers. It's quick & easy.

In need of .NET advocacy

P: n/a
Hello people,

The following is not a troll but a serious request.

I found myself in a position where I have to present a Pro/Con list to management and architects in our company with regard to developing new products (specifically - desktop products) in C#/.NET instead of the usual C++/COM that we do.

Since I am not an experienced .NET developer by any definition, I don't have a good grip on the "Pro" part.

The argument that I hear most extols the virtues of the garbage collection in .NET.
Frankly, I am not really convinced by it myself because I started since consistently using smart pointers and RAII, I did not have to worry about deallocations. I also feel that the lack of deterministic destructors is a big drawback that makes managing non-memory resources cumbersome.

Therefore I ask the community to provide me with reasons that could persuade me, and the people I will present them to, that switching would be beneficial to the company (they would be mostly interested in lowering risks, increasing productivity and saving money).

Both links and prose are welcome.
Best regards,
Alex.
--
Please replace myrealbox with alexoren to reply by email.

Jul 21 '05 #1
Share this Question
Share on Google+
55 Replies


P: n/a
Microsoft is in the process of killing the C++/COM stuff. The easiest way
of doing COM components was with VB6 but they don't sell it anymore and they
will soon (next month) stop unpaid support for it; the only exception beeing
things about security. In two years, even the security support for VB6 will
cease to be free. With VB6 out of the picture, the demand for COM
components will be falling rapidly.

On the C++/MFC/ATL side, you can be pretty sure that there will be no new
further development - excerpt of course for the integration of managed
code - and MS will only offer support for maintenance releases.

For Windows, it is fair to say that in the future, any new development will
be based on the .NET Framework; so you can tell that C++/COM is a thing of
the past and of the present but not of the future.

S. L.

"Alex" <re******@myrealbox.com> wrote in message
news:3a*************@individual.net...
Hello people,

The following is not a troll but a serious request.

I found myself in a position where I have to present a Pro/Con list to
management and architects in our company with regard to developing new
products (specifically - desktop products) in C#/.NET instead of the usual
C++/COM that we do.

Since I am not an experienced .NET developer by any definition, I don't have
a good grip on the "Pro" part.

The argument that I hear most extols the virtues of the garbage collection
in .NET.
Frankly, I am not really convinced by it myself because I started since
consistently using smart pointers and RAII, I did not have to worry about
deallocations. I also feel that the lack of deterministic destructors is a
big drawback that makes managing non-memory resources cumbersome.

Therefore I ask the community to provide me with reasons that could persuade
me, and the people I will present them to, that switching would be
beneficial to the company (they would be mostly interested in lowering
risks, increasing productivity and saving money).

Both links and prose are welcome.
Best regards,
Alex.
--
Please replace myrealbox with alexoren to reply by email.
Jul 21 '05 #2

P: n/a
"Alex" <re******@myrealbox.com> wrote in message
news:3a*************@individual.net...
Hello people,

The following is not a troll but a serious request.

I found myself in a position where I have to present a Pro/Con list to
management and architects in our company with regard to developing new
products
(specifically - desktop products) in C#/.NET instead of the usual C++/COM
that we do.

Since I am not an experienced .NET developer by any definition, I don't
have a good grip on the "Pro" part.
Here we go:
- Productivity, productivity, productivity. Within 3 months of switching to
..NET we found a 20-50% productivity boost over VB6. The boost over C++ was
several times.
- Interoperability. A lot of work has gone into making sure that your .NET
code will work seamlessly with your COM components, preserving your existing
investment. Similarly IJW protects your existing non-COM C++ code.
- Security. CAS allows you to be very specific about code permissions,
allowing you to ship safer code and administrators to protect their systems
better.
- Some platform independence. With Mono you get the ability to write for
Windows and Linux in one code base.
- Future. COM does have a future, but will not receive much work. Most new
components and libraries on Windows will be .NET.
- Massive unified libraries. Their unified nature makes them easier to learn
(ONE string class!). Their capabilities are awesome.
- RAD features. Visual designers, edit & continue (soon back) and suchlike
make it very easy for even beginners to pump out good components.
The argument that I hear most extols the virtues of the garbage collection
in .NET.
That's perhaps because of how important a feature it is.
Frankly, I am not really convinced by it myself because I started since
consistently using smart pointers and RAII, I did not have to worry about
deallocations.
Good for you! But now imagine you were working in a system where it not only
guaranteed RAII for, but for all code you used. You could put that newbie to
work without having to scan their code for naked pointers and invalid
resouce usage semantics, because it would be taken care of for you.
I also feel that the lack of deterministic destructors is a big drawback
that makes managing non-memory resources cumbersome.
There is a pattern called IDisposable that allows you your deterministic
clean-up. Also note that the new C++/CLI allows for deterministic
finalisation.
Therefore I ask the community to provide me with reasons that could
persuade me, and the people I will present them to, that switching would be
beneficial to the >company (they would be mostly interested in lowering
risks, increasing productivity and saving money).

Both links and prose are welcome.
Best regards,
Alex.
--
Please replace myrealbox with alexoren to reply by email.

Jul 21 '05 #3

P: n/a
> - Productivity, productivity, productivity. Within 3 months of switching
to
.NET we found a 20-50% productivity boost over VB6. The boost over C++ was
several times.
I do not know about VB but when I use managed C++ then I speed up about 3
times compared to unmanaged C++ because especially in user interface design.
And a second aspect because of the assemblies, that reduces compile and
linker time a lot.

If I create a program purely in C# then I even speed up with 7 times
compared to unmanaged C++.
Mainly because of the lightning faster compile times than C++, and also the
auto-completion is much faster, and the languages is designed from scratch
to use the .NET so much simpler to extend and very readable compared to the
C++ where I need tons of macro's to make it .NET compatibe.

Right now I create C# projects for prototyping and test my program, en then
port it to conventional C++ and still have time left.

The good things about the .NET is that you can write parts in managed C++
code, so you still have the raw processing speed while you have the very
nice User interface featuers of the .NET. :-)

Oddly enough, I create the programs in the same time frame when I program in
..NET or conventionally. The only difference is that I can add more
functionality and make it far more user friendly in the case of the .NET
program.
- Security. CAS allows you to be very specific about code permissions,
allowing you to ship safer code and administrators to protect their systems better.
This is true, the security of the code is buit into the application by
default.
In my opinion, now in the world of so many virusses and worms, this is the
best thing they ever implemented.
E.g. if you create a small program lets say a calculator, then it cannot be
infected by a virus/worm and taken over to connect the Internet. Compared to
a conventional executable, it could take over your complete computer. I
don't clame that a .NET program cannot be infected, but it slows down the
propagation dramatically.
- Some platform independence. With Mono you get the ability to write for
Windows and Linux in one code base.
And don't forget, with the Visual Studio 2005 coming out in the summer in
combination with the .NET framework 2.0 you can compile a program in such a
way that it stays neutral of the 32/64 bit code.
This means that a program that is compile with this flag, then when
installed on a 32 bit Windows XP it will compile as 32 bit program, and when
run on a 64 bit Windows XP it will compile and run as pure 64 bit!!!!! And
the 64 bit Windows XP is out to be soon? This month I believe?
- Future. COM does have a future, but will not receive much work. Most new
components and libraries on Windows will be .NET.
- Massive unified libraries. Their unified nature makes them easier to learn (ONE string class!). Their capabilities are awesome.

In the near future we will have .NET framework v2.0 combined with Visual
studio 2005, this summer.
But then the name changes to WinFX (equivalent of .NET framework 3.0) to be
included into the next version of WIndows codenamed Longhorn (2006).
The good news is that I hear rumors that this WinFX will also be available
for Windows XP and maybe W2K(?)

Since porting code from unmanaged code to managed code takes time, it would
be nice to start doing it now. Or at least start to learn the .NET way it
does have a pretty steep learning curve regarding to the security stuff. And
you have to think in OOP which to my suprise a huge bunch of programmers
still do not understand because they have to unlearn the none-OOP way.

The biggest negative side of the .NET applications is that there is a big
resistance towards installing the .NET framework.
I get very silly responses when I ask people why they do not want to install
it. Most of the responses are psychological orientated, which translates to
fear of the unknown.
But it appears that when you buy a recent version of Windows XP then the
..NET framework framework is automatically included.

Another psychological thing is that .NET programs appears to be slow,
because they load much slower. But tests here by running the program, I do
not see any noticible slowdown. Except for the additional user interface
functionality that you implement of course. You tend to implement more
active user interface stuff.

--
http://www.skyscan.be
Jul 21 '05 #4

P: n/a
>The argument that I hear most extols the virtues of the garbage collection
in .NET.
Frankly, I am not really convinced by it myself because I started since
consistently using smart pointers and RAII, I did not have to worry about
deallocations. I also feel that the lack of deterministic destructors is a
big drawback that makes managing non-memory resources cumbersome.

The GC is fantastic!
The only scary thing is that if you look at your taks manager, your memory
consumption gets up and up and up an when it reaches out of memory
situations it suddely drops dramatcially. This means that the GC got into
action freeeing up memory. It does this by alanyzing you assigned code and
if it discovers that some memory blocks are not assigned anymore anywhere
then it frees up memory. Smart pointers cannot do that in my opinion, not in
that extend way.

The very good thing about this is that I do to have to keep track of who
allocated the memory, if you assign it to multiple pointers.
The other good thing is that the memory does not get disposed untill every
pointer to it have been changed to another location. This reduces the risk
of access violations dramatically since all pointers point to a valid memory
block. Your code gets simplified dramatically. Especially when you create
code for OpenGL, to built a dynamic scene.

There is one negative impact of the GC.
When you implement code that have file access, that locks a file, and you
would close the file in the destructor, then the file gets close in a
unpredictable time frame. So in this case you should not close the file in
the destructor, but use the "dipose" function for that. This is similar like
calling the delete function but it happens when you decide it, not depending
on the GC.

I have to admit that in the beginning I did not trust that GC, I was afraid
that it would not work very reliantly, but tests have shown that it is very
reliant, so now I trust it more than the time that I used the delete way of
doing.

--
http://www.skyscan.be
Jul 21 '05 #5

P: n/a
Sean,

Very nice post. I find this one of the best on this ever asked question.with
the exception from that not expliciet question to respond to your mail
address, let us all benefit from this kind of discussions. (Although in my
opinion there is not much to ask anymore when we see your message).

:-)

Cor
Jul 21 '05 #6

P: n/a
Another reason to move to .NET is the fact that VB programmers that upgrade
to VB.NET somehow gets forced to use the .NET.
Since there are far more VB programmers than C++ programmers, I believe that
the .NET framework will be forced to be installed by everybody that wants to
use that latest program created by the VB programmer.

Also I noted that ATI video card drivers expect the .NET installed for their
user interface to configure the card. (CATALYSTT for Windows XP) ATI is also
a big player in the market so expect .NET to be installed on many computers
that have the newest ATI video cards.

In my opinion, investing in none-NET technology except if you need raw
performance power, is a waste of time and resources if you create a program
that have a year development cycle.

--
http://www.skyscan.be
Jul 21 '05 #7

P: n/a
I have to throw in my two bits here...
I have to present a Pro/Con list to management and architects in our
company with regard to developing new products (specifically - desktop
products) in C#/.NET instead of the usual C++/COM that we do.< (they would be mostly interested in lowering risks, increasing productivity
and saving money).<

The framework library alone is worth the switch. For years, folks have been
complaining that MFC and the classes built on top of it ignored most of the
most productive design patterns. It was difficult to really use many of the
most powerful patterns without creating yet another layer of code on top of
the MFC classes to create the relationships that you needed, and even then,
C++ was structurally limited from answering a few of the most difficult
problems.

No more.

You get a class library that was redesigned from the ground up. It makes
EXTENSIVE use of the modern design pattern principles, one of the key
reasons that folks had been switching to Java, but are now switching back.
As a result, the code is smaller, easier to plug in, and easier to maintain.
I'll be honest, I'm able to do things in C# that would not have occurred to
me in C++ because the library has fostered a better approach to solving
problems.

The neat thing about this is: the explosion of open source C# code. I guess
it was hard to tell that one of the biggest reasons why C++ never really
took off in the open source community was the lack of patterns in the MFC,
but now that we have the framework, it is not only easy to get high quality,
open source, components written in C#, but Microsoft itself has released
fairly sizable chunks of code into open source.

In fact, many of the "productivity" applications that were popping up in the
Java world for years have now started appearing as ported code in .Net,
including (my favorites) NUnit, NAnt, and ports for many popular AOP
frameworks.

Also, with C# and .NET, we have no more DLL Hell, like we did with COM.
That was an expensive problem and one of the best things that MS fixed. In
order to share your library with other apps, you MUST sign it and provide a
version number. The system will check the version (unless you tell it not
to) to make sure that you are getting the library you debugged with.

What does all this give you:
Lowered risk
--- code can be reused, shared, and leveraged more easily because of the
extensive use of patterns in the framework
--- less code is required, therefore less likelihood of defects, therefore
less risk in the integration phases
--- more readily available code for profiling, unit testing, automated
build, and others
--- by using the newer framework, finding skilled resources is easier than
finding C++ folks
--- Absense of DLL hell reduces support costs

Increased productivity
--- No need to write expensive "layers" on top of MFC to get it to do the
things that OO developers expect
--- Support for a wide variety of needs, including internet protocols, XML,
and Web Services, built in to the tools. Zero code to use these new
features.
--- C# language is simpler to write in, and simpler to train folks in,
dramatically increasing the productivity of average developers
--- Elegant event model built in to languages allows for more powerful
application architectures with less code to maintain.

Lowered costs
--- First off: lowering risk and increasing productivity... no need to
repeat myself
--- availability of low cost or no cost options for components and tools,
even a few from Microsoft.
--- Training costs are lowered due to the approachability of the system
--- More people are available in the contingent staffing world who know C#
now, lowering their billable rates
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
Jul 21 '05 #8

P: n/a
Except when M$ drops support for .Net, like they are doing with VB6,
you'll be screwed, just like the millions of people/companies that have
invested billions in building VB apps. You'll have to either migrate
your code to the next great M$ platform or else just try to plod on
with no support or upgrades from M$. At least if you build something
with C++, you know that you'll always be able to compile it and always
be able to find support.

Jul 21 '05 #9

P: n/a
Patrick,
At least if you build something
with C++, you know that you'll always be able to compile it and always
be able to find support.

In a kind of same way is this said in past from the universal language Algol
as well.

Beside Cobol are there not much program languages with a longer lifetime
than 30 years.

Cor
Jul 21 '05 #10

P: n/a
Cor,

Whew! Thanks, I really appreciate the compliment.

BTW, my email address can be found here:
http://www.codingsanity.com/email.jpg.

Sean

"Cor Ligthert" <no************@planet.nl> wrote in message
news:eB*************@TK2MSFTNGP10.phx.gbl...
Sean,

Very nice post. I find this one of the best on this ever asked
question.with the exception from that not expliciet question to respond to
your mail address, let us all benefit from this kind of discussions.
(Although in my opinion there is not much to ask anymore when we see your
message).

:-)

Cor

Jul 21 '05 #11

P: n/a
And what about Fortran? According to the following references, Fortran was
born well before Algol:
http://www.math.grin.edu/~rebelsky/C...utline.02.html
http://www.scriptol.org/dates.htm

S. L.

"Cor Ligthert" <no************@planet.nl> wrote in message
news:uu**************@TK2MSFTNGP15.phx.gbl...
Patrick,
At least if you build something
with C++, you know that you'll always be able to compile it and always
be able to find support.

In a kind of same way is this said in past from the universal language
Algol as well.

Beside Cobol are there not much program languages with a longer lifetime
than 30 years.

Cor

Jul 21 '05 #12

P: n/a
"Patrick A" <pw*******@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
Except when M$ drops support for .Net, like they are doing with VB6,
you'll be screwed, just like the millions of people/companies that have
invested billions in building VB apps.
And who didn't bother using the great Upgrade Wizard provided with .NET.
Also, note that when VB6 support ends, you'll still be able to write VB6
apps and sell them, and they'll work. MS just won't be providing free tech
support on it.
You'll have to either migrate
your code to the next great M$ platform or else just try to plod on
with no support or upgrades from M$. At least if you build something
with C++, you know that you'll always be able to compile it and always
be able to find support.


By this logic we shouldn't buy anything. Where do you think I can get free
support for my Nokia 2110? Or my parents Datsun 1200 (1980's model)? How
about getting support for my Betamax video player, or my LP record player?
The fact is that you can still get support for those things, it'll just cost
you more. VB6 is the same.

Keep in mind that VB6 was about providing RAD to developers, and .NET
continues that tradition. I'll say that I believe I'd spend less time
writing an app in VB6, and then rewriting it in VB.NET from the ground up
than I would writing it in C++ once. So, a longer term language but at the
cost of productivity and profits. I'm not in that sector of the industry
where solutions have to last 10+years, so for me, C++ makes no sense.
Jul 21 '05 #13

P: n/a
> Except when M$ drops support for .Net, like they are doing with VB6,
you'll be screwed, just like the millions of people/companies that have
invested billions in building VB apps. You'll have to either migrate
your code to the next great M$ platform or else just try to plod on
with no support or upgrades from M$. At least if you build something
with C++, you know that you'll always be able to compile it and always
be able to find support.

If you think like that, then we would probably still be stuck with Windows
3.1 now and no Internet.
Programming languages must evolve since the programs they must create
becomes more and more complex.
Using managed C++ using .NET framework I gain a 3 fold speed of development,
while creating more secure code an far more user friendly.

I realize that the VB6 people have a hard time since it is a step backwards
in functionality, but the Visual studio 2005 coming out in de summer, will
have a much better solution and ease of use for VB programmers. You will
still have a transition, but it will become much easier.

Regarding support and experience, since .NET programs look alike in any
programming language except for small syntax differencs, you will gain a lot
more experience from other developers that program in different languages.
The only limiting factor would be the none-case sensitivity, but if C# and
C++ programmers write .NET assemblies (dll's similar like OCX) you simply
can use them if you want. So your search for usefull components increases
treefold with the components designed for the managed C++ and C# + your
normal VB.NET components .

See many advantages over VB 6, it is really worth the transition!

--
http://www.skyscan.be
Jul 21 '05 #14

P: n/a
no one is stopping you from sticking with VB6. Support is still there...
it's just not free. There's a BIG difference.

Those C++ language compilers you are comparing with... will you be paying
for support there too?

I was once a Luddite too, but no more. Sometimes progress really is better.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Patrick A" <pw*******@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
Except when M$ drops support for .Net, like they are doing with VB6,
you'll be screwed, just like the millions of people/companies that have
invested billions in building VB apps. You'll have to either migrate
your code to the next great M$ platform or else just try to plod on
with no support or upgrades from M$. At least if you build something
with C++, you know that you'll always be able to compile it and always
be able to find support.

Jul 21 '05 #15

P: n/a
Thank you very much for your replies, they (especially Sean's Olaf's and Nick's) were very informative!

First, a minor nit picking:

Sean Hederman> There is a pattern called IDisposable that allows you your deterministic clean-up.

Not really, as it depends on the user of the object to manually call Dispose() at the appropriate time.
I had this problem with Java and it is the same in C#.
I hope that C++/CLI would solve it in an elegant way (i.e., allowing destructors in managed objects).
Now, to the bulk of the answers.

The comments mentioned several advantages:

1) Productivity increase.

Is it possible to get some "official" data from a company?
It is one thing to say "Joe Sixpack claimed on m.p.d.g that he experienced a productivity increase of 64.7% since switching to .NET" and quite a different thing to point people to the site of a commercial (preferably well known) company stating the same.

Also, it would be interesting to break down the productivity increase.
Did the savings come from an easier transformation of the design to code? Faster coding? Less bugs to fix? More efficient tracking of the said bugs? More understandable code? Something else? Did all activities (analysis/design, coding, QA, refactoring, support) benefit equally?

2) Security.

Again, real-world examples will be appreciated.

3) Portability and interoperability.

I don't see any advantage over using C++ with platform-independent library (like Qt, ACE, WxWidgets, etc.)

4) "Future".

Not really an issue in this particular case because future platforms will still support COM and native execution.
As somebody mentioned, the availability of newer Maximas did not cause older Datsuns to stop working.

5) Framework.

Can anyone comment what parts of the framework proved to be "lifesavers" compare to the "old way"?

6) RAD features.

MFC had them, no?

7) Programmer availability.

I guess that if a lot of VB6 coders are "forced" to switch to VB.NET then the market of .NET developers will get a big boost.
However, no offence intended but VB6 did little to promote good programming practices and a good number of VB6 coders should not be let anywhere near a product.

My own (admittedly biased) perception is that top developers would achieve better results given the power and flexibility of C++ but the average developer will do better with managed code.

8) Stuff that nobody commented on (yet)

Reflection, 3rd party tools (NUnit, etc.), ...
Best regards,
Alex.
--
Please replace myrealbox with alexoren to reply by email.

Jul 21 '05 #16

P: n/a
Alex,

With all those good answers in this threads, which answers that are in my
opinion more than you could expect from a newsgroup. I can only get this
opinion. This starting message in your question is false.
The following is not a troll but a serious request.


Just my thought,

Cor
Jul 21 '05 #17

P: n/a
>Now, to the bulk of the answers.
Very tough questions now, you want proof. ;-)
I can only give you the programers point of view.
1) Productivity increase.
I cannot give real data, but look at it this way:
Currently I am still forced to use unmanaged C++ because users have still
the big scare to install the .NET framework.
But I can speed up the unmanaged C++ cycle by creating prototype C# programs
to test out ideas and functionality because the C# compiler is lightning
fast.
This way I know the pitfalls that I will encounter, I can use NUnit for
tesing stuff and then I port that C# code to C++ and still have more time
left than I would have created the program in unmanaged C++ directly. I had
to find a good way to emulate delegates/events and use properties in
unmanaged C++, but now the C++ programs are equivalent of the .NET way of
doing. Also the C++ programs are actually a stripped down version of the C#
programs that have far more functionality otherwise I would never reach a
delivery date. But at least the C++ programs are ready to be extended for
the future.
2) Security.
Again, real-world examples will be appreciated.

If you go to http://www.securityfocus.com/bid/keyword/
Here you fins all known bugs of almost anything software related.
APS.NET uses the .NET frameowrd, ASP uses the old ways.

Use keyword "asp.net" (.NET way) and I get 5 bug reports:

16-02-2005: Microsoft ASP.NET Unicode Character Conversion Multiple
Cross-Site Scripting Vulnerabilities
06-10-2004: Microsoft ASP.NET URI Canonicalization Unauthorized Web Access
Vulnerability
06-05-2004: Microsoft ASP.NET Malformed HTTP Request Information Disclosure
Vulnerability
08-09-2003: Microsoft ASP.NET Request Validation Null Byte Filter Bypass
Vulnerability
06-06-2002: Microsoft ASP.NET StateServer Cookie Handling Buffer Overflow
Vulnerability

Use the keyword "ASP" (none .NET way) and you get a zillion of bugs.
6) RAD features.

MFC had them, no?
Not really, it was a first trial to make it RAD, but they failed miserably
because the MFC classes are created in the none-Object way of thinking.
It was nothing more that a set of classes that acts as wrapper around
windows functions. You had a very hard time to extend and reuse the objects.
The framework was built in the wrong way.

Another thing about MFC is that every class behaves differently. So many
execptions in how to use dialog box controls that are in a lot of cases not
compatible with each other.
Which is perfectly normal because since MFC is a set of class wrappers
around Windows and Windows have been extended with all different new
technologies.

Creating a user interface is an adventure on it's own.
Look at the differences in using menu items and popup menu's. Completely
different ways of implementing.

At the same time, Delphi came out with the pure Object oriented way of
thinking. This was in 1995 or something like that.
Every component have almost the same properties with predictable names. If
you understand one control, then you probably understood the other control
too.

Maybe it is of no suprise but the guy that developed the Delphi framework,
happens to be the same guy that was in the design phase of the .NET.
I don't know the details about this, but it is striking how close Delphi and
..NET are related.

Look I don't say that MFC is really that bad, it was a good idea in those
times to implement it like that, but the Delphi/.NET way appears to be the
better choice since it is designed from scratch in such a way that is can be
extended. It looks like that MFC is designed to have the highest performance
in speed while the .NET way is to the easiest way of extending and creating
programs.
7) Programmer availability.

I guess that if a lot of VB6 coders are "forced" to switch to VB.NET then the market of .NET developers will get a big boost.However, no offence intended but VB6 did little to promote good programming practices and a good number of VB6 coders should not be let anywhere near a product.
This is a something that I do not wish to discuss. ;-)
But the hord of VB.NET programmers will somehow make the users install the
..NET framework which is very good news. :-)
My own (admittedly biased) perception is that top developers would achieve better results given the powerand flexibility of C++ but the average developer will do better with managed code. I have to agree on that. But to programmers are expensive and in short
supply.
And what do you do when they leave the company or maybe get sick? Who is
able to take over that code?
Top programmers tend to create unreadable code for other developers. Mostly
because they use techniques that the common people have no clue of what they
are doing.
8) Stuff that nobody commented on (yet)

Reflection, 3rd party tools (NUnit, etc.), ...

I love NUnit!!
Testing code have never been so easy when you starts to have a huge library
and you must change something in that library you can test very fast if it
breaks something else.

Another issuse, if you program in C# and have a syntax error, then your
incorrect code gets underlined, so you can find the problems faster. Also
you maybe get a few errors while C++ tends zo give you a kazilion errors all
trying to point you in the wrong direction.
In my opinion choosing for the .NET or not is like a action of faith. Only
history will tell if it was a good choice or not.
But right now I personally would gamble on .NET.

--
http://www.skyscan.be
Jul 21 '05 #18

P: n/a
Hi Alex,
Thank you very much for your replies, they (especially Sean's Olaf's and
Nick's) were very informative!<<
Glad to be of help
1) Productivity increase.<<
Developers have been arguing about how to measure developer productivity for
years. If you notice from my signature, I am a CFPS. That is a Certified
Function Point Specialist. In other words, I am trained and certified
measure developer productivitiy. Most of my data is private and
proprietary. I can tell you this: when translating from function points to
estimates, we use "normalized" numbers to determine the expected
productivity of a developer against a particular feature set. We are very
happy with the productivity of C#. C++ is considered one of the "average"
languages. These are not guesses. They are measurements. (And no, I
cannot share the numbers). You can get public numbers from
http://www.spr.com
Did the savings come from an easier transformation of the design to code?
Faster coding? Less bugs to fix? More efficient tracking of the said
bugs? More understandable code? Something else? Did all activities
(analysis/design, coding, QA, refactoring, support) benefit equally?<<
The reasons "why" vary from person to person, mostly because each person
finds a different reason for the productivity gains of .Net. Besides, why
do you care? If its more productive, its more productive. It's a little
like asking "Why does Broccoli taste better than Asparagus?" You'll get an
argument and no answers. Note that 2.0 (Whidbey) adds a LOT of useful
features, including a unit testing framework very similar to NUnit.

2) Security.

There have only been a handful of security issues reported against .NET, and
all have been fixed in current service packs. Not so for COM over the
years. . (Public info was provided by another poster).

3) Portability and interoperability.

I never raised this as an advantage of .Net. I simply stated the error of
using this as a cost factor over .Net because it is not cheaper to use a
different compiler (with paid support or no support).

4) "Future".
Not really an issue in this particular case because future platforms will
still support COM and native execution.<<
I thought you were pulling this stuff together for managers and executives.
Now I'm beginning to wonder. Is Cor right?

"Future of the language" affects the availability of developers. These
issues are CLOSELY tied together.

If your company is doing custom software development, even just for internal
apps, this matters a LOT. Ask all those organizations stuck with miles of
Powerbuilder code and no developers around to maintain it, and no way to add
the new features that the business wants, or change the business rules to
keep up with changes in law, policy, or business practices. This is an
EXPENSIVE place to be.

I know of a government agency with a mission critical app written in
SmallTalk, and no way to extend it. It's a nice app, but they needed
integration features, and SmallTalk doesn't give you anything "out of the
box" like .Net (and even VB6) does. Their last remaining SmallTalk
developer doesn't understand integration.

This story is repeated in thousands of companies and agencies, with systems
written in dozens of languages. With the aging of the COBOL population,
this fate will soon befall the estimated billions of lines of COBOL code. I
used to support an app in Simula. Talk about "hard to fix!" Simula is a
wonderful language that no one remembers. I even added one to the pile:
many years ago, I wrote a very useful app for Linguistics research... in
SNOBOL. I dare you to find a professional SNOBOL programmer, for any price.

Availability of developers matters. Over time, it will matter to C++. The
trend has already started, and historically, this trend is a freight train
that cannot be stopped.

5) Framework.
Can anyone comment what parts of the framework proved to be "lifesavers"
compare to the "old way"?<<
All of it. The structure of the framework is totally different than a set
of wrapper classes around a set of wrapper classes around an API. (COM on
MFC on Win32). You can do things in 20 lines of code in C# that would
require hundreds in C++, and that story is repeated many times.

Are you familiar with Design Patterns? If not, read this to get you
started: http://blogs.msdn.com/nickmalik/arch...21/328727.aspx

6) RAD features.MFC had them, no?<< You are kidding, right?
7) Programmer availability.
I guess that if a lot of VB6 coders are "forced" to switch to VB.NET then
the market of .NET developers will get a big boost.<< Now, you are being prejudiced. I know many excellent programmers in the VB
ranks, and some pretty lousy ones in the C++ ranks.
My own (admittedly biased) perception is that top developers would achieve
better results given the power and flexibility of C++ but the average
developer will do better with managed code.<<
Your statement is naieve. *All* developers will achieve better results
using C# over unmanaged code because you can focus on the business problem
and not the details of the technology. Also, _your_ projects will have
average developers on them, if not now, then later during maintenance. This
is a fact of life. Average developers outnumber top developers about 20 to
1 in my experience.

No one creates an IDE for top developers, or a language, or a framework.
These tools are there for average developers to increase their productivity
because a 1% increase in productivity applied to 95% of the workforce is far
better for overall cost savings than a 25% increase applied to 5% of the
workforce. Company executives get this, and if you want to be able to speak
with them with a coherent message, you need to learn it too.
Reflection, 3rd party tools (NUnit, etc.), ...<<


I commented on third party tools and open source platforms in my previous
post.

I've seen many postings from Java users who were impressed with the
Reflection capabilities of .Net. Personally, I think that reflection is
probably a tad bit over-discussed because it is a 'cool' feature, but for
those applications where it is the right answer (quite a few, actually), it
is absolutely mission-critical, and this capability simply wasn't available
in C++.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.


Jul 21 '05 #19

P: n/a
"Alex" <re******@myrealbox.com> wrote in message
news:3b*************@individual.net...
Thank you very much for your replies, they (especially Sean's Olaf's and
Nick's) were very informative!

First, a minor nit picking:

Sean Hederman> There is a pattern called IDisposable that allows you your
deterministic clean-up.

Not really, as it depends on the user of the object to manually call
Dispose() at the appropriate time.
I had this problem with Java and it is the same in C#.
Whether it's manually called or not does not impact it's determinism. A
naked pointer in C++ has deterministic clean-up, but you have to call delete
to get it. If you want smart pointer equivalence, wrap the reference in a
using block.
I hope that C++/CLI would solve it in an elegant way (i.e., allowing
destructors in managed objects).
It does. C++/CLI supports deterministic cleanup via ~ClassName.
Now, to the bulk of the answers.

The comments mentioned several advantages:

1) Productivity increase.

Is it possible to get some "official" data from a company?
It is one thing to say "Joe Sixpack claimed on m.p.d.g that he experienced
a productivity increase of 64.7% since switching to .NET" and quite a
different thing to point people to the site of a commercial (preferably
well known) company stating the same.
Does Microsoft count? ;-)
Also, it would be interesting to break down the productivity increase.
Did the savings come from an easier transformation of the design to code?
Yes, much easier.
Faster coding?
The tools help you with coding if that's what you mean. Also C++ to C# meant
a cleaner syntax with less gotchas and ambiguities.
Less bugs to fix?
Yep. No swallowed error conditions via unchecked HRESULT's. No dangling
pointers, no buffer overruns, no memory leaks.
More efficient tracking of the said bugs?
Nope. Generally one uses third-party tools for that.
More understandable code?
Yes, C# is much easier to read than C++.
Something else?
One coherent set of libraries.
Did all activities (analysis/design, coding, QA, refactoring, support)
benefit equally?
No, Id say coding was helped the most by the tool, and the Framework also
assisted A&D, coding and QA a bit.
2) Security.
Again, real-world examples will be appreciated.
Code Access Security and no buffer overruns are the biggies here.
3) Portability and interoperability.
I don't see any advantage over using C++ with platform-independent library
(like Qt, ACE, WxWidgets, etc.)
Read the posts. Sure, you can do it in C++, but C++ is a pain to develop for
in comparison.
4) "Future".

Not really an issue in this particular case because future platforms will
still support COM and native execution.
As somebody mentioned, the availability of newer Maximas did not cause
older Datsuns to stop working.
No, but do you really *want* to drive an old Datsun?
5) Framework.
Can anyone comment what parts of the framework proved to be "lifesavers"
compare to the "old way"?
Reflection, unified type system, single string class (happiness), Remoting.
6) RAD features.
MFC had them, no?
No. I suggest you write a simple MFC windows app, and then do the same in
Windows Forms. Chalk and cheese.
7) Programmer availability.
I guess that if a lot of VB6 coders are "forced" to switch to VB.NET then
the market of .NET developers will get a big boost.
However, no offence intended but VB6 did little to promote good programming
practices and a good number of VB6 coders should not be let anywhere near a
product.

Agreed, but then I also believe that large numbers of C++ coders should be
similarly constrained. Also, you seem to be suffering from a fairly common
misapprehension that .NET is basically C# & VB.NET. You can also code .NET
using
C++, either ANSI C++ (using Managed C++ Extensions), or the much easier to
read C++/CLI.
My own (admittedly biased) perception is that top developers would achieve
better results given the power and flexibility of C++ but the average
developer will >do better with managed code.
Disagree completely:
http://codingsanity.blogspot.com/200...about-net.html. I
love this attitude by dyed-in-the-wool C++ devs that C++ is somehow "better"
than other languages. It's not. It's just a language. It does some things
better, and some things worse than other languages. I don't understand how
you can come up with the idea that top developers won't achieve better
results by using better tools. For writing most applications today, .NET is
a far better tool than most C++ implementations. In the few areas where it's
not, fine use C++. Premature optimization is a mistake no matter what the
context, and developing 100% in C++ because of the 1% (or less) where you
really need it is a clear case of premature optimization.

Alex, I'm struggling to understand something. You asked for pro/cons to
persuade others and then flat out admitted that you're biased against what
you're supposedly championing. Your statements appear designed to assert
that C++ is better than .NET/C#. I'm struggling to reconcile this with your
assertion that you're not a troll, and it seems I'm not alone.
8) Stuff that nobody commented on (yet)
Reflection, 3rd party tools (NUnit, etc.), ...
Best regards,
Alex.
--
Please replace myrealbox with alexoren to reply by email.


Jul 21 '05 #20

P: n/a
Thank you for the reply, Olaf

"Olaf Baeyens" <ol**********@skyscan.be> wrote in message news:42*********************@news.skynet.be...
Now, to the bulk of the answers.

Very tough questions now, you want proof. ;-)


Not exactly. I have to present a case between people that will want hard data.
I am not saying that I would not be able to be convincing without it but it would be so much easier if I was able to say that company BlahBlahSoft made a similar decision and experienced measurable gains.

It is not easy to overcome corporate inertia.

Thanks,
Alex.

--
Please replace myrealbox with alexoren to reply by email.

Jul 21 '05 #21

P: n/a
Hello Nick, thank you for your reply.

"Nick Malik [Microsoft]" <ni*******@hotmail.nospam.com> wrote in message news:4c********************@comcast.com...
Developers have been arguing about how to measure developer productivity for
years. If you notice from my signature, I am a CFPS. That is a Certified
Function Point Specialist. In other words, I am trained and certified
measure developer productivitiy. Most of my data is private and
proprietary. I can tell you this: when translating from function points to
estimates, we use "normalized" numbers to determine the expected
productivity of a developer against a particular feature set. We are very
happy with the productivity of C#. C++ is considered one of the "average"
languages. These are not guesses. They are measurements. (And no, I
cannot share the numbers).
Even not aggregates?
You can get public numbers from http://www.spr.com
I could not find public data on cpr.com, only reports for sale.
Did the savings come from an easier transformation of the design to code?
Faster coding? Less bugs to fix? More efficient tracking of the said
bugs? More understandable code? Something else? Did all activities
(analysis/design, coding, QA, refactoring, support) benefit equally?<<
The reasons "why" vary from person to person, mostly because each person
finds a different reason for the productivity gains of .Net. Besides, why
do you care? If its more productive, its more productive.


I care because I have been asked these questions when I tried to informally broach the subject to some decision makers.
I've been told that we would have to (a) purchase new tools and (b) re-train our developers, both of which costs.
We are not exactly swimming in money so unless I can demonstrate good ROI in the short-to-medium term, I am not going to have a sympathetic audience.
4) "Future".
Not really an issue in this particular case because future platforms will
still support COM and native execution.<<
I thought you were pulling this stuff together for managers and executives.
Now I'm beginning to wonder.
Is Cor right?
Cor is free to think and say whatever he (or she) wishes. I am free to ignore him (or her).

Your sig notwithstanding, you still work for Microsoft. When a person asks for help in nudging his company towards a platform that YOUR EMPLOYER develops, markets and advocates, making allegations about this person's motives is not your best course of action.

I thank you for your help so far but I can do without the veiled insults.
"Future of the language" affects the availability of developers. These
issues are CLOSELY tied together.
The issue of developer availablity is a real one and I have commented on it separately.
Some people's comments implied more than that.
I dare you to find a professional SNOBOL programmer, for any price.
This is really getting off topic but http://www.google.com/search?q=snobol+resume found a few.

That aside, I already acknowledged this point in my previous post.
5) Framework.
Can anyone comment what parts of the framework proved to be "lifesavers"
compared to the "old way"?<<
Are you familiar with Design Patterns?
Since before they were called that.

They are usually solutions to problems that only arise in a specific context.
A bunch of "classic" design patters are unneccessary in, say, LISP or Smalltalk.

I am not familar with the intricacies of the framework. My frirst exposure to .NET was less than a month ago and it is still on a part-time basis.
Some examples where the framework simplifies the developer's job would be appreciated.
6) RAD features.MFC had them, no?<< You are kidding, right?
No, am not.

I never spent much time with MFC (I dislike it) and not yet a lot of time with the framework.
7) Programmer availability.
I guess that if a lot of VB6 coders are "forced" to switch to VB.NET then
the market of .NET developers will get a big boost.<<
Now, you are being prejudiced. I know many excellent programmers in the VB
ranks, and some pretty lousy ones in the C++ ranks.


Not much disagreement from me here. I have seen (and had to maintain) C++ code that still makes me shake my head in amazement.
However, you cannot deny that since VB 6 is very easy to pick up, there are a lot of people using it who lack the fundamentals of computer science and software engineering.
Also, _your_ projects will have
average developers on them, if not now, then later during maintenance. This
is a fact of life. Average developers outnumber top developers about 20 to
1 in my experience.


Again, I agree completely and my statement was meant as an endorsement of .NET rather than a critique.
This is exactly what can persuade a manager: An average .NET developer will cost the company less that a top C++ developer would, even taking talent and knowledge differences into account. An average C++ developer on the other hand would probably not.

Best regards,
Alex.

--
Please replace myrealbox with alexoren to reply by email.

Jul 21 '05 #22

P: n/a
Thank you for your reply Sean,

"Sean Hederman" <em*******@codingsanity.blogspot.com> wrote in message news:d2**********@ctb-nnrp2.saix.net...
"Alex" <re******@myrealbox.com> wrote in message
news:3b*************@individual.net...

Alex, I'm struggling to understand something. You asked for pro/cons to
persuade others and then flat out admitted that you're biased against what
you're supposedly championing.
The only bias that I have comes from familiarity. I've been writing in C++ for a very long time while I have just a cursory exposure to .NET (something that I am working to rectify).

I am very familiar with the shortcomings of C++ but some of the solutions became a second nature to me so I no longer percieve them as overly problematic when applied to myself and others in my situation.

I readily acknowledge the strengths of the .NET platform (at least those that I am aware of) but on the other hand, I find some features overhyped and some omissions uncomfortable (although with the advent of C++/CLI I could have the best of both worlds).
Your statements appear designed to assert that C++ is better than ..NET/C#.


I have NEVER implied that. Perhaps you've became oversensitive from dealing with the people that do?

Some of my statements were biased and some may have assumed the role of the devil's advocate but this is mostly because the people I will have to persuade will be asking me the same questions. Since I think that I will only have one chance to make my case, I need to have answers to these questions. The problem is, I do not have sufficient knowledge of the .NET platform to address these questions so I presented them here in the hope that more experienced people (such as yourself) will supply the answers that are needed.

So far, I got a lot data that I will have to digest and present in a logical fasion.
I would prefer some real world examples of medium-sized companies that made the plunge but one makes do with what one gets.

Best regards,
Alex.

--
Please replace myrealbox with alexoren to reply by email.

Jul 21 '05 #23

P: n/a
"Alex" <re******@myrealbox.com> wrote in message
news:3b*************@individual.net...
Thank you for your reply Sean,
"Sean Hederman" <em*******@codingsanity.blogspot.com> wrote in message
news:d2**********@ctb-nnrp2.saix.net...
"Alex" <re******@myrealbox.com> wrote in message
news:3b*************@individual.net...
Your statements appear designed to assert that C++ is better than
.NET/C#.
I have NEVER implied that. Perhaps you've became oversensitive from
dealing with the people that do?


"My own (admittedly biased) perception is that top developers would achieve
better results given the power and flexibility of C++ but the average
developer will do better with managed code."

That's the statement that got up my nose. I've done more than my share of
C++ development, and I get irritated by the undeserved "techier than thou"
attitude that some C++ developers have. A language is a tool and nothing
more or less. The idea that someone is an inferior programmer based on their
choice of language makes as much sense as thinking that someone driving a
faster car must be a better driver.
Some of my statements were biased and some may have assumed the role of the
devil's advocate but this is mostly because the people I will have to
persuade will >be asking me the same questions. Since I think that I will
only have one chance to make my case, I need to have answers to these
questions.


Fairy nuff.
Jul 21 '05 #24

P: n/a
"Sean Hederman" <em*******@codingsanity.blogspot.com> wrote in message news:d2**********@ctb-nnrp2.saix.net...
"My own (admittedly biased) perception is that top developers would achieve
better results given the power and flexibility of C++ but the average
developer will do better with managed code."

That's the statement that got up my nose. I've done more than my share of
C++ development, and I get irritated by the undeserved "techier than thou"
attitude that some C++ developers have. A language is a tool and nothing
more or less. The idea that someone is an inferior programmer based on their
choice of language makes as much sense as thinking that someone driving a
faster car must be a better driver.


A better analogy is that one had better be an excelent driver to take advantage of a fast car while for the average driver, a sedan or a minivan would be a much better choice. A person driving a fast car COULD be a better driver who has a SPECIFIC need for that car's performance, or he could be asking for trouble. If I see my neighbour driving a Formula-1 I'd say he's nuts. Hell, if I see Michael Schumacher driving his kid to school in his F1, I'd say he's equally nuts. However, you won't see him driving a Civic on a racetrack, would you?

I just admitted that C# / .NET is a more PRACTICAL choice in most cases. If that is not an endorsement then I do not know what is.
Now, if you don't mind, I'd like to get back on topic.
Just got an email from Ryan Storgaard, a platform advisor from Microsoft Canada, who was kind enough to point me to some case studies (http://www.microsoft.com/resources/c...s/product.asp). This will take some time to peruse...
Best wishes,
Alex.

--
Please replace myrealbox with alexoren to reply by email.

Jul 21 '05 #25

P: n/a
Hello Alex,
You can get public numbers from http://www.spr.com
I could not find public data on cpr.com, only reports for sale.
I said "public". I didn't say "free."

The reasons "why" vary from person to person, mostly because each person
finds a different reason for the productivity gains of .Net. Besides,
why
do you care? If its more productive, its more productive. I care because I have been asked these questions when I tried to
informally broach the subject to some decision makers.
I've been told that we would have to (a) purchase new tools and (b)
re-train our developers, both of which costs.
We are not exactly swimming in money so unless I can demonstrate good ROI
in the short-to-medium term, I am not going to have a sympathetic
audience.
You will not get a demonstration from a newsgroup. You will get one from a
demonstration. Have some of the devs write a simple app in C#. Let them
tell you. Better yet, contact the local sales office of MS and have someone
come over and speak with the execs. Walking in to a meeting with an expert
by your side can really help.

I thought you were pulling this stuff together for managers and
executives.
Now I'm beginning to wonder.
Is Cor right?
Cor is free to think and say whatever he (or she) wishes. I am free to
ignore him (or her). Your sig notwithstanding, you still work for Microsoft. When a person
asks for help in nudging his company towards a platform that YOUR EMPLOYER
develops, markets and advocates, making allegations about this person's
motives is not your best course of action. I thank you for your help so far but I can do without the veiled insults.
No insult intended.
5) Framework.
Can anyone comment what parts of the framework proved to be "lifesavers"
compared to the "old way"?<<
Are you familiar with Design Patterns?
Since before they were called that. They are usually solutions to problems that only arise in a specific
context.
A bunch of "classic" design patters are unneccessary in, say, LISP or
Smalltalk.
Your response answered my question, but I don't agree with your implicit
conclusion: that you understood what I meant. I suggest that you read up...
your reply was not indicative of someone who is up to date on OO Design
Patterns.
I am not familar with the intricacies of the framework. My frirst
exposure to .NET was less than a month ago and it is still on a part-time
basis.
Some examples where the framework simplifies the developer's job would be
appreciated.
Not the kind of question that can be reasonably answered in a newsgroup. To
get this level of detail, contact your local MS district office and sign up
for one of the many public talks that are provided, or have a pre-sales
engineer visit your site. They will be much better able to answer detailed
questions like this.
6) RAD features.
>MFC had them, no?<<

You are kidding, right? I never spent much time with MFC (I dislike it) and not yet a lot of time
with the framework.
Another responder did a fine job of answering this already. Basically MFC
is a fine library but isn't RAD in any real sense. Each control had to be
learned seperately from the other, and features that you would expect for OO
systems, like development to interfaces, was sorely lacking. That has been
fixed in the framework, allowing a great deal of flexibility in the way that
the framework can be used and extended.
7) Programmer availability.
>>I guess that if a lot of VB6 coders are "forced" to switch to VB.NET
>>then
>>the market of .NET developers will get a big boost.<< Now, you are being prejudiced. I know many excellent programmers in the
VB
ranks, and some pretty lousy ones in the C++ ranks.

Not much disagreement from me here. I have seen (and had to maintain) C++
code that still makes me shake my head in amazement.
However, you cannot deny that since VB 6 is very easy to pick up, there
are a lot of people using it who lack the fundamentals of computer science
and
software engineering.
agreed.
Also, _your_ projects will have
average developers on them, if not now, then later during maintenance.
This
is a fact of life. Average developers outnumber top developers about 20
to
1 in my experience.

Again, I agree completely and my statement was meant as an endorsement of
.NET rather than a critique.
This is exactly what can persuade a manager: An average .NET developer
will cost the company less that a top C++ developer would, even taking
talent and > knowledge differences into account. An average C++ developer
on the other hand would probably not.


Hey... two points of agreement in a row!

Seriously, you would be surprised how helpful the folks at your local
district office can be. Assuming you are in the US:
http://www.microsoft.com/mscorp/info...s/default.mspx

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

Jul 21 '05 #26

P: n/a
Nick,

Before I wrote that sentence you referred too, had I read the reply from
Alex, who started started his first message with.

"Since I am not an experienced .NET developer by any definition"

I readed constantly sentences as

------------------------------------------------------------------
Not really, as it depends on the user of the object to manually call
Dispose() at the appropriate time.

And

My own (admittedly biased) perception is that top developers would achieve
better results given the power and flexibility of C++ but the average
developer will do better with managed code.
--------------------------------------------------------------------

I am something longer in these newsgroups you know and all trolling threads
have this kind of writting in the second message. However I can be wrong of
course.

I assume that my message had as least the advantage that this thread became
not such a one as we have seen the last days (When you look in the language
vb newsgroup than it is terrible).

:-)

Cor
Jul 21 '05 #27

P: n/a
>> >Now, to the bulk of the answers.
> Very tough questions now, you want proof. ;-)


Not exactly. I have to present a case between people that will want hard

data.I am not saying that I would not be able to be convincing without it but it would be so much easier if I was able to say that company BlahBlahSoft made a similardecision and experienced measurable gains.

It is not easy to overcome corporate inertia.

I know the problem. ;-)

Basically you have to tell them how much more money they will earn if they
would use .NET. ;-)

--
http://www.skyscan.be

Jul 21 '05 #28

P: n/a
> That's the statement that got up my nose. I've done more than my share of
C++ development, and I get irritated by the undeserved "techier than thou"
attitude that some C++ developers have. A language is a tool and nothing
more or less. The idea that someone is an inferior programmer based on their choice of language makes as much sense as thinking that someone driving a
faster car must be a better driver.

Sean I don't think that in the case of Alex that this is an issue. I don't
feel that he is criticizing anything, but he talks about his own experience
and that is if you like it or not always biased. I really think that if he
was convinced that C++ is much better than C# and MFC better than .NET then
he would really never started to ask for feed-back.

My feeling is that he really wants to move to .NET, but he lacks experience
so we have to help him.

Alex does a great job with this topic and I hope that he somehow publicizes
his findings (in this newsgroup?) so that other programmers might have a
good basis in order to convince their bosses that it is a good step to start
using .NET.

I do agree that a lot of C++ programmers feel superior towards other
programmers, and in most cases they create their programs from programmer
point of view to show off what they can do, but sadly enough those programs
are not very user friendly and in most cases the user must adapt to the
program instead of the programmer adapt to the user.

But this is a real world situation, we have no other choice to accept that
people like these exist, but there are also many C++ programmers that are
not totally like that. :-)

Alex, keep up the good job. :-)
--
http://www.skyscan.be
Jul 21 '05 #29

P: n/a
>Again, I agree completely and my statement was meant as an endorsement of
..NET rather than a critique.
This is exactly what can persuade a manager: An average .NET developer will cost the company less that a top C++ developer would, even taking talent and knowledge differences into account. An average C++developer on the other hand would probably not.

Not only this, but an average developer does not have a company in it's
grip.
If you create a program and then the top developer says, pay more or I go,
then you are stuck with him/her because others do not understand tehe
created code.

But I have another interesting new item that would promote .NET programs, is
the deployment and updating.
..NET programs can be put on a server and in combination with a xml file
describing the most recent version, people automatically gets the latest
version of the application without need to re-install.
From IT point of view, this is very nice since I do not have to go to every
machine to check the version and update the program. I just put it on the
server, change the xml file and it is automatically updated.

To be honest I never used it, so I only know it by reading stuff, but it
looks promising.

--
http://www.skyscan.be
Jul 21 '05 #30

P: n/a
Olaf,

This behaviour is called click once update and will be as a kind as standard
version in Net 2.0.

However it is not difficult to make when you use features from Net.

In a program you have than
A simple webservice to see what are the latest version
Check that to your current version
A simple webclient.downloadfile(s) to get the builds
Some renaming functions and it is done.
The only problem is when you have to get a new update program, however even
that is not difficult to implement.

There is as well something already for Net 1.1 in that you see as well a
description for 2.0

http://msdn.microsoft.com/library/de.../updaterv2.asp

I hope this gives an idea.

Cor
Jul 21 '05 #31

P: n/a
And another interseting thing is form inheritance.
You can create your's custom controls by inheriting a
System.Windows.Forms.UserControl.
Now you get a panel and you drag and drop all the components on it. Create
your functionality, test it and save it.

Open your main program, and now you can drag and drop the full working
custom made control on your main form and see it in action. And you see live
data. The MFC way is very very very cumberson and during the development of
a dialog box, you get these big black spaces that represents your custom
control but you have no idea what it is until you run it.

--
http://www.skyscan.be
Jul 21 '05 #32

P: n/a
> This behaviour is called click once update and will be as a kind as
standard
version in Net 2.0.

That is it! :-)
I forgot the name.

By the time Alex convinces his boss, the VS 2005 will be available and so
..NET 2.0 ;-)
I saw a report that in the VC 2005 (C++? C#?) you can be able to test your
function in design mode? No need to recompile? This could also improve the
development cycle dramatically.

Right now I am porting code that I already created in a .NET program to C++
using MFC, but I get really depressed if I see how complicated the MFC way
is.
One function must be spread to mutiple functions distributed at different
locations. And I am only talking about a simple edit field with a spin
button. :-(

Another control I have to emulate is a control that have one slider, a left
and right static field and a field below that represents the current slider
position.
I have a.NET custom made control that does all that, just drag and drop and
your gone, but now I have to do that the MFC way and and that is a
nightmare.

And I am not talking about tabbed forms and greying out controls. The .NET
way is to create a panel/group box, drop the controls on that and disable
the panel and all controls are grayed out.
The MFC way is to gray every control out manually. This means I have to
create a variable even for the static texts to grey them out.

But this work has to be done, so let's gather some motivation and do the
thing. ;-)

Maybe another point for Alex:
If you do it the MFC way then it takes more time to see something visually.
But if you do it the .NET way then it is very rewarding for the programmer
and the boss because you see your program getting better and better in real
time. :-) Programmers and bosses gets motivated and really love their job,
so become even more productive. :-) Just an idea?

--
http://www.skyscan.be
Jul 21 '05 #33

P: n/a
> I know the problem. ;-)

Basically you have to tell them how much more money they will earn if they
would use .NET. ;-)


Exactly!

You have hit the nail on the head.

The bottom line should be - "This will save us money. HEAPS of money."
However I have to break it down and present some proof.

So far I have:
* Increased productivity --> less time spent developing products (time is money)
* Better integration with testing tools --> less time spent in QA
* More robust code --> less time spent in support
* Easier and "safer" development --> can hire less expensive developers

Did I miss anything?

On the "cons" side:
* Existing developers need retraining (time, money, "beginners' mistakes")
* Supporting yet another technology (old products WILL NOT be rewritten but still supported)

Currently I'm working on the "proof" side.
While I have no reason to doubt your accounts, managers like nicely presented case studies by big companies.

Jul 21 '05 #34

P: n/a
Dear Cor,

This is my first reply to you.
I hope it addresses your concerns because it will also be the last one on this subject.

"Cor Ligthert" <no************@planet.nl> wrote in message news:%2****************@tk2msftngp13.phx.gbl...
Before I wrote that sentence you referred too, had I read the reply from
Alex, who started started his first message with.

"Since I am not an experienced .NET developer by any definition"
True, I am not. Yet...
I have experience with C++ and Java, as well as other, less popular languages.
I an currently writing a "demo / prototype" project in C# and reading a lot on the subject.
I also regestered to DevTeach 2005 and hope to get something out of it.

Do not confuse lack of experience with ignorance.
I readed constantly sentences as

Not really, as it depends on the user of the object to manually call
Dispose() at the appropriate time.
This comes from my Java experience.
I worte class libraries that used non-memory resources that just *had* to be released in a timely manner.
GC does not solve this problem. Finalizers do no solve this problem.
Requiring the users of the class to call a cleanup function worked but caused a lot of problems due to the fact that they just "forgot" to do it.
In C++, stack based objects and destructors make this specific issue much easier to handle.

My understanding is that (managed extensions to C++ and C++/CLI notwithstanding) managed .NET code uses the same principles.
Was I wrong?

The reason that I mentioned it in the first place is that I think that GC is not the main reson to switch to .NET and in our case, since some of our developers have been bitten by blindly relying on the Java GC, it is not even a "good" reason.

Therefore, I asked for other compelling reasons.

Context is everything.
And

My own (admittedly biased) perception is that top developers would achieve
better results given the power and flexibility of C++ but the average
developer will do better with managed code.
Statement based on a experience with C++ plus external resources (boost, loki, ACE, etc.) and Java, plus reading material on .NET and cursory familiarity parts of the .NET framework.

Statement clearly identified as "perception" (not fact!) and the extistance of bias openly admitted.

Perceptions can and do change.
I am something longer in these newsgroups you know and all trolling threads
have this kind of writting in the second message. However I can be wrong of
course.


So you are a regular of this group, yet you spend your time trying to prove that I am trolling instead of adding to the discussion.

Thankfully, others (like Nick, Olaf and Sean) have provided me with valuable information and demonstrated patience and goodwill even when they disagreed with some of my statements.

Alex.

--
Please replace myrealbox with alexoren to reply by email.

Jul 21 '05 #35

P: n/a
Alex <re******@myrealbox.com> wrote:
The reason that I mentioned it in the first place is that I think
that GC is not the main reson to switch to .NET and in our case,
since some of our developers have been bitten by blindly relying on
the Java GC, it is not even a "good" reason.


It's a very good reason - so long as you know what you're doing. Like
almost any other technology, you need to know what it's capable of and
what it's not capable of. It's wonderful when it comes to memory, but
awful for unmanaged resources - so don't use it for unmanaged
resources.

The "using" statement makes disposing of unmanaged resources in C# very
easy for the most part (when you don't need to embed them in objects
themselves) and the disposable pattern makes it easy to extend to the
rarer cases.

You've cited cases where Java developers have assumed that the GC can
cope with non-memory resources in a timely fashion - my counter-example
is that there are plenty of C++ programs which leak memory and wouldn't
if they used GCs. (Yes, there are GCs available for C++, but again you
end up with a particular "dialect" of C++ rather than "plain" C++.) The
GC should only be used to deal with memory, but I find that memory is
the resource I use most often.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #36

P: n/a
Hello Nick,

"Nick Malik [Microsoft]" <ni*******@hotmail.nospam.com> wrote in message news:O9********************@comcast.com...
I said "public". I didn't say "free."
Sorry, my mistake. Unfortunately company will not pay at this point (getting them to pay for the DevTeach conference was hard enough) and I will not spend my own money on it. Oh, well, I'll try to find public and free resources.
You will not get a demonstration from a newsgroup.
No, but I may get a link to a case study, if available.
Have some of the devs write a simple app in C#.
I am writing one as we speak.
Managed to convince the powers that be that a prototype shoud be throwaway so it does not really matter if I use a different technology.
Let me tell you, trying to beat the deadlines while learning a new technology at the same time can be challenging...
Your response answered my question, but I don't agree with your implicit
conclusion: that you understood what I meant. I suggest that you read up...
Why don't you tell me what design patterns the framework implements?

As I said, I have a platform to learn and project to complete and it has to be done faster than planned and have more functionality as a proof that the .NET platform makes one more productive... while at the same time gather information for a case to switch technologies.
I don't have a lot of time left to delve into the parts of the framework that do not relate directly to what I am currently working on.
have a pre-sales engineer visit your site.
You see, that's the kind of information that I wouldn't know. Thanks!
Another responder did a fine job of answering this already. Basically MFC
is a fine library but isn't RAD in any real sense. Each control had to be
learned seperately from the other, and features that you would expect for OO
systems, like development to interfaces, was sorely lacking. That has been
fixed in the framework, allowing a great deal of flexibility in the way that
the framework can be used and extended.
Too much flexibility, I'd say. And the (incomplete) documentation is spread all over the place...
Sometimes it is an excercise in frustration to make things work like intended. Grrrr....
Sorry, had to vent, feeling better now :-)
Hey... two points of agreement in a row!
I was not in disagreement with you in the first place.

What I was saying is that there are certain arguments pro or anti the switch to .NET that may hold a lot of weight in our company and there are others that will be dissmissed right away.
Seriously, you would be surprised how helpful the folks at your local
district office can be. Assuming you are in the US:
http://www.microsoft.com/mscorp/info...s/default.mspx


Slightly off - Canada, Ontario, Toronto area.

Best wishes,
Alex.

--
Please replace myrealbox with alexoren to reply by email.

Jul 21 '05 #37

P: n/a

"Olaf Baeyens" <ol**********@skyscan.be> wrote in message news:42***********************@news.skynet.be...
Sean I don't think that in the case of Alex that this is an issue. I don't
feel that he is criticizing anything, but he talks about his own experience
and that is if you like it or not always biased. I really think that if he
was convinced that C++ is much better than C# and MFC better than .NET then
he would really never started to ask for feed-back.
For the record: MFC is an abomination.
Alex does a great job with this topic and I hope that he somehow publicizes
his findings (in this newsgroup?) so that other programmers might have a
good basis in order to convince their bosses that it is a good step to start
using .NET.
I will.
I do agree that a lot of C++ programmers feel superior towards other
programmers, and in most cases they create their programs from programmer
point of view to show off what they can do, but sadly enough those programs
are not very user friendly and in most cases the user must adapt to the
program instead of the programmer adapt to the user.

But this is a real world situation, we have no other choice to accept that
people like these exist, but there are also many C++ programmers that are
not totally like that. :-)


In my experience, one becomes a better programmer when he/she understands the nature of the tools at his/her disposal, their strengths and weaknesses and how to leverage the former and work around the latter.

C++ programmers have no choice. They have to understand the internals in order to avoid the numerous traps and "gotcha"s inherent in the language otherwise the project they work on will fail.

This is similar to MFC vs. straight Win32. Sure, MFC provided a quick way to so some things seemingly without the need to know what went on behind the scenes but I've worked with people who purported to be MFC experts but had limited understanding of the Win32 layer and the way the MFC wrappers interacted with it. They got stuck whenever they tried to coerce some flexibility out of the framework.

My experience of assembly helped me with C. My experience with C++ helped me with Java.
And, it already helps me with learning C#. By way of analogies:
Why does a==b usually (but not always) different from a.Equals(b)? Because with reference types a and b are actually pointers to the GC heap.
What's a delegate? An object encapsulating a function or method pointer.
Events? Piece of cake - fancy callbacks.

Does the fact that C++ is currently one's language of choice makes that person a better programmer? Not necessarily.
But if one has worked with several different languages and was curious enough to learn what makes them tick, then that does.

Best wishes,
Alex.

--
Please replace myrealbox with alexoren to reply by email.

Jul 21 '05 #38

P: n/a
Alex,

I can be wrong I told.

I don't know if I wrong in this, however I miss a great advantage what is
the framework.

This set what is a OS extention, can save you in future a lot of useless
rolout time at your customers. You don't have to add by instance all kind of
runtimers because all is already build in that framework.

As well can using the framework give you a very standarized UI. What
probably will save the client education time, for what he will be glad with.

Maybe for your economic report.

When I was wrong, sorry I did not say it that hard, however I got with your
second message that feeling.

Cor
Jul 21 '05 #39

P: n/a
Hello Jon,

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message news:MP************************@msnews.microsoft.c om...
The "using" statement makes disposing of unmanaged resources in C# very
easy for the most part (when you don't need to embed them in objects
themselves) and the disposable pattern makes it easy to extend to the
rarer cases.


Can you please suggest what is the preferred way of utilizing "using" when one has several heterogeneous items to dispose?

Thank you.

Best regards,
Alex.

--
Please replace myrealbox with alexoren to reply by email.

Jul 21 '05 #40

P: n/a
Alex <re******@myrealbox.com> wrote:
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
The "using" statement makes disposing of unmanaged resources in C# very
easy for the most part (when you don't need to embed them in objects
themselves) and the disposable pattern makes it easy to extend to the
rarer cases.


Can you please suggest what is the preferred way of utilizing "using"
when one has several heterogeneous items to dispose?


Just nest them:

using (...)
{
using (...)
{
...
}
}

If you don't like the deep indentation, you can do:

using (...)
using (...)
using (...)
{
...
}

My main point, however, which you've snipped, is that automatic memory
management is a big win. The unmanaged resource management isn't that
hard with just a bit of discipline - which you need in C++ too...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #41

P: n/a
"Alex" <re******@myrealbox.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
On the "cons" side:
* Existing developers need retraining (time, money, "beginners' mistakes")


No formal case studies, but just my experience:
When we moved our workflow product team to .NET, we saw a 20-30% drop in
productivity. After about 2 months we were back to parity, and gradually
moved to 40-50% increased productivity 6 months later. Keep in mind that we
moved a disparate group, some VB6, some Delphi, some C++, but all fairly
senior.
Jul 21 '05 #42

P: n/a
Good points, mea culpa.

Alex, sorry for assuming the worst.

"Olaf Baeyens" <ol**********@skyscan.be> wrote in message
news:42***********************@news.skynet.be...
That's the statement that got up my nose. I've done more than my share of
C++ development, and I get irritated by the undeserved "techier than
thou"
attitude that some C++ developers have. A language is a tool and nothing
more or less. The idea that someone is an inferior programmer based on

their
choice of language makes as much sense as thinking that someone driving a
faster car must be a better driver.

Sean I don't think that in the case of Alex that this is an issue. I don't
feel that he is criticizing anything, but he talks about his own
experience
and that is if you like it or not always biased. I really think that if he
was convinced that C++ is much better than C# and MFC better than .NET
then
he would really never started to ask for feed-back.

My feeling is that he really wants to move to .NET, but he lacks
experience
so we have to help him.

Alex does a great job with this topic and I hope that he somehow
publicizes
his findings (in this newsgroup?) so that other programmers might have a
good basis in order to convince their bosses that it is a good step to
start
using .NET.

I do agree that a lot of C++ programmers feel superior towards other
programmers, and in most cases they create their programs from programmer
point of view to show off what they can do, but sadly enough those
programs
are not very user friendly and in most cases the user must adapt to the
program instead of the programmer adapt to the user.

But this is a real world situation, we have no other choice to accept that
people like these exist, but there are also many C++ programmers that are
not totally like that. :-)

Alex, keep up the good job. :-)
--
http://www.skyscan.be

Jul 21 '05 #43

P: n/a
Hello Sean,

"Sean Hederman" <em*******@codingsanity.blogspot.com> wrote in message news:d2**********@ctb-nnrp2.saix.net...
"Alex" <re******@myrealbox.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
On the "cons" side:
* Existing developers need retraining (time, money, "beginners' mistakes")


No formal case studies, but just my experience:
When we moved our workflow product team to .NET, we saw a 20-30% drop in
productivity. After about 2 months we were back to parity, and gradually
moved to 40-50% increased productivity 6 months later. Keep in mind that we
moved a disparate group, some VB6, some Delphi, some C++, but all fairly
senior.


Good info, thanks!

--
Address email to user "response" at domain "alexoren" with suffix "com"
Jul 21 '05 #44

P: n/a
Hello Jon,

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message news:MP************************@msnews.microsoft.c om...
Alex <re******@myrealbox.com> wrote:
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Can you please suggest what is the preferred way of utilizing "using"
when one has several heterogeneous items to dispose?


Just nest them:
If you don't like the deep indentation, you can do:

using (...)
using (...)
using (...)
{
...
}


I guess that will have to do.

Thank you.

--
Address email to user "response" at domain "alexoren" with suffix "com"
Jul 21 '05 #45

P: n/a
Hello Alex,

Perhaps this will help.
Seriously, you would be surprised how helpful the folks at your local
district office can be. Assuming you are in the US:
http://www.microsoft.com/mscorp/info...s/default.mspx
Slightly off - Canada, Ontario, Toronto area.




Microsoft Canada Co.
1950 Meadowvale Blvd
Mississauga, Ontario
L5N 8L9
Canadian Head Office: (905) 568-0434
Customer Inquiries: (877) 568-2495
Microsoft TT/TDD: (905) 568-9641
Microsoft Order Centre: (800) 933-4750

I don't know how far Mississauga is from your location (especially since I
don't know precisely where your location is :-), but I'm sure that they will
be helpful. I've worked with the good folks in my local district office on
occasion over the years, and they are nothing if not helpful, fair, and
informative.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--


Jul 21 '05 #46

P: n/a
Hello Alex,
Your response answered my question, but I don't agree with your implicit
conclusion: that you understood what I meant. I suggest that you read
up...
Why don't you tell me what design patterns the framework implements?


That's fair.

Unfortunately, it would be difficult to catalog all of the patterns, and
which framework item uses which pattern, without an extensive amount of time
dedicated to the topic. Cataloging would not prove very much, and isn't the
most interesting work (it's up there with counting spots on the backs of
insects... something that most of us are quite happy to let _other_ folks do
for us).

Clearly, the Observer pattern (and its cousin, the Event pattern) are
heavily used, as are the Factory Method, Builder, Iterator, Strategy and
Bridge.
I can make a case for Singleton as a supported pattern but I don't know
where the framework uses it.
I'm pretty sure that IClonable is essentially an implementation of the
Prototype pattern.
The XML classes use Composite quite a bit.
The IO classes make use of the Decorator pattern.
..Net Remoting and web services make heavy use of the Proxy pattern .
I could make a fairly strong case that Visitor and Adapter are used by the
data classes.

A page of articles on design patterns in .Net can be found here
http://www.windowsforms.net/Articles...131&tabindex=3

A good site for sharing of design patterns can be found here
http://patternshare.org/default.aspx/Home.TableColumns

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
Jul 21 '05 #47

P: n/a
> As well can using the framework give you a very standarized UI. What
probably will save the client education time, for what he will be glad with.

I think that the UI is the first reason why people will start using the
..NET.
I do it too because I can create user interfaces very fast that are nice,
stable and very user friendly compared to the MFC way.
But when I need the raw processing power, most funtions are still
conventional C++.
What I do now is try to write unmanaged C++ in a .NET way, or at least close
to it, so that this part of the code is ready when I port it to the .NET way
of life. Especially using properties, using private as much as I can, and
use delegates/events as much as I can and avoid the SendMessage() way of
communicating.

I see that ATI have a .NET program to configure the their network card.

And I discovered Friday that Pincacle Studio 9 also uses the .NET framework,
and I think it is for their wizard.

--
http://www.skyscan.be
Jul 21 '05 #48

P: n/a
>> Have some of the devs write a simple app in C#.
I am writing one as we speak.
Managed to convince the powers that be that a prototype shoud be throwaway

so it does not really matter ifI use a different technology.
Maybe a very good reason to use the .NET programs is use it as fast
prototyping tool to test new interfaces and code functionality.
Maybe this way they all get hooked by it in time when they discover how fast
you can produce code and that actually works.
Let me tell you, trying to beat the deadlines while learning a new technology at the same time can be challenging...

I know, one of the most interesting aspects of beeing a programmer. ;-)
Performing miracles. :-)

You feel the adrealine rushing through your vanes, very addictive. :-)

--
http://www.skyscan.be
Jul 21 '05 #49

P: n/a
>On the "cons" side:
* Existing developers need retraining (time, money, "beginners' mistakes")
* Supporting yet another technology (old products WILL NOT be rewritten but still supported)

Although I am a big favour of .NET it has also cons sides.
And it would morally be not right if I would hide these negative sides.

* The resistance of people to install the .NET framework. You would not
believe what stories they come up in order not to install it. Typical would
be: It slows down my computer, It is too big, I don't believe in it,....
* At this moment installing the .NET framework is far too complicated. New
distributions of Windows XP seems to contain the .NET framework, but from
the summer on we will have a new one the v2.0. So I hope the installation
becomes a one click situation. The situation through critical updates is
currently too complicated for my grandmother that wants to browse the
Internet and read email.
* Installation is a bit complicated because of the security issuses if the
program needs internet and/or LAN access. Luckily this can be easily fixed
by creating a managed dll that contains registration code to give your
program enough access to access the LAN and Internet. You cannot grant
access rights from inside your program, but you can make the setup run that
managed code to give program user rights. The setup.exe is not a managed
code so it does have access to the user rights. And if people double click
on a setup then we assume that they know what they are doing.
* The resistance of the VB and C++ programers since they have to relearn
everything, becoming a newbie.
* The error reporting that would give a user a heart attack when something
goes wrong like no LAN access, or when you try to run the program from a
networkdrive by double clicking on it. You get an error like the "access
violation" type with a list of all assemblies loaded, where even normal
programmers have no idea what it all means. This is very user-unfriendly.

These are the ones that comes to my mind...

Especially the resistance to install the .NET framework by the users and the
resistance of older C++ programmers is the biggest hurdle to overcome in my
opinion. I classify this phonomenon as "The big scare". Scare of the unknown
because it is baseless.
Luckily time is in our favour here.

--
http://www.skyscan.be
Jul 21 '05 #50

55 Replies

This discussion thread is closed

Replies have been disabled for this discussion.