What reasons are there to migrate from vb.net specific language to .net framework language?
Examples:
VB.net
ubound
msgBox
.Net Framework
array.getUpperBound(0)
messageBox
Those functions exist to mirror the built-ins in VB6, to make porting code easier.
The functions in the Microsoft.VisualBasic namespace are often then wrappers around the .Net functions, with some additional checks before calling the function, so there's a minor performance hit using them vs. the native ones.
backward compatibility
VB.Net is a ".net framework language". The examples you showed for .Net work just fine in VB. So, in that sense you would not be migrating from anything. As to why you should prefer the newer .net idioms over the older vb-specific idioms, there are many reasons:
The newer code is more portable
It uses more modern programming concepts, and therefore subtly encourages better habits
The newer code is sometimes faster
The newer code has more features. For example, you can set more styles on the new MessageBox than you can the old MsgBox.
Sometimes neither is the best choice. For example, if you're using arrays much at all in .Net 2.0 and later you're doing something wrong. IEnumerable(Of T) and the various generic collection types are much to be preferred.
Related
I am working on migration of VB6 Application to VB.net.
the VB6 code uses ChrB quite often and I need to know how to convert it into vb.net
has anyone faced any similar issue..?
Regards,
Rasheed
VB.NET doesn’t support “byte-oriented” string methods.
VB Migration Partner provides the ChrB6 replacement method, which approximates the original VB6 method’s behavior but isn’t guaranteed to work well in all circumstances. This replacement method is marked as obsolete and methods invocations are flagged with a migration warning.
Someone asked me today if it was possible to port a visual basic application to Linux or similar platform, I assumed it was .NET so I suggested to use Mono, but noticed that on their vb support page they only talk about vb 8 (.NET)
Does mono support non-.NET vb? In fact I'm not sure what he is using, I think vb6, I'm not sure of the versioning at all though.
No, VB6 is an entirely different beast from VB.NET. Mono is basically there to run (via JITting, interpreting or AOT-compiling) IL - the Intermediate Language that VB.NET and C# compile down to. (Of course it also provides the libraries and compilers.)
Running VB6 requires an entirely different execution environment, basically.
No, but you could take a look at gambas
Gambas is a free development
environment based on a Basic
interpreter with object extensions, a
bit like Visual Basic™
I own a copy of vb2005 professional.
I need to migrate a vb6 project to vb.net
Is there any difference in terms of effort to migrating to these
editions of vb.net
thanks
I think it's slightly easier to target the later versions. I believe the PowerPack 3.0 was added for Visual Studio 2005: it included extra support for emulating the VB6 Printer object and shape controls.
Anyone who's read my other answers about VB6 migration should stop reading now because I've said this before... but I think it's relevant, so I'll say it again anyway.
Check out the Microsoft UK advice with a screencast explaining the 5 basic options for .Net migration. Decide which is best. People may advise you to just rewrite from scratch in .Net. Be cautious about this - you say your codebase is big, which is a danger sign for rewriting. Microsoft UK say
Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.
I'm rewriting a lot of VB6 currently and what I've found so far is that the previous developers had to use a lot of third party and custom modules to implement what they need when a lot of it has been included in the base class library for .Net since then.
From what I've seen there's no easy way to migrate from one to another. A lot of effort goes into these migrations. The best thing to consider is whether you want to try to go line by line or examine the code, document core functionality, evaluate how well the software has worked over it's lifetime and then engineer a new design.
That's what I've ended up doing because a line for line rewrite is nearly impossible and a large pain. Compiling libraries and modules into COM to bring the functionality into .Net applications is a lot of effort and kind of a "McGyver" approach. That's why I just documented everything well, understood the process, then wrote as .Net software.
Specifically, what functionality are you trying to maintain? Have you written in .Net before?
In my experience the "migrate" is really a rewrite so it doesn't make any difference what version of Visual Studio you use. I'd use the latest.
We are in the process of creating active-x controls used within our application.
Since Microsoft stopped supporting classic Visual Basic, is it wise to use Visual Basic to develop the Active X control or the latest VC++/ATL/MFC libraries provide more feature where we can create controls faster by leaving Visual Basic flexibility?
We will not be able to use .NET/VB.NET/C# since the application is supposed to work inside containers and containers may not support latest .NET runtime.
Any other language is best fit for Active X control development other than VB and VC++?
I, personally, would recommend using Delphi for this. It is still actively developed, and has the control you get with C++, but a rapid development environment more like VB.NET.
#nobugz: If you are really interested what is ActiveX in Delphi, look at docwiki. Normally it is 100% source code (yours + VCL, VCL is also available as sources) with autogenerated COM wrappers. So all potential security problems are also in source code. If you find a security problem in VCL, please send a bug report to Quality Central.
Here is a good example on how to create ActiveX Controls with C# .NET
http://www.codeproject.com/KB/cs/CreateActiveXDotNet.aspx
By all means VB6 is the best language. After reading your question I feel that you are a VB6 developer. If you know VB6 and use it then why hesitate using it for producing ActiveX controls.
I program in Delphi as well as VB6 along with VB.NET and C# but creating ActiveX controls is the easiest in VB6 compares to all other development tools.
If you are hell bent on not using VB and if you are looking for an alternative then try out PowerBasic (commercial - very costly) or PureBasic (commercial but affordable) Get it from here or better still MinGW (a GNU C++ compiler).
I have to say that VB6 with a good book like Developing COM/ActiveX Components with VB6: A Guide to the Perplexed you will be up and running faster.
In Ironpython site exists references to a language called VBx using DLR. But i can't find any reference to this in google. Where is it?
Edit: Is a Implement of Visual Basic 6.0 in DLR? if yes is so cool. Is more expected for people using VB6 yet and can't migrate because big frameworks.
From this mailing list post:
VBx was an implementation of Visual Basic on the DLR. It was first meant
to be in Silverlight, but the VB team decided they'd rather put VB.NET in
Silverlight rather than build a new implementation up from scratch. So, VBx
is on hold.
Apparently it's an implementation of VB in the DLR:
http://www.mail-archive.com/users#lists.ironpython.com/msg05933.html
Straight from the mouth of Paul Vick (long time VB architect)
What is VBx?
VBx was one of the four language implementations that were originally driving the design of the DLR, the other three being IronPython (from which the DLR was extracted in the first place), IronRuby and Managed JavaScript.
VBx was intended to be a dynamic version of Visual Basic.NET or a .NET version of Visual Basic 6, whichever way you want to look at it. It was primarily intended as a testbed for the flexibility of the DLR, secondarily as a testbed for a more dynamic version of VB.NET and tertiarily (is that a word?) as a scripting language for Silverlight. It has fulfilled its primary goal and the designers of VB.NET decided that they want to pursue goals two and three within the existing VB.NET language, rather than producing yet another slightly different incompatible version of VB. (You already have VB.NET, VB, VBA and VBScript.)
Managed JavaScript was also abandoned, the team was folded into the IE team and is responsible for the ECMAScript 5 engine in IE 9.