advise VB.Net or C#

[Navarone]

I have been developing small applications in VB6 for about a year now and I feel our applications are pushing the VB envelope and think we should consider different programing language. Most of what I have done are all windows based applications. I have not used VB.Net or C# but I was told there almost identical.

For building window applications or software, what is the best suited programing lanqauge?

[Memnoch1207]

Either one is fine for developing Windows or Web apps.

[nswan]

I'd just toss a coin!!

[Navarone]

Is one easier to learn than another. Would it be easier to migrate into VB.Net seeing as how I already know some VB?

[Kasracer]

I'd go for C#. No matter which one you choose, you're going to have to learn a whole new language.

[Memnoch1207]

VB.Net would have a smaller learning curve, considering you already know VB, but once you are comfortable working in .NET, I would recommend you learn C# as well.

[Navarone]

hey thanks for the tips. I see there is also a C#.Net. Is this what you mean or just plain C#.

[Kasracer]

Originally posted by Navarone
hey thanks for the tips. I see there is also a C#.Net. Is this what you mean or just plain C#.

There is no 'plain' C#. C# is a standardized language but no compiler exists that compiles C# without the .NET framework, nor are their any standard libraries.

[Navarone]

So if I order the C# software, how should I order it?

[Edneeis]

Here is a white paper from Microsoft that outlines the difference between VB.NET and C#:
http://support.microsoft.com/?kbid=308470

As for how to order it, I believe there is a C# Standard edition with just that language otherwise (and I recommend this if you can afford it) you can get VC++, C#, and VB.NET in one of the Visual Studio.NET Packages (Pro, Enterprise Dev, Enterprise Arc.). The Professional version will probably be just fine and I'd recommend getting 2003 over 2002.

http://www.pricegrabber.com/search_g...7f9e826771e5b5

[Priore]

IMO, it's easier to move from VB6 to VB.Net than it is to move from VB6 to C#.
But I agree with others when they say once you learn VB.Net, it's not hard to move to C# (and it's fun too ).

[PT Exorcist]

Originally posted by Priore
IMO, it's easier to move from VB6 to VB.Net than it is to move from VB6 to C#.
But I agree with others when they say once you learn VB.Net, it's not hard to move to C# (and it's fun too ).

I believe the oposite, he will just continue to use his bad vb6 habits, starting C# from the ground would probably make him addopt new programming styles.
Also VB.NET has things like ReDim, the VB6 compability namespace that I think that are in a way or in other bad programming habits..

[hellswraith]

Originally posted by PT Exorcist
I believe the oposite, he will just continue to use his bad vb6 habits, starting C# from the ground would probably make him addopt new programming styles.
Also VB.NET has things like ReDim, the VB6 compability namespace that I think that are in a way or in other bad programming habits..

I agree with you.

[Priore]

Originally posted by PT Exorcist
I believe the oposite, he will just continue to use his bad vb6 habits . . .

Oh, I'm sorry, I didn't realize you know him personally.

Anyway, I don't know him so I didn't assume that he has "bad habits" just because he is a vb6 programmer.

I don't think I had them . . . but that is a biased opinion.

And I don't assume a vb6 programmer knows only vb (I knew several languages before learning .Net)

All in all, I guess it's not a simple question to answer, as there can be many factors to consider.

EDIT:
BTW, my reason for thinking that vb6 to vb.Net would be easier is because the languages are similar and he could focus his efforts on familiarizing himself with the .Net Framework (and then moving to C# when comfortable using the Framework). ---- Depends on your point of view.

[PT Exorcist]

Well...

I dont know him and as he didnt mention if he knows or not another languages I assumed he doesnt. And if he does then that's awesome, if he knows C++ or java he will have 0% learning curve when we talk about learning new keywords

Even if he has VERY GOOD programming habits in VB6 , in .NET things are most of the times done 180º in the other way. What he will try to do (and don't denny it, I see that like 80% of this VB.NET section do it) is make heavy usage of the VB6 compability namespace when you can simply use the .NET version of the functions..

Peace

[hellswraith]

Originally posted by PT Exorcist
Well...

I dont know him and as he didnt mention if he knows or not another languages I assumed he doesnt. And if he does then that's awesome, if he knows C++ or java he will have 0% learning curve when we talk about learning new keywords

Even if he has VERY GOOD programming habits in VB6 , in .NET things are most of the times done 180º in the other way. What he will try to do (and don't denny it, I see that like 80% of this VB.NET section do it) is make heavy usage of the VB6 compability namespace when you can simply use the .NET version of the functions..

Peace

Again, I agree 100%.

The best VB6 programmer is going to have to change some ways of thinking when doing .net development to do it effectively. If they don't have to change much, then they are not taking advantage of all the new stuff offered to them.

[formulav8]

VB.Net was not that bad at all for me to learn. And it is because I already knew visual basic. He would without a doubt learn VB.Net easier than C# since alot of the VB.Net syntax is similar to the classic versions. Of course, that is just my opinion.


Jason

[hellswraith]

Originally posted by formulav8
VB.Net was not that bad at all for me to learn. And it is because I already knew visual basic. He would without a doubt learn VB.Net easier than C# since alot of the VB.Net syntax is similar to the classic versions. Of course, that is just my opinion.


Jason

That is your opinion, but are you still using MsgBox, or are you using MessageBox.Show? Are you using Len() instead of string.Length? Are you still using Right() or Left() or Mid() instead of string.Substring()?

If you are, then it is my opinion that you didn't LEARN .Net, you learned how to do the same thing you did in vb6 in vb.net. You learned how to get around some of the little 'frustrations' like no control collections, or shared form instances instead of learning why they are not there.

There are just soooooo many of those old habits that people still use from VB6, and I argue if they are truly learning .Net. They are using compatibility classes that wrap existing functionality. Why would you add an extra layer?

This is just my opinion, and like everyone else, I believe mine to be right...lol.

Now, this isn't to say that learning VB.Net is wrong. I just think there are two ways to go about it. If you are eager to remove your old practices, then learning vb.net or C# won't matter. If you just want to move over to .Net to say you know it, and still carry old habits, then vb.net makes that easy for you, and you won't quite be as effective in .net as others. I see C# as a way to force a VB6 person into learning .Net for what it is without any biases, or old habits. This lets the mind free up faster into the new way of doing things. Again, just my opinion, and I am starting to get tired so I am rambling on.

[Edneeis]

I still use MsgBox but feel that I do things the .NET way. Really all .NET languages are just wrappers of functionality, namely the Win32 API. Really it comes down to the goals or purpose of the two languages. The VB compatiblity classes are there to be used and since they don't require the VB6 runtimes they are not the same as calling those things in VB6. Its all a matter of preference I say. I don't use Left or Right or Len but that is because I prefer then .Length or .SubString versions better. I don't think they they really add an extra layer they are still part of the .NET framework its just the syntax is adjusted to match the VB6 syntax more. VB is all about productivity, making an app as fast as possible thus it has certain shortcuts built in. Of course this is just a trade off. Of course as previously stated its all a matter of opinion so just form your own and stick with it. Also as previously mentioned if you can learn both and you'll be better off.

PS. I think there are some bad habits that VB6 teaches us, or doesn't teach us, or example instancing. One of the big problems VB6 programmers run into with .NET is working with forms and exchanging data between forms. This is because VB6 never taught us about instancing of forms, since we almost always worked with the default shared instance of the form. This is something that regardless of VB.NET or C# you will need to learn and correct in moving to .NET.

[Kasracer]

Originally posted by Edneeis
Really all .NET languages are just wrappers of functionality, namely the Win32 API.

Link? I was told the framework was built from the ground up and didn't use the Win32 API (since Microsoft is replacing the Win32 API anyway, it would be stupid if the framework was a wrapper for it).

[Edneeis]

Who told you that? Link? I've been reading interviews or listening to them lately from the MS brass and I don't think the Win32 API is going anywhere. They are just wrapping it up. Review all the mass of data out there on Longhorn and WinFS that is where my information comes from. The idea with .NET is a better way to expose the underlining OS not necessarily to replace it. In a recent interview, I heard that they have no plans to rewrite the OS from scratch or even some large applications like MS Office. They are just exposing more of it via WinFS and the .NET framework. I believe that was from Richard Green speaking about VBA and the whole Visual Studio for Office Tools bit. http://www.franklins.net/fnetdotnetr...aspx?showid=43

[PT Exorcist]

Originally posted by Edneeis
PS. I think there are some bad habits that VB6 teaches us, or doesn't teach us, or example instancing. One of the big problems VB6 programmers run into with .NET is working with forms and exchanging data between forms. This is because VB6 never taught us about instancing of forms, since we almost always worked with the default shared instance of the form. This is something that regardless of VB.NET or C# you will need to learn and correct in moving to .NET.

Not only that, when i came from VB.NET to C# I didnt know how events really worked(delegates), I had several times problems as I was used from vb6 to use Late Binding and such..

[Navarone]

I don't know anyone here either Still I appreaciate your input. I am really quite new to programming. So I don't think I have any bad habbits as yet, unless of course they have been passed on to me from other VB user on this forum site.

For about 4 years now I have worked mostly with Action Script and Lingo (Flash and Director) and this last year VB6. Most of my apps are graphic intense, with back ground images, mouse roll-overs, etc... How well does VB.Net or C# handle graphics?

[PT Exorcist]

Depends in what you mean with that. C#/VB.NET can't do flash GUIs(at least in easy way) but they sure have lots of functions for drawing

[Navarone]

Ok, thats a good point. Let me clarify. Currently in VB6 I can play a Shockwave file using the ShockwaveCntrl . Does VB.Net/C# have such a control or capability?

And as far as mouse-overs, I am referring to a command button or equal in C#/VB.net where the image switches from a "off" state to an "on"state when you mouse over and out. In VB6 I have a HoverCommand Cntrl, does this capability exist in either programming language?

[jwmoore2001]

Not sure if it does, but you can reference COM objects just as well in VB.NET.

right click "project" click "Add Reference" click the "COM" tab. Find the object and click "select"

now you can instantiate that object in your form. Any COM objects hosted on your machine will be in that tab.

[jwmoore2001]

Not only that, when i came from VB.NET to C# I didnt know how events really worked(delegates), I had several times problems as I was used from vb6 to use Late Binding and such..

Delegates are not events, you declare an event as a delegate to be able to access that event by its memory address. You do this so you can access the event if the object is running in a seperate thread.

Just a clarification.

[Edneeis]

Events use delegates to work though. I prefer VB's event model with the Event keyword over C#'s delegate use but ultimately behind the scenes it is done the C# way.

You can actually work directly with the Event Delegate in VB by using the [NameOfEvent]Event protected delegate from within that scope.

You can also declare an event with a delegate:
Public Event Handled As EventHandler

[jwmoore2001]

Really all .NET languages are just wrappers of functionality, namely the Win32 API.

Ok the .NET Framework is not WIN32 API. The .NET Framework runs with a Common Language Runtime(CLR) with Just In Time Compiling(JIT). This means that .NET is managed code because debugging, error checking, etc is not managed by the ASSEMBLY that is created when you build your code, its managed by the CLR.
WIN32 apps are managed internally by themselves making WIN32 API un-managed code. The .NET FRMWK uses ILASM to build an Assembly file that when run is compiled by the CLR to its final stage.

[Edneeis]

Originally posted by jwmoore2001
Ok the .NET Framework is not WIN32 API. The .NET Framework runs with a Common Language Runtime(CLR) with Just In Time Compiling(JIT). This means that .NET is managed code because debugging, error checking, etc is not managed by the ASSEMBLY that is created when you build your code, its managed by the CLR.
WIN32 apps are managed internally by themselves making WIN32 API un-managed code. The .NET FRMWK uses ILASM to build an Assembly file that when run is compiled by the CLR to its final stage.

Ok I didn't say it WAS the Win32 API I said it USES the Win32 API, hence the use of the word wrapper.

[jwmoore2001]

Events use delegates to work though. I prefer VB's event model with the Event keyword over C#'s delegate use but ultimately behind the scenes it is done the C# way.

Huh? Delegate is a keyword used in an object's method declaration. Delegate is not associated with Event. You can use declare a sub or function as Delegate and call that Sub/Function's address from anywhere in code. The Delegate keyword replaces the CallBack keyword in earlier versions of VB.

[Edneeis]

A delegate is an object which provides a form of type safe function pointer. An event is a delegate or derived type.

Public Class something
    Public Event Handled As EventHandler
 
    Public Sub test()
        Me.HandledEvent.BeginInvoke(Nothing, Nothing, Nothing, Nothing)
    End Sub
 
End Class

I'm not sure I'm explaining it properly but you can read 'Events and Delegates' in the VS help for more info.

[Edneeis]

I could be wrong (its happened before it'll happen again) on the .NET framework just using the Win32 API behind the scenes but that is my present understanding of it. If it didnt then it would seem like it would be a non-issue to use on non MS Operating systems. I'd imagine that Mono is just s runtime to translate the CLR IL code to the Linux API instead of Win32.

[jwmoore2001]

A Delegate is a TYPE used to invoke one or more methods where the actual method is determined at run-time. This not only provides a safe way for derived object to subscribe to events provided by their base class but they also provide a way for programs to respond to asynchronous procedures(or seperate threads)

Simply put delegates provide a way to invoke methods by their address rather than by name.

Delegate Function MathDelegate(ByVal X as integer) as boolean
 
Function DoCalc(ByVal Func as MathDelegate, ByVal X as integer) as string
If Func.Invoke(X) then
  return " Is "
Else
 return " Is Not "
End If
End Sub
 
Function IsEven(ByVal X as integer) as boolean
If x Mod 2 then
  Return False
Else
  Return True
End If
End Function
Function 
 
Sub CheckEven(ByVal X as integer)
MsgBox("The number " & X & DoCalc(AddressOf IsEven, X) & " even.")
End Sub

[jwmoore2001]

I could be wrong (its happened before it'll happen again) on the .NET framework just using the Win32 API behind the scenes but that is my present understanding of it. If it didnt then it would seem like it would be a non-issue to use on non MS Operating systems. I'd imagine that Mono is just s runtime to translate the CLR IL code to the Linux API instead of Win32.

Yeah I am not exactly sure either their is no reference to that in any documentation I know of. The Win32 Structure and Framework is too large to include in the .NET framework and then redistribute and you are right, if that was so it could be deployed to a linux machine.

As far as the delegates thing. I am referencing a study guide by microsoft for MCSD (getting ready to take an exam) and thats how they explain it. I would guess you would be right to say that events use addresses because when you raise an event, you need to subsribe that event to a procedure in code with a handler. So it must be memory call either way you look at it. But visually you dont have to call an event by its address the CLR does that by itself. If you want to call an event in a seperate thread you must use the delegate.

[PT Exorcist]

I dont get why all this discussion, it seems clear to me that everyone here knows what a delegate is and that internally we all need to subscribe our events to delegates

That's the point why I said that, I didn't need to explain in DETAIL because I just wanted to show a face of an advantage of C# -- whenever you want it or not you'll eventually have to learn delegates to use events

[jwmoore2001]

That was sort of my point is that you dont have to declare an event as a delegate procedure.

[Highlight=VB]
Public Event DoEvent()
[/vbocde]

That right there can be handled in your application. The delegation sub allows you to use addhandler to dis-associate your events along with other things already mentioned.

[Edneeis]

I like delegates because they stay crunchy, even in milk.

[jwmoore2001]

I found that you where right though Ed about having to use delegates for events in C# because in C# you have to use the addhandler to subscribe to events which inturn forces you to make the event as a delegate sub.

[TheManWhoCan]

This came from somewhere in Microsoft, although I can't remember who exactly:

The .NET Framework is a collection of classes which provide a managed representation of some of the functionality of the Win32 API. What's actually gone on in the writing of those classes, is that the fundamental classes for each namespace are written in unmanaged C++ and are full not of API calls but of the code behind them. So the base classes perform the API functions but it's all inline rather than explicitly called. Once the fundamental base objects for a given namespace have been programmed in unmanaged code, the rest of the namespace is coded in C# because that's ultimately what it was designed to do.

I think that's accurate but don't hold me to it.

On the VB.NET versus C# debate, they are effectively equivalent in all but grammar. I favour the C# way: everything is explicit and unambiguous. It's a bit less Mickey Mouse if you get my drift.