Which one would you prefer to extract a sub-string from the given string and why?
I am thinking that since Left and Right are VB functions and not .NET functions, they may cause problems in the future in terms of compatibility.
Please clarify my thoughts on that.
Use whichever makes most sense i.e. makes that piece of code easier to read.
I don't know why you'd think that they'd cause problems in the future, they're functions, they're provided as part of the VB.Net Language set, there is no earthly reason why they would be removed, and even if they were, they would be trivial to re-implement.
Use 'em, cause you ain't gonna lose 'em
When given the choice between a feature that is from Microsoft.VisualBasic vs a comparable feature that is provided in the core framework assembiles, I tend to stick with the latter in most cases.
I do this for various reasons:
It tends to be understood by more developers. (e.g. C# guy looking at my VB.NET code).
You're more likely to find online help (message boards, stackoverflow, etc) for the core framework version than you are for the VB-ized version.
Using them gives your code a "legacy" feeling to it. It's like making use of the Call statement.
Makes it easier for another person to "copy and paste" VB.Net code into their C# (or other .NET language) project and have it be one less language translation point/hangup. (Unlikely this is a real concern/reason, but I know I've many-a-time "copy and pasted" example C# code into my VB.Net project and anything that doesn't cause road blocks in the translation process (e.g. usage of yield) makes my life easier.)
While completely inconceivable they are going away (as most of these keywords/statements are a BASIC language construct), they do feel more likely to become marked obsolete than any of their core framework counterparts. Especially as VB6 is becoming more and more of a distant memory and the VB.NET language takes on a life of its own in conjunction with the core .NET framework advancing.
One notable exception to this, I tend to make use of the My namespace proxies offered; My.FileSystem.ReadAllText(...) is just sexy. :P
Do you work alone?
If no, the decision is simple.
If your team members have C# background, use Substring.
If your devs have some VB6 background, use Left and Right.
If you ain't sure, ask them.
.net SubString will throw if start + length is > than the string length where VB Left() will return the entire string if a length greater than the string length is provided. That's a substantial behavioral difference.
Also, given .Net Standard, avoid Microsoft.VisualBasic.
Yes, I know this is > 10 years old, but ended up here when trying to port some really old code. So, thought I'd share the difference.
Related
I am developing a VB6 legacy application. I have started writing all new code in VB.NET essentially creating what I am calling an interoperability layer. I could approach this in two ways:
Write all new code in VB.NET using this interoperability layer and use a phased approach to upgrading.
Continue writing VB6 code and then convert it all at a later date (use a big bang approach). I do not have time to convert the entire application at the moment.
My question is, which is the better approach?
UPDATE
The reason I favour option 1 is because there is an ASP.NET application. The previous developer would effectively duplicate code in both apps i.e. VB6 and ASP.NET. Therefore some of the code in the ASP.NET app can be shared with VB6 and vice versa. That is why I believe option 1 is better, but I cannot find any literature to suggest that developers actually do this
In a previous life I was involved in the same type of project. The original application was written with Access as it's framework. Then came VB6 which seemed to work nicely and allowed for more features without having to alter much of what was written originally in Access.
Along came .Net ...
...as much as I disliked the developmental staging to .Net and being forced to work with an interoperability layer it was necessary.
That said, I will answer the question as subjectively as possible:
If you know that the application is to be converted fully to .Net, then do as much of your new development with .Net as you can. There is no reason I can think of to put it off other than the perceptions (and truths) about interoperability - e.g. more overhead, performance, etc.
sidebar - at least you don't have interoperability issues with Access ...when it crashes, it brings down everything. It was my first experience with interop (with Access) and it wasn't pretty.
Advantages to waiting on .Net development:
shorter time to deliverable (no interoperability layer)
more stable app (no interoperability layer)
Disadvantages to waiting on .Net development:
Long (and likely unprofitable) release cycle while the entire app is re-written
Lots of new bugs introduced
Learning to write unit tests when that will be the last thing on your mind
Beginning .Net development now will increase your chances of success in the long run. I don't believe an interop layer is going to cause you the headaches it did for me - and any degradation in performance should be minimal.
I don't know if you are involved with a team of developers on this project, but if you are, make sure everyone is on board with the move to .Net. I've seen a few VB6 developers strike a dear in the headlights pose over VB.Net. The nature is to continue writing in the same style they're used to.
Concentrate on giving the users what they want.
If it's easier to accomplish this in vb6, then do that.
Worry about converting to vb.net when it's necessary to convert to vb.net.
The tools to convert vb6 to .net are now pretty
good, are under constant development and so can be expected to improve further.
I personally would use your first option(since you already have your interoperability layer implemented), that way it will make the rewrite when you do it less painfull.. if you design you class structures correctly. The second option would be my preferred way to go but since you are under time constraints, use the first. Eventually the VB6 runtimes are not going to be part of newer versions of Windows, see this SO question. I myself have a VB6 application that is going to need to converted.
I've used Teleflex, developerfusion, and SharpDeveloper, and all these, to convert C# to VB, but as most know, there are always errors, and modules left out, and such.
Does anybody know of a good VB editor, preferably freeware, and can handle translated VB and offer suggestions to correct it for you?
Visual Studio underlines things and offers suggestions on some things, but other things it just underlines and leaves you to the guesswork, which doesn't help a non-coder like me.
Non-coders shouldn't be translating C# to VB.
No code translator will take care of everything for you. Even if it works programmatically, there are design patterns and code standards that are different for each language. Hire a programer.
No. And it's not always possible to convert C# to VB. Some features of C# have no equivalent in VB.
Unsafe code (e.g. pointers)
Iterators (yield)
Conversely some features of VB have no equivalent in C#.
Exception filters
XML literals
Why do you need to convert the code anyway? What's the business case?
VB and C# are different langages, so even the best translator in the world will miss some things. The person doing the translation shouldn't be a "non-coder" and should know at least some VB, so when a compile error is shown, he knows what to do with it, or at least knows how to search on the web (or ask on SO) to know how such part of code can be translated to VB.
Although vb.net and C# are both designed around the same .net framework, and consequently feature very similar features that work mostly the same way, many corner cases are handled differently by the two languages. While one could argue ad nauseum about whether a statement like myStruct = new myStructType(someParams) should affect the value of myStruct before the constructor completes (in C#, it does not; in vb.net, it does), and it's probably good to avoid designing code around corner cases, it's doubtful that any translator--much less a freeware one--will detect all of the corner cases and ensure that code which (possibly accidentally) relies upon them will still run correctly.
In 2002 I did a pretty large VB6 app for a client. It used a lot of UserControls and a 3rd party menu control (for putting icons next to menu names). It had dynamically "splittable" panels, TreeViews with multi-state checkboxes, etc. A very rich UI. My total time on the project was about 500 hours, which the client graciously let me spread over a whole month. (Yeah, it was that kind of job.) They were very happy, though, and they paid the bill on time with no argument.
So after having no contact with them for years, they suddenly call and wonder if I can update the app to .Net for them. My initial reaction is just to decline, since I don't use VB.Net. And having read a bunch of posts on SO about the difficulties of porting, etc., etc., I'm even more inclined to decline, so to speak.
Still, before I tell them no I am interested in roughly quantifying the effort it would take. I would love to hear from anyone who has done this kind of thing and has a feel for how much work it is. Was it:
Significantly less than the effort you used on the original?
Somewhat less than the effort you used on the original?
The same as the effort you used on the original?
More?
A lot more?
Please only respond if you have actually done this kind of port. And the answer doesn't have to be exact, since I really am only trying to ballpark this. My feeling is that the effort will be at least as much as it took for the original, if not more. But I could be wrong. Thanks for any help.
I have done what you've been asked. In my case it was an (amateur) bowling tournament mgmt system: Member database mgmt (personal info, IRS/Winnings info, mailing lists etc etc etc) , tournament mgmt (player assignments, scoring, lane ticket generation, check register for winnings and side-pots, etc etc etc) as well as IRS EDI generation for all winners in a given year. Plus about a billion little items scattered across ~ 50 screens/sub-screens.
The key is CLIENT UNDERSTANDING -- You must be clear that they understand that this is not trivial; this is a new adventure for BOTH of you (particularly if you are a new-comer to VB.Net) If they liked your work before then they may very well give you the leeway/freedom to learn VB.Net on their nickel.
Reading some of the previous answers let me make a few suggestions (based upon 30 years experience as a software developer, the last 20 of which as a consultant....)
TAKE THEIR MONEY IF THEY OFFER IT. You need to bring your skillset into the 20th century; let them pay for it (again, if they agree.) They may be Magazine surfing and want "the latest stuff" for NO GOOD REASON -- but maybe they realize that they can extend the life of (your) application by this port. In essence they may have all kinds of goofy reasons for doing it... if they are NOT hiring you to DECIDE whether or not this port is a good idea. Then you may express any dismay you have about the decision PROCESS out of good client relationship building; BUT if they want to do this then it might as well be your job.
Take all this mumbo-jumbo re: C# vs VB.Net with a grain of salt. I have worked EXCLUSIVELY in VB.Net / ASPX.net (vs C#) since its inception and have yet to come across ANY functionality NOT attainable in VB.Net. There are some 'purists' out there that just view VB.Net as a toy. Well, I came from the days of writing in Assembler, then C, then C++ (And you can throw in Fortran, PL1 for good measure) then VB5, then 6, then VB.Net ... and NOW JAVA for Android. Its ALL GOOD FUN... and each has it merits and drawbacks. Remember that C# and VB.Net are essentially just GUIs to achieve a meta-language intermediate. You can write a TERRIBLE (as measured by efficiency or memory use or whatever metric you choose!) Program in C# and a great one in VB.Net (and vice-versa.) DO NOT EQUATE GOOD PROGRAMMING WITH LANGUAGE SYNTAX. (... C# is "superior" ???? Gimme a break.)
I chose to allow the Visual Studio do most of the heavy lifting for the first pass. Then you go through the gazzillion errors and clean it up. It goes pretty fast.
BUT you need to decide whether or not to take advantage of any framework benefits that you had hand-coded in VB6. E.G. looping through a string to locate a specific character(s) is now as simple as The_String.IndexOf("c") I found that in my case I went through the code several times and took better and better advantage of the Class (i.e. object orientation) as well as framework goodies as I became comfortable... this adds to your development time (see CLIENT UNDERSTANDING mantra) BUT your code WILL BE MORE Efficient then it ever could have been in VB6. You could simply port to get the errors out and not take ANY advantage necessarily from the framework.
I have not found any issue with 3rd party active-x controls. You can add a reference to FRAMEWORK objects, COM objects, etc. It may even be likely that the control vendor has a .Net (managed code) version... OR there may be suitable alternatives since you wrote the thing in VB6. (See CLIENT UNDERSTANDING mantra)
So if your still reading, then now I will finally tell you that the second attempt at my application in VB.Net CONVERTED/PORTED from VB6 was ~ 1/3 of the original time to get to a working model... and I was learning the framework as well. (If your confident in your skill set, have learned a few languages through the years you will get the gist of VB.Net quickly --- its the SUBTLETIES that take awhile.)
I must caution you that the thing that can REALLY kill you if you do not preach the CLIENT UNDERSTANDING well enough is if they want to make changes WHILE you're porting (and this is VERY LIKELY since they've been using it for awhile... I was very true in my case as well.
There is no hard and fast rule here. It could be that changes will actually HELP YOU get to a better understanding the framework faster OR changes could be a real pain. Only you can determine which flavor they might be. AND if they look to be the PAINFUL type -- you might ask to do the conversion first so that you have reliably reproduced the functionality -- THEN go back and review the code to make changes and take advantage of the framework as necessary. But, as I said, there is NO Hard and Fast rules here -- and don't let the purists tell you differently --- remember they are probably the same guys that said that PASCAL was going to take over the world!
So after having no contact with them for years, they suddenly call and wonder if I can update the app to .Net for them.
You need to ask why they want this done.
It's a Bad Plan(tm) for clients to be making technical decisions on a whim. Before applying any solution, thoroughly understand their needs and their problem. Only after you understand the problem as they do should you make recommendations.
It could be that they're infatuated with a buzzword and want to be using the latest thing, or it could be any of a million other things. The solution to their problem could be something really easy, but if you don't find out what their problem is, you will never know the best way to solve that problem.
I would plan on it taking about 50% of the time and effort it took to create it in the first place.
I have done EXACTLY what you are asking about for a commercial software product that consisted of roughly 500 kloc. We balanced the desire for refactoring with the desire to get something working and released as quickly as possible.
It took nearly the entire team about 1 full year to get it done...for a product that took 4 years to create in the first place. It was a gigantic undertaking..not to be underestimated.
We are doing that exact thing right now, however it's slightly different. Instead of one huge application, there are many smaller ones. However, there are a few bigger ones in the list. What we found out is that it was significantly less work than we originally thought. BUT...the biggest unknowns had to do with third-party controls we had. If you have a lot of those to basically redesign, you will probably be looking at more work.
The one good suggestion I have is to use Visual Studio 2008 for the conversion (not VS 2005). There were far less problems when using the built-in converter in VS 2008 than there was with VS 2005. Not sure why, it just was that way.
So, I can't say that you won't spend 500 hours again, but most likely not. Most of your time should be spent on testing to verify no functionality was lost.
In my opinion,
Visual Basic 6 and Visual Basic .NET are so different that you should forget about their coincidence in their name, and treat this as a migration to .NET =P
I think that you have one big advantage and one disadvantage:
Advantage: you allready know what the application has to do. Probably you´ll have some meetings with your clients, in order to add some modifications or new features, but you have the major part of the requirements very clear. You´ll even have the old working application to see while you, or your team, are coding.
Disadvantage: you´ll have to learn a new language. Saying how much time is going to take, is very subjective. I´ve allways thought that learning a new language is not the problem, the big problem would be if you have to learn to program!. But you do know to program. You´ll know what you want to do, and you´ll have only to search how to do it in the new languaje.
Since you have to learn .NET, If you have to estimate, I think that you should suppose that it will take you at least the same as the previous application, even more.
My advice is too take the chance to learn this new language. And if you are more inclined to decline the project, let me give you another idea... Maybe you could estimate a little module of your application, and tell the client that you´ll try to do that module, to see how much it takes to you. The client should pay this little module, even if you decide not to continue.
You can´t tell the client that you know all the requirements, so they are saving money with you, in some way. And that they should take this little risk (we are talking about a little module), because who better than you to make the project, you know the old application perfectly!
If the client is right with this, you´ll can take the decision with more arguments. And If finally you decide to continue, with this little module done, you can estimate the whole project better than before.
Sorry, my English isn´t very good, and probably I´ve made many gramatical errors.
EDIT grammar mistakes... =P
This is a huge topic.
You should take a look at MS' Free Book - Upgrading Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET.
Were you to rewrite from scratch, rather than simply try and port the previous application, it shouldn't take too long. VB.Net has some features that will make the new application build take shorter. As it seems that you don't know VB.Net already, what will take you the most time is learn how to do things the new way(tm).
I'd go for two months this time.
But seriously, that's probably not far off — or even low — because the client will have some reason for needing the port done. It won't be just a straight port - they'll want some "small little enhancement" that will blow the whole project up.
Additionally, I'd worry a bit about the third party controls. Most of the rest of it should convert okay, but there's sometimes an issue finding a good analog to a 3rd party control in .Net.
I'm also concerned that you don't use vb.net. If you're a c# user and wanted to re-implement that way you'd be fine, but otherwise this is a non-starter. VB.Net is just different enough from vb6 for you to get yourself into trouble.
Aside from all that, I would expect it to be less work this time than last, because you have a very explicit design laid out in front of you that you merely need to follow.
I am new to developing with Visual Basic, but have lots of experience in C#/C/C++/JAVA/Haskell and a few others.
Is there some reason I am maintaining code and finding code examples where the type declaration just seems lazy? I have seen countless Strings, that are only ever used as the String type, declared as an object. Before the object oriented features of VB.NET came in, was this necessary to assure that methods could take in multiple types? Why would anyone do this?
At a guess...laziness and old VB6 habits being carried forward.
In VB6 there was the variant type that could take in various types and it was meant to be used with caution and care. When .Net came out the only conversion for that (besides changing your code a lot) would to have used object as the type.
I would definitely call it a hangover effect or code conversion effect from VB6 if the code appears to need that flexibility as you described for a method to take in multiple types.
However, if you are seeing code for string types that were declared as objects this is far worse than just laziness and a hangover from VB6! It sounds like horribly poor design and a lack of care.
Some VB6 experts, for instance "the Mandelbrot Set", advised using Variants for all variables. You could call it early duck typing?! This was rather controversial - many of us thought it was a recipe for disaster.
But there must be a lot of code like this out there. Before modern conversion tools appeared, upgrading it to VB.NET would be very hard. The Visual Studio upgrade tool simply panics every time it sees a Variant. If you really, really needed to upgrade with limited resources, I suppose changing all variants to Object might be the least-bad option. Obviously the resulting code would be horrible.
You could gradually refactor. When you work on an area of code, you could change the declarations to a more specific type.
I'm considering building a framework for VB.NET, and using the My namespace to plug it into VB seems like a reasonable idea. What is "My" used for?
The purpose of My, as I understand it, is to be an easy shortcut to certain API tasks that are common but hard-to-find or hard-to-use. You probably shouldn't completely subsume your framework under My. (For one thing, C# people using your framework may get grouchy.)
Instead, you should design it as a normal framework. When you're finished, make a list of some common tasks that people might want to use your framework for. See whether any of those could be useful to have under My, especially where there are classes or methods that can be used in a number of ways, but they have one or two really common usages that can be abbreviated with My.
This article shows how to extend My, and it has a section at the end that describes a few design guidelines to follow: Simplify Common Tasks by Customizing the My Namespace
As to your main question, when coding in VB .NET, I use My as often as I can. It reduces a number of operations to one line of code.
I really like the "My" Namespace in VB.NET and I always use it in my WindowsForms applications, because it is very intuitive.
I use primarily these categories:
My.Computer: primarily for file system and network purposes
My.Application: Version number, current directory
My.Resources: Access to resources used by the application residing in resource files in a strongly typed manner.
My.Settings: very handy
I think, if your extensions for My of your framework fit well, then many VB.NET programmers would appreciate them.
I've used My in my VB.NET projects, and I don't feel guilty about it. I am primarily a C# guy, but until I transitioned my company to C#, we were a VB shop. In my mind, the My namespace is a nice piece of syntactic sugar. Just as I'm not embarrassed to use C#'s coalesce operator and other sugar, I'm not embarrassed to use VB's sugar, either. (To an extent; I won't use the classic VB functions that .NET still exposes.)
That said, never put anything in that namespace. It's Microsoft's namespace, and just as you wouldn't put anything under System nor Microsoft, don't put anything under My. It will cause confusion later on -- if not for you, then for others who maintain your code. Create your own namespace for your own code.
We do use it in some code, but hesitantly so. It's true that My often helps make code more readable. For example, the Environment.SpecialFolder enumeration curiously lacks a Temp member, whereas My.Computer.FileSystem.SpecialDirectories has one (Path.GetTempPath() will do as well, but is hardly intuitive compared to other special folders).
But My is only beneficial in such cases because the existing APIs are badly-designed, not because My is inherently better. Like JAGregory, I strongly suggest one avoids extending My — or any other kind of global namespace, variable, etc. — whenever possible. The idea just doesn't fit a clean OOP architecture.
I never use the My namespace (I'm a C# developer), but my VB co-worker doesn't as well. I found the My members not necessary, because in many cases, they're counter-intuitive for me, e.g. in my opinion opening a file has something to do with IO (hence System.IO.File) and not with my computer (My.Computer.FileSystem). They always seem so scattered and bunched together.
It's just some re-roll of functionality that is already available otherwise, from all languages. And I don't like depending on Microsoft.VisualBasic.dll when I'm developing for .NET - I always prefer System.*.
And then, it's always kind of limited. I see VB developers struggle with their app when they can't find something in the My namespace, because they can't imagine that you can use something in the System namespace. That of course is not a problem of the My namespace itself.
I mainly use C# and Boo, but when I do use VB.NET I use My namespace quite often. I dont see any reason to not simplify coding. It still retains its readability.
I've only used it from a user perspective, I've never plugged anything into it. I consider the My namespace to be some highly reliable, platform-provided, global helper mechanisms. Officially sanctioned shortcuts, really. I might be surprised to see external user or third-party code in there.
As such, I'd encourage a vb framework to define its own appropriately-named namespace instead of latching on to the existing My namespace. Such a framework shouldn't have that "global" feel to it.
Never used it so far, although I've never actually looked into it either.
I wouldn't advise putting anything into the My namespace yourself, it's much more clear just to lay it out like you would if it were a non-VB framework.
Love the My! Anything that helps me get the job done faster, and provides code for solutions that I don't have to write, the better!
I use My.Settings and My.Computer often while programming in VB.NET. I particularly enjoy My.Settings as an alternative to using ConfigurationManager.AppSettings when it is appropriate.
I agree with John Rudy about the use of My. It is syntactic sugar that makes life a little more readable.
I don't use it a lot.
I'm considering building a framework for VB.NET, and using the My namespace to plug it into VB seems like a reasonable idea. Is it?
If it fits, by all means, use it. Since you didn't offer any further information about your framework it's hard to say. I wouldn't put general-purpose stuff into the My namespace (such as the My.Computer stuff) because there isn't really any advantage to putting it there. However, application-centered helpers fit in well.