I've been thinkin about moving to VB.net
from VB6. My number one concern is the
.net frame work. is this required to have
another user run my program? And what
about Ture 32 bit DLL's, not those activeX
dlls. Would switching be a good idea?
Printable View
I've been thinkin about moving to VB.net
from VB6. My number one concern is the
.net frame work. is this required to have
another user run my program? And what
about Ture 32 bit DLL's, not those activeX
dlls. Would switching be a good idea?
The .NET framework is a very intelligent programming structure. I really could not go back to VB6 after working with the .NET Framework.
Yes. The user must have the .NET Framework and version you are developing with. This is pretty standard with Windows now and most everyone should have it installed by now.
.NET is run under managed code, meaning the the .NET code is stored into an assembly file(MSIL). When the application is run it is compiled to its final state by the Common Language Runtime (CLR). The code is managed because the Type-Safety, memory management and other run-time tasks are handled by the CLR not by the application's executable as did in traditional Windows applications.
Also, lets look at this from a developer standpoint, and where you want to be in 5 years. MS is redeveloping most/all of the applications in windows besides the basic kernal into .Net apps. If they are moving in that direction, where should you be heading if you are a Windows developer? My thought would be with .Net.
You can do EVERYTHING you did with vb6 in .Net. You may have to struggle a bit to find out how, but it can be done.
You can use dll's, but .Net will make a wrapper class for it in order for you to access it like a .net assembly.
So, basically, The VB runtime DLL's are no
longer needed? What about execution?
is it faster? How about compiled code is it
more or less in size than vb6?
The VB runtime DLL's are no longer needed, but the .Net framework has to be installed on the users machine in order to use a .Net created app.Quote:
Originally posted by NeptuneCentury
So, basically, The VB runtime DLL's are no
longer needed? What about execution?
is it faster? How about compiled code is it
more or less in size than vb6?
Execution is subjective. I hear people complain that their apps are not as fast as vb6 was. I can't really give you a firm answer. I have found that my apps, run about the same speed as vb6 apps. There is ONE noticable difference, and that is the first time the application is ran. You see, .Net doesn't compile down to native code, it is a Intermediate language that is compiled the first time it is ran. So, the first time it is ran, it runs slower than normal, but after that, it runs just fine.
The .Net framework is so robust, you would have a hard time giving it up once you use it for awhile.
I agree. Not only that but once you get used to the differences in Visual Studio .Net you will never want to go back to Version 6 or earlier either.Quote:
The .Net framework is so robust, you would have a hard time giving it up once you use it for awhile.
The VS.Net IDE is an awesome piece of work from Microsoft. I can not think of one thing to complain about it.
If you are on a budget, as I was, you may want to consider purchasing the VB.Net Standard Version (roughly $100). It lacks some of the advanced features that the Pro version contains but you can still get (I believe) most things done in code that the higher end versions do automatically.
I could be wrong about that so you may want to ask around but I have found that most of the limitations that MS put on the standard version like not being able to connect to full SQL Server using a wizard can be overcome by connecting manually.
If you have any questions specific to the standard version's features just post back to this thread and I will try and answer them for you.
One note: If you plan on doing any reporting with Crytal Reports you are going to need the higher end version of Visual Studio or have the developers version of Crystal Reports.
Pros:
-Quick development cycle
-Easy database access
Conds:
-Need framework to run the programs
-Faster than VB6 but it's still slow in IO functions (according to benchmarks i've seen, C#'s IO is ALOT faster. I don't understand why (shouldn't it be the same?) but I've even tried it and there was a noticable difference)
-The IDE has some wierd bugs in it (sometimes the tabs refuse to stay in one order, working on a network if you lose the connection for a second you get a ton of errors thrown at you and NOTHING works correctly until you restart the project).
I've never seen the stdnard version for $100, where is this? The academic is usually around $100 or a little less.Quote:
Originally posted by BukHix
If you are on a budget, as I was, you may want to consider purchasing the VB.Net Standard Version (roughly $100). It lacks some of the advanced features that the Pro version contains but you can still get (I believe) most things done in code that the higher end versions do automatically.
From Amazon.com: Microsoft Visual Basic .NET Standard 2003
How easy is it to convert VB6 apps?
And what to you mean by IO functions
being slow? do you mean files, graphics?
As far as converting VB6 apps, you should really just re-write them in .Net if that is what you want to do. There are different ways to do things now, that to truly take advantage of the cool stuff, it takes a rewrite. If the VB6 app works, why upgrade it? If you need to do a lot of bug fixes, and you need to go ahead and rewrite it, then move it to vb.net.
Those are only my opinions.
As far as the File IO, I haven't really had any problems yet. I don't do much file IO, mostly database stuff. I will tell you that it isn't THAT much of a difference for most people. And if you really NEEDED that extra performance, you could write a C# dll to do that, and integrate it into your vb.net app easily.
IO is... well.. IO.. Input/Output. Writing files, deleting files, reading files, ect..Quote:
Originally posted by NeptuneCentury
How easy is it to convert VB6 apps?
And what to you mean by IO functions
being slow? do you mean files, graphics?
IO doesn't really have much to do with graphics except when reading or writing them, though VB isn't the fastest for graphics either (like games and such). Simple games will be fine though, just don't expect to write the next Doom3 or Half Life in VB.
In my very simple program I read in a list of directories and then the files inside of the directories and threw them into a ListBox. With VB the program would actually pause for a second. In C# it was just instant. Same exact code was used too (except for the obvious syntax differences).Quote:
Originally posted by hellswraith
As far as the File IO, I haven't really had any problems yet. I don't do much file IO, mostly database stuff. I will tell you that it isn't THAT much of a difference for most people. And if you really NEEDED that extra performance, you could write a C# dll to do that, and integrate it into your vb.net app easily.
I really don't know why and I've even seen benchmarks putting VB really far behind C# in IO. I would have thought that if they both used the same framework it would take the same amount of time.
That is very interesting, I would like to get both versions of the code from you sometime so I can see this in action.
I have heard of these differences, but I have never verified them myself. I have always liked C# more, but I use VB.Net at work right now. If I could actually prove performance reasons to choose C# maybe I could get us to switch over (which is what I would perfer).
I don't have the code for the VB version anymore (I have since deleted it) but I got my class which was redone in C#. When I ported from VB to C# I basically copied and pasted and then made the syntax changes.
This was the class that, in VB.NET actually paused my application but in C# it doesn't:
It isn't very complex or anything.Code:public class PopulateLists
{
public void List1(ref System.Windows.Forms.ListBox lbo, string add)
{
try
{
lbo.Items.Clear();
lbo.Items.AddRange(System.IO.Directory.GetDirectories(add));
}
catch (System.Exception ex)
{
System.Windows.Forms.MessageBox.Show(ex.StackTrace.ToString());
}
}
public void List2(string dir,ref System.Windows.Forms.ListBox lbo)
{
try
{
lbo.Items.Clear();
lbo.Items.AddRange(System.IO.Directory.GetFiles(dir));
}
catch (System.Exception ex)
{
System.Windows.Forms.MessageBox.Show(ex.StackTrace.ToString());
}
}
public void FormatList(ref System.Windows.Forms.ListBox lbo, int temp)
{
try
{
for(int i = 0; i < lbo.Items.Count; i++)
{
lbo.Items[i] = FormatString(Convert.ToString(lbo.Items[i]));
if (temp == 2)
{
lbo.Items[i] = FormatStringExt(Convert.ToString(lbo.Items[i]));
}
}
}
catch (System.Exception ex)
{
System.Windows.Forms.MessageBox.Show(ex.StackTrace.ToString());
}
}
public void FormatList(ref System.Windows.Forms.ListBox lbo, int temp, ref string EXTType)
{
try
{
EXTType = ReturnExt(Convert.ToString(lbo.Items[0]));
for(int i = 0; i < lbo.Items.Count; i++)
{
lbo.Items[i] = FormatString(Convert.ToString(lbo.Items[i]));
if (temp == 2)
{
lbo.Items[i] = FormatStringExt(Convert.ToString(lbo.Items[i]));
}
}
}
catch (System.Exception ex)
{
System.Windows.Forms.MessageBox.Show(ex.StackTrace.ToString());
}
}
private static string FormatString(string str)
{
int intStart = str.LastIndexOf("\\");
return str.Substring(intStart + 1);
}
private static string FormatStringExt(string str)
{
int intStart = str.LastIndexOf(".");
return str.Substring(0, intStart);
}
private static string ReturnExt(string str)
{
int intStart = str.LastIndexOf(".");
return str.Substring(intStart);
}
}
That is in a DLL (that isn't the only thing in the DLL, but this is what slowed things down). The program that used this class was made in VB.NET and so the was DLL. When I changed the DLL to C# it made a noticable difference and I didn't even change my code in my project.
C# was built from the ground up to work with the .NET framework (Most of the .NET framework was written in C#). VB.NET was'nt, because of obvious backwards compatiblity. Most of the IL is not even the same in identical code for VB.NET and C#.
I agree, but for the code he is doing, it is calling framework classes, which are the exact same framework classes that VB calls. Why the difference?Quote:
Originally posted by DevGrp
C# was built from the ground up to work with the .NET framework (Most of the .NET framework was written in C#). VB.NET was'nt, because of obvious backwards compatiblity. Most of the IL is not even the same in identical code for VB.NET and C#.
I dont believe that c# is faster with IO then vb.net
If they are used in a similar way, they should be exactly the same (or near as damiit). The overhead is the IO subsystem, not the code.
Ive found vb.net to be about 10 times quicker then VB6 if you use the .net functions, especially in string handling. Ive found a little slower using controls tho.
Also, Ive recently found out, that running windows 2003 with SQL 2003 and .net 2003 programs can run up to 50% faster.
Read this if you ever have the time ;)
http://support.microsoft.com/?kbid=308470
Then you believe wrong because I have seen it for my own eyes. Google for benchmarks on IO functions in C#.NET and VB.NET. Most benchmarks I've seen, VB.NET is usually about 10 times slower than C# in IO.Quote:
Originally posted by Grimfort
I dont believe that c# is faster with IO then vb.net
I agree with your thinking in that it should be the same or damn near close, but it just isn't.
Ive looked and cant find any decent examples.
I still dont believe it :), have you got any links ?
Here is what Microsoft has to say about the differences:
http://support.microsoft.com/?kbid=308470
For this particular test I used your class and this vb version of it:
VB Code:
Tested on my My Documents folder and got these results in milliseconds:
C# .0100156
VB .0400616
After the initial run both the C# and VB apps ran instantly or 0 milliseconds. So C# was x4 faster than VB here BUT we are still just talking about milliseconds and only on the first run.
I will attach the same projects I used.
Previous tests where done from the IDE (not that it should matter) but now I moved the exes to the same folder and ran them on the "C:\". Now I'm getting different results, strange. Of five tests here are the results:
C#
.0100151
.0100151
.0100151
.0100151
.0100151
VB
.0100151
.0100151
.0200302
.0100151
.0200302
After each test I could exit the application and restart it to perform the test again. That is very odd. Now VB shows equal performance or no worse than x2 the duration.
Either way this is nothing too significant and would never be noticable by the end user. I don't think I'd pick my language on a few milliseconds increase in speed on IO functions. The languages are comparable and it should be an individual decision which to use.
PS: Is it me or is the Intellisense not as good in C#?
Edneeis, was the class implimented in the exe itself or in a DLL? I had that class in a DLL and then used a VB application to access and use it. Perhaps IO is slower coming from a managed DLL? When I had it made in VB the application's speed in which it performed functions was actually noticable than compared to C#.
No I was lazy and just stuck it all in an exe. I'll have to try it using a dll.
Ok using a C# exe and C# dll as well as a VB exe and VB dll here are the results:
vb
.0200320
.0200296
.0200290
.0200294
.0200294
c#
.0100148
.0100145
.0100145
.0100145
.0100147
Then I switched and mixed different exes with different dlls.
vb exe, c# dll
.0100150
.0100150
.0100157
.0100157
.0100156
c# exe, vb dll
.0100150
.0200300
.0200300
.0100157
.0100156
I didn't time the UI responsiviness but the C# UI did seem a tiny bit faster (bringing up the folder browser and form). I still prefer the VB syntax so I'm staying put.
Wow, nice work Edneeis.
VB has extra data checking options for projects for numbers. Im not sure if C# has these options, but removing may increase the speed a bit. But as you have show theres little to no difference in them. I much much prefer vb syntax, its sooo much easier to see the layout IMO, the names are more meaningful as well. So VB for me as well. They should rename it as Visual Not-So-Basic.
2x slower is actually a major downfall. If you talk in terms of heavy IO Calls.
Yes x2 is bad but if they are both are still under .1 milliseconds then there isn't much point to it. I mean If one car can reach 300 miles an hour in 6 seconds, and another in 3 that is quite a difference, but if you never drive past 60 then you'll never notice the difference. We don't know if in other things VB has the edge. Also if you develop faster in VB than the time and money you could save on development is well worth the .01 millisecond extra it takes in some IO functions.
Exactly. But like you said if I built an application that did some heavy IO operations, then C# might be the way to go especially in an enterprise environment where customers rely heavily on speed.
Not a big deal. Now that you did those test I will keep that in mind when the time comes to develop an application that rely's on heavy io operations. Thanks.
You know I downloaded and read that white paper a while back it was really helpful. I did just read in this book I have from Microsoft Press that relates to:
COM usage in .NET - States that COM let properties that you where able to assign in VB 6 are not readable in C# but they are in VB.NET.
To me that is a big downside. Because I use & develop COM components all the time. So I would have to modify those components for use in C#.
I would like to point out that the .NET Framework does integrate nicely with COM. The architecture for building COM readable components in .NET is nice.
The fact that you can mix and match VB and C#, and that once you learn the framework classes, using C# in parts in simple as pie.
There's no reason to lean toward one or the other. I use both in our apps.. only because some controls are written in C#, and we have to modify them for particular uses in our VB apps.
Edneesis, was your code run with Integer Array Bounds Checking for the VB test?
Do you mean the 'Remove integer overflow checks' optimization? If so then no that was unchecked in both the dll and the exe for all tests.
Perhaps that could be part of the discrepancy, since the code above uses a few integers on the drill down.Quote:
Originally posted by Edneeis
Do you mean the 'Remove integer overflow checks' optimization? If so then no that was unchecked in both the dll and the exe for all tests.
Actually I just tried it with those enabled and it actually ran slower. Wierd huh?
So the test with the optimizations disabled ran faster?
Then obviously this code isn't a good test for benchmarking. There's too much discrepancy. Virtual disk paging by the OS probably is skewing the results.
That is correct.Quote:
Originally posted by nemaroller
So the test with the optimizations disabled ran faster?