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.
Related
so my question is relatively simple, can I create VB6 application that references a class in a dll, and then substitute that dll for another at runtime?
Now my intial guess is... no chance in VB6.
So my thoughts turned to a VB.net interop dll. Could I do it in here, and then call the interop dll from the VB?
Again, my guess would be no.... but I'd be happy if someone knew differently.
The only thing that I think would actually work would be DI in .Net, but I'm limited to .net 2, or 3.5 at a big push, so I dont know if that is possible.
So for the background....
I have a dll that a specific site uses, but we dont want to ship that out to everyone. Instead, we want to build a clone dll which just has the interfaces setup so that the VB6 build will complete.
When it gets to the site that needs it, they want to replace the dummy dll, and drop in their version instead.
Note: We do use RegFreeCOM when its gets installed, so I do have the manifest files that I could play around with if needed.
Any ideas would be much appreciated.
Nick
Its a COM dll so its not statically linked to the VB6 exe, so long as the clsids and interface ids are the same in the type library for both DLLs, you can swap them around as you see fit. (If its a VB6 dll this is trivial to do with the 'binary compatibility' build option)
You could also use late binding instead and instead of making a reference directly in your VB6 code, you would create an object and then set that object to an instance.
Examples and information:
MVPS
Microsoft
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.
How do you reference DLLs from Objective-C? I use GNUStep Make files on Windows.
RIch
Ooh... this takes me back. A bit of a guess from the most common problem I ever ran into.
If GNUStep's DLLs on Windows work like they did a decade ago, then you:
Link to the DLL like you would any other DLL. I don't remember the explicit syntax, but there should be about a zillion examples available
Make sure you have a static reference to a symbol in each DLL from the main program (or from some other DLL).
In particular, when compiling something that is pure Objective-C, it is quite easy to end up in a situation where the Windows link loader doesn't load a DLL because it doesn't see a hard reference to any symbol in that DLL. When I ran into this with WebObjects applications, I would typically export something like:
int businessLogicDLLVersion;
And then refer to that symbol quite specifically in my main program. That static reference was enough to cause the link loader to load the DLL and the runtime to hook up all the classes.
I recently ran across a DLL installed on my system that Dependancy Walker (and every other utility I tried) says has zero exports by name or ordinal, yet the file is approximately 4mb in size. I thought the sole purpose of a DLL was to export functions for use by other code so what would be the purpose of a dll with no visible exports?
One way to think of a DLL is as a container for functions. Exporting a function from a DLL makes those functions visible to callers outside of the DLL. While exporting functions from a DLL is perhaps the most common way to provide access to them, many platforms provide other ways to access functions which have not been exported such as reflection in the .NET Framework and Java and (I think) LoadLibtary / GetProcAddress in Win32
Reasons for doing this are varied, often it is because it is beneficial to the developer to have functions in a library but undesirable for those functions to be called from external applications
Resource-only DLL, maybe? Those are used quite often for localization purposes, for example.
EDIT: it's also possible to have a DLL with code that does something in DllMain() to somehow make its functionality available. The DLL can register itself with some global dispatcher, for example, or create named kernel objects...
I have an application that uses many different .NET managed DLL's as objects (each DLL implements a common interface). Each DLL also has a version number in the file name.
Suppose I create the object "Shape~01.dll." The application will use that DLL but it can't be replaced while the application is running. So, if I want to "upgrade" the shape dll I have to create "Shape~02.dll" and the application has to dynamically search for and load the newest dll everytime a shape is created and/or the user has to restart the application. It get's worse, each dll depends on the main .exe thus has to be rebuilt with the main .exe.
Is there an easier method to have dynamically "replaceable" objects?
Well, this isn't the best solution (still thinking about it), but you can unload dll files which will allow them to be replaced. That might be a quick stopgap solution until you come up with a better idea.
You don't mention which language/platform you are trying to accomplish this in, so I will answer for the .NET Framework.
If you want to do it the hard way look at Shadow Assemblies, this is the method that ASP.NET uses to keep the site updateable though it is using the files.
For a much easier method look at the new System.Addin namespace, this uses Shadow Assemblies under the hood and should do what you want.
Instead of polling when creating an object, why not just request notification from the system when the file system changes?
The class is System.IO.FileSystemWatcher in.NET.
For native code there are a few ways to watch a folder, but IANAND (I am not a native developer ;).
Although having said those things, you probably want to rethink the reason you need to change your objects so frequently, because it will probably take a lot of work to make it work.
You used the dynamic tag, so maybe you should try a dynamic language? :)