Opinions on .NET Framework?

  • Thread starter Thread starter roy.anderson
  • Start date Start date
R

roy.anderson

Question: Is there a site that lists (or share your opinions, please)
the relative strength/weakness of programming in C# or VB?

Question: Is there a site (or share your opinions) that lists the
relative strength/weakness of a PC app vs a Web app? The assumption
here is that the app will be for inhouse use only.

Thanks!
 
Question: Is there a site that lists (or share your opinions, please)
the relative strength/weakness of programming in C# or VB?
Click to expand...

People which is not a language fanatic agree that in .NET the language of
choice is only a matter of personal preference for syntax since there are
only minor differences (removed in the upcoming 2005 versions of the
languages) and most of the bulk is in the .NET Framework class library,
which is common. So, if yoy like "{", "}" and ";" use C# and if you like
verbose "End XXX" use VB.NET.

That said about the languages, the IDE is somewhat more productive for
VB.NET because of its background compiler which produces better Intellisense
experience (I have used both).
Question: Is there a site (or share your opinions) that lists the
relative strength/weakness of a PC app vs a Web app? The assumption
here is that the app will be for inhouse use only.
Click to expand...

Again, people which is not a Web fanatic agree that if deployment to clients
is not an issue, currently PC apps more user friendly (better UI, better
responsiveness, etc.), more robust (using .NET, COM is another story) and
take less time to develop.

--

Carlos J. Quintero

MZ-Tools 4.0: Productivity add-ins for Visual Studio .NET
You can code, design and document much faster.
http://www.mztools.com
 
There are probably at least 50,000 threads on this topic. Just search
the newsgroups for C# vs VB.
 
There is a white paper on this topic, differences between VB.NET and C#
http://support.microsoft.com/?kbid=308470

VB.NET has background compilation, which is a huge plus. It automatically
detects errors as you edit your source code. In C# errors are detected when
you build your project.

It's also a bit simpler to do late binding. For example, if you want to
support multiple versions of office without knowing in advance what version
it is, you need to use late binding.
In VB.NET you would do

option strict off
....
Dim excelApp as object = CreateObject("Excel.Application")
excelApp.Visible = False
Dim excelWorkbooks as object = excelApp.WorkBooks

The equivalent in C# is

Type excelType = Type.GetTypeFromProgID("Excel.Application");
object excelApp = Activator.CreateInstance(excelType);
object[] params = new Object[1];
params[0] = true;
excelApp.GetType.InvokeMember("Visible", BindingFlags.SetProperty, null,
excelApp, params);
object excelWorkbooks = excelApp.GetType.InvokeMember("Workbooks",
BindingFlags.GetProperty, null, excelWorkbooks, null);

It's a lot more cumbersome in C#.

With that said, I much prefer C# because there are more options for
Refactoring.
The .NET framework is centered around object oriented development. In my
opinion OO and Refactoring go hand in hand. The SmallTalk and Java tools
community have had automated refactorings for a long time. However it seems
Microsoft OO tools have been extremely late in this. C# in VS.NET 2005 will
have automated refactorings built in, but VB.NET will not. IntelliJ has
ReSharper, which is an excellent refactoring add-in for C#. It also does
background compilation a la VB.NET.

There are no viable VB.NET refactoring tools out there.

Automated refactoring may not be important for a lot of people, but it is
important for me. Writing good maintainable code that adheres to OO
principles is the reason why anyone should use an OO language.
 
Question 1: There are tons of them

Primarily it comes down to this:

C#
1. Shorter syntax (easier to type)
2. Ability to call "unsafe" code (ie, unmanaged code pointers, etc.)
3. More explicit model out of the box

VB.NET
1. Easy late binding syntax (no need to invoke Reflection directly)
2. VB COM style helper functions (note: perf hit for using)

Other than that, they tend to compile to the same IL, so they are
functionally equivalent. There are a few other bullet points. Beyond that,
most of the arguing is personal preference.

Question 2:
Web apps are stateless in nature and have all of the code on a server (in
most cases), so they are easier to update. Windows Forms are better for
connected apps overall, as web apps are kludged to hold state. If you connect
and stay connected, or deal with large amounts of data updates in one form,
you are better to go windows. If extreme perf is a concern, windows may also
win. Otherwise, I would generally go web. If you design your tiers correctly,
or use SOA (service oriented architecture), the UI (web or winForms) is a
presentation layer only, so you can easily switch to whichever model suits
you at the moment (in other words, move non-presentation code out of your UI
and into classes and you can go either way).


---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
Cowboy (Gregory A. Beamer) - MVP said:
Question 1: There are tons of them

Primarily it comes down to this:

C#
1. Shorter syntax (easier to type)
2. Ability to call "unsafe" code (ie, unmanaged code pointers, etc.)
Click to expand...

Be careful here - unsafe code is *not* unmanaged code. There's a big
difference.
 
VB.NET has background compilation, which is a huge plus. It automatically
detects errors as you edit your source code. In C# errors are detected
when you build your project.
Click to expand...

That said, I already find the mere syntax-checking stuff built into the C#
code editor to be somewhat irritating at times, particularly when I'm in the
middle of complicated code refactoring tasks. There are plenty of times
when I'll move a method from one class to another, and decide for a variety
of reasons to change variable and parameter names, return types, or
whatever. I sometimes find it irritating to have the code editor putting
little red squigglies under stuff that I know I need to fix and I'll get to
it when I'm damn good and ready. At times like those, I'm entirely happy
not to also have blue squigglies showing up due to a background compiler
also cranking away while I'm not looking.

Admittedly, a lot of this will get better after MS gets around to releasing
VS 2005 (hey, MS, if you're listening, please hurry up with that!) because
of the code-refactoring functionality that they've added. I in particular
can't wait to have automatic re-naming of variables. God that's a long long
overdue feature...
 
C#
Be careful here - unsafe code is *not* unmanaged code. There's a big
difference.
Click to expand...

Ok, that's a tantalizing statement. Care to clarify for those of us who
have not necessarily memorized Don Box's "Essential .NET" book yet?
 
MS News (taruntius) said:
Ok, that's a tantalizing statement. Care to clarify for those of us who
have not necessarily memorized Don Box's "Essential .NET" book yet?
Click to expand...

Sure. Unsafe code is still written in C#, and still executed within the
CLR - it's still IL which is JITted, and still has a lot of the safety
features of the CLR. It just doesn't have *all* of them - so you can
use pointers and the like. Here's the definition from the C# spec:

<quote>
Unsafe code - code that is permitted to perform such lower-level
operations as declaring and operating on pointers, performing
conversions between pointers and integral types, and taking the address
of variables. Such operations provide functionality such as permitting
interfacing with the underlying operating system, accessing a
memory-mapped device, or implementing a time-critical algorithm.
</quote>

Unmanaged code, however, is native code which must have been written in
another language, and is usually part of a separate DLL - interop,
basically.
 
First, DB2 is a database server, much like Microsoft SQL Server, and the
..Net platform is a programming platform, much like Java. So, your question
doesn't make sense. Second, I did a little research, and darned if I
couldn't find a product comparison on the IBM DB2 web site that compares DB2
to SQL Server. But I *did* find a comparison on the Microsoft SQL Server
site. You may want to check it out:

http://www.microsoft.com/sql/prodinfo/compare/ibm/default.mspx

--
HTH,

Kevin Spencer
Microsoft MVP
Short Order Coder
http://unclechutney.blogspot.com

What You Seek Is What You Get
 
Since it is the only development platform made by Micorosft for building
Windows based applications, I'd say it's pretty valid.
 
My point being that Microsoft doesn't support VS 6.0 anymore, they only
support VS .NET. So, in MS's eyes .NET is the development platform to be on
for Windows development.
 
Scott M. said:
My point being that Microsoft doesn't support VS 6.0 anymore, they only
support VS .NET. So, in MS's eyes .NET is the development platform to be on
for Windows development.
Click to expand...

VS.NET can be used to develop non-.NET products though. (Note, by the
way, that Visual Studio 2005 has dropped the ".NET" part of the title.)

From Solution Explorer, choose Add -> New Project -> Visual C++ and
you'll see lots of options only some of which are .NET-based.

Native code development is still very much supported. There are various
situations which don't lend themselves to purely-managed solutions:
games and drivers spring to mind for starters.
 
In Microsoft's eyes, Visual Studio is the IDE for all kinds of Windows
development, including native C++. Visual Studio 6 is 3 generations behind
the latest version. And the IDE is not the .Net platform, but a set of
programming tools.

--
HTH,

Kevin Spencer
Microsoft MVP
Short Order Coder
http://unclechutney.blogspot.com

What You Seek Is What You Get
 
Back
Top