I'm working on some legacy VB5/VB6 code and need to convert a ".bas" file to vb.net.
I found several options
Compile the .bas file into a com dll and then reference and use it in my project. (For this I guess I would need vb5 or vb6 which I don't have at my disposal)
Copy and paste the contents of the file in to a new module in vb.net and then try solving the errors one by one.
The contents of the .bas file reference a particular dll.
The .bas file has mostly declarations consts, types, sub's and functions.
What would be the most elegant way of redoing this in vb.net. Is it as simple as option 2.
EDIT
I used VS2008 express and ran the code through the upgrade wizard it did the necessary conversion. and the .bas file was converted to .vb. I took that file and decided to rewrite other parts of the code, including some redoing of the converted .vb file.
Other questions related to this one are here.
Consider rewriting as an alternative. In my experience, this makes less work in the long run than either relying on an opaque COM library or using the VB6 migration wizard and picking up the pieces it spits out.
Depending on your knowledge of .NET, the rewrite of a single VB6 module shouldn’t take very long. If you are freshly starting with .NET then this may take longer but it will also provide good opportunities to learn .NET.
Microsoft provide guidance on what to do including an app that attempts to convert VB6 code to .NET
This includes both your solutions except 2 is helped by the converter.
It depends on how complex the VB6 code and what it does.
However if you are going to have to support and change the VB6 code it would probably be worth doing the conversion now.
There are a lot of advantages to converting to vb.net -- compatibility with future (and possibly current) systems and maintainability being the most important. The main advantage to leaving it as a dll would be to save development time, but this could backfire if there are future compatibility problems.
If the code is in a VB6 project now, or if it can be added to one, you can open the .vbp project file with vb.net and it will it asks if you would like to automatically convert it to vb.net. It does a pretty good job, exclusive of third party add-ons.
Related
I have just reversed a crackme in OllyDbg, and I was wondering if I can modify its code with application written in VB.NET. For example, to change JNZ (on specified address) for JMP.
EDIT:
I see there is a misconception. I was talking about creating patcher in Visual Basic.NET(programmatically change EXE code) to patch already reversed application. I know about Write/ReadProcessMemory that allows me to inject code after application execution(in that case it's loader not patcher), but how to overwrite EXE permanently?
Changing JNZ to JMP is kind of bypassing some kind of verification inside application (serial number of if it is purchased or not, so if you have the source code, you can just comment which lines you don't want your application to execute
Patching a compiled program is possible with certain tools, you can even do that in runtime with code injection.
But, as i understand from your question, you're talking about a vb .NET application and not a regular VB application.
VB .NET applications compiles to bytecode (MSIL code) and not binary like regular VB applications, which makes it even more easier to reverse, you can actually "decompile" the .exe file to it's source code with a tool like ILSPY (see google), patch it, and then re-compiled it.
My question might sound stupid but please bear with me :-)
I have an excel file, was doing some manual task, converted them to VBA code in order to automate. Works well.
I then decided why not distribute this. So, I went about searching for ways to protect the VBA code and found none. The most probable way was to convert it to DLL and call the DLL using "Tools-> add references->mytoolsDLL" inside excel. As the DLL code is not seen it does offer some protection. So, I looked up how to convert my VBA to DLL. Solution found "Visual Studio-> Class Library Project"! SO converted almost all VBA to DLL using Class Library Project, compiled, registered my DLL, used it inside Excel, all good, works well.
Now, this DLL I have compiled I dont know if it is classified as "COM add-in" or ".NET" DLL! Today I realised that it was very easy to "de-compile" a .NET DLL. I tried looking at "code" difference between a COM ADDIN and .NET there is almost none. When coding this "DLL", I was using google and MSDN a lot but they all referenced it as "VB"
If I am converting VBA to something, should it be "COM ADD-IN" or ".NET"? I read about VSTO today and was wondering how does VSTO come inbetween Visual Studio and COM ADDIN/.NET? What techniques can I use to ensure that the DLL when distributed can be license controlled? i.e. after first "install" the DLL cannot be copied to other machines? Is it possible to do license management/control via VSTO?
p.s: If you think I am mixing up terms/terminologies please feel free to correct me
Why not just right click your project once you are in the developer environment, select VBAProject Properties, select Protection Tab and set a password to protect your vba project ?
Is one able to compile VB 6 code in Visual Studio.NET ? In other words, is it backwards compatible with older VB code?
Since I know there is a difference between managed code (.NET) and unmanaged code, I am wondering if Visual Studio.NET is able to compile unmanaged code as well?
Kind regards,
Kris
While you cannot compile vb6 in the .net Visual Studios, you may use interop libraries to allow vb.6 to utilize managed code
http://msdn.microsoft.com/en-us/library/kew41ycz%28VS.71%29.aspx
No, you can't compile VB6 code in any VS.NET version.
You can open a VB6 .vbp project file in Visual Studio. This automatically invokes the project converter, it will try to translate your VB6 code into VB.NET. The translator does a fairly decent job of it but the VB.NET language has changed pretty drastically. It depends on how 'clean' your VB6 code was.
After the conversion is completed, you'll have to walk through the list of warnings and errors you'll get. Getting none at all is rare. There might be hundreds or thousands. If you're in that boat, it starts making sense to rewrite the code.
Anyhoo, just try and see what hits the fan. You'll have a good idea what you're in for in about ten minutes. Don't forget to copy the project before you start the conversion.
No it is not compatible. I think there is an upgrade wizard, but you will end up fixing some stuff manually.
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.
I want to create an ActiveX DLL from Visual Basic 6 from which I would like to call some public functions. I will call this DLL only from VB6. However, it seems that only classes get exported. Is there any workaround?
I know there is a way to create DLLs from VB6 with standard WINAPI functions. This is not what I want, because I would have to type thousands of Declare instructions, and I would lose the dynamic linking so I don't need to recompile applications when changing the DLL.
I will state my problem just in case anyone has a better idea. I've got a bunch of relatively big projects, each with its own code, and then I have a lot of "Generic" code which is used in several projects. It's an annoyance to add every file to each new project, and having to recompile all of them for each minor change. So I thought of creating a DLL, so I would just "Add reference" when I begin a new project, and don't have to worry anymore about recompiling (at least for minor changes) but I raged when discovered that only classes got exported.
I wouldn't mind to reorganize the code in classes, but it's an overwhelming task: there are some 10 years of 3-4 people code, so it's not something I can do overnight.
Yes, it's easy.
Put all the utility routines in special classes in the DLL.
Set the Instancing property of those classes as GlobalMultiUse.
Build the DLL.
In your client project (with a reference to the DLL) you will now be able to call the functions and subroutines as if they were in a module in that project. You won't need to create any objects.
You can read more in the VB6 manual.