Can a Portable Class Library be referenced from a VBA context such as Excel? I tried adding a reference to the DLL but it fails with "Can't add a reference to the specified file."
I have written a normal class library before (with its build settings set to expose to COM) that references a PCL and then provides wrapper methods. This is tedious and complicated, is there a better solution that would expose the PCL as-is?
Related
I'm reading msdn pages introducing DLLs in C++, in both Regular DLLs Statically Linked to MFC and Regular DLLs Dynamically Linked to MFC, it says:
Regular DLLs must have a CWinApp-derived class and a single object of
that application class, as does an MFC application. However, the
CWinApp object of the DLL does not have a main message pump, as does
the CWinApp object of an application.
Is this true?
I'm actually using XLW (an open source application that wraps the Excel C API in simple C++ interfaces ) to build XLL plug-ins for Excel.
Howcome I couldn't find any CWinApp in either the codes generated by XLW or the XLW source code?
ps: Notes on XLW -- basically, if you write a library consists of mylib.h and mylib.cpp, XLW will parse mylib.h and generate xlwmylib.cpp; compile and link all three files together, will generate a mylib.xll, that can be imported by Excel as an add-in; then Excel can call functions defined in mylib.h as normal Excel function, either in formular or in VBA.
Whilst I am doing VB6 development, I think that this is a wider issue. I have found that sometimes in the VB IDE we get an error: [BadImplementsRefInCompatLib]. Using the Type Library Viewer that comes with "Advanced Visual Basic 6" by Matt Curland, it flags up that the type library in my component has a reference to a type library it can't find, but not what it is. The underlying error is with the TLI component when it tries to find out about an interface that is defined in another type library.
I also tried OLE View - to try and reverse compile the IDL - but again, it gave an error message when trying to get the external type, without identifying the erroneous value.
I traced the actual error back to the type library reference in the registry which was point to a component, but the major version was incorrect. Replacing the major version fixed the issue.
I used a binary editor to see if I could spot what information is being used in the type library. And indeed, I found the names (no paths) of the components which it references, but I couldn't work out the format. I was actually hoping to find a table of type library GUIDs and version numbers. I suppose I could write code to extract these names, and eliminate the "working" references, but this is a bit crude.
Does anyone know how a type library references external types?
[BadImplementsRefInCompatLib] means that your binary compatible target's typelib has a reference to an external typelib and this external typelib is not registered.
For instance if you have a project group with several ActiveX DLLs that are set to binary compatible version compatibility and Project2 references Project1 (uses types from Project1 on functions/properties prototypes of a public class) when Project1 breaks compatibility and gets recompiled Project2's compatibility target has a typelib that references external typelib that is not registered (namely the old version of Project1 component).
In our shop we do have references across VB6 projects but never ever use types from core on public methods/properties of classes. Such parameters are declared As Object and down-cast in code which is less trouble than tying components with external cross references. Curland's EditTLB is used regularly to spot offending classes.
No idea how a type library references external types. I just importlib("component.tlb") in idl and use types from component at will.
Btw, a very simple way to "protect" a COM component (DLL/OCX) from being used in VB6 IDE is to reference a struct in external custom made typelib (param to a public method) and then "forget" to ship this external typelib. VB6 IDE chokes with "Error loading DLL" on adding a reference to the DLL/OCX but the component works and registers perfectly, provided you don't try to call this "obfuscated" method cross threads (in-process or not).
I have multiple native C++ projects, one of them is a dll project, and I want to test it.
The problem is that the generated .lib file only contains the definitions for the public interface of the dll, but I would like to test the projects internals.
Since referencing the project does not work (it only works for static libraries) is there a way to add the the generated objs directly in my testing project ?
Also I know that I could include all the source code files in the referenced project. But is there a way to do this considering that the referenced project might change. I would like a method that does not force me to mange each file manually.
I have done some research and I found some answers like in this question:
Reusing object files in Visual Studio 2005
but since I have many small classes exposing all the classes is a bit to tedious.
I found that I can set a Pre Link Event in the Build Event menu.
This allows me to use the following command:
lib -out:"../Debug/tempAllDllObjects.lib" "../MyDLLProject/Debug/*.obj"
now, even if my project is a DLL project I have an additional .lib file that contains all the objects in my project. All I have to do is reference the newly created lib file. This way I can link with all the objects in my DLL project even if they are not in the public interface.
As a note the command can also be set on the DLL project as a Postbuild Event this will increase the efficiency since now the lib file is only generated when changes occur.
How can I share source code between 2 projects in MS Visual Studio 2008 (I'm programming in C++)?
In my case, I have the code for the main game project and now I want to make a simple model editor that uses the game's code, so that whenever I change/add some code in one project it will be updated in the second one.
A common method for doing this, (you'll see it everywhere in open-source packages), is to bundle all the headers into an 'include' folder and all the source into a 'source' folder.
Now in whatever project needs the code, you go to, 'Project Properties->c/c++->General->Additional Include Directories'. Then add the path to the 'include' directory. Finally, add the source/headers to your project, now both projects reference the exact same files, which are in a nice tidy shared location.
You can also build the shared code as a static library or better yet (IMO) a DLL. This involves creating a new project, and learning a little bit about the linker in VS 2008, but really nothing too complicated. This also has the advantage (in the case of a DLL) that the two projects don't re-compile the same code, but rather it is compiled once and used twice.
You can move the required classes into a separate library project and then references this from the second project. Any changes will be automatically picked up.
(I'm not a C++ developer, however the above works for C# projects, I would assume it works for C++ projects too)
You basically have two options:
Create a static library. In this, all the code in the library will be exported and visible to who ever links to this library.
Create a DLL: here, you can define what classes and methods you would like to export and use those.
Lets say you have a class called classA which is defined in classA.h and implemented in classA.cpp and you want to use this same class from two different applications (application B and application C).
Using method 1, you would create a static library by going to file->new win32 project and in the box that pops up, choose application settings and make it a "Static Library". Then in this static library you add both your classA.h and classA.cpp.
To use this static library in application B or C, goto the references and add a reference to the static library project that you just created. then include classA.h in your application (don't forget to set the additional include directories path) and you are good to go.
The approach is very similar for a DLL as well, the difference here would be that you can choose what parts of your code in the DLL are exported (ie visible to outside callers).
From an overall point of view:
With the static library approach, your code will be compiled into both the applications.
With the DLL approach, there will be just one copy of the shared code (in the DLL which will be a separate file) and this will be loaded as required.
When creating a DLL with Visual C++ 2008 I have a couple of choices. I can create a "Class Library", which I understand will actually give me a .Net Library that uses the CLI (managed) extenstion of C++.
Since I don't want that, and I assumed that I need a static .LIB file to link into another Visual C++ windows executable project, I choose instead "Win32 Project" and, on the Application Settings panel, specify a C++ (no MFC) DLL.
This will create a project with a .cpp file which is supposed to be where I define "the exported functions for the DLL application".
This doesn't seem to be what I want either. Basically, what I'm looking for is the native C++ equivalent of what would, in C# .NET be a class library assembly. I want to package some classes into a DLL, then have a .EXE project use the DLL's classes by including the DLL project header files and link with a .LIB to resolve references.
What's the usual way of doing this?
You're doing it right. What you'll need is to mark your classes with __declspec(dllexport) to make them available from outside the project. When you build the project, you'll generate both a .DLL and a .LIB.
Create a new Project
Visual C++ : Win32 : Win32 Project
Application Settings select DLL and check 'Export Symbols"
When you generate the project, it will stub out an exported class for you, typically named C{MyLib}.
You are right to make a C++ (no MFC) DLL. You can create your classes and those entry points which you define will be exported from that DLL for use by other C++ code (for example, a Win32 application written in C++).
Since C++ names get mangled automatically by the compiler to weird and wonderful values, it's not practical to export them as is if the DLL's clients are, for example, C programs. But if everything is in C++, you should be OK.
If you create some classes, you can choose to have them linked dynamically (as a DLL) but you will need an import library (created for you automatically) which contains the DLL's symbol definitions. You can also choose to link statically to your code from an application - in this case you would end up with a static library (also a .LIB) which contains the actual object code in your classes rather than symbols in a DLL.
The advantage of a DLL is, of course, that if you write several applications using your library, they can all share the DLL; with a static library, they would each contain a copy of your library code.
I think this article describes what you are trying to do:
http://www.codeproject.com/KB/mcpp/usingcppdll.aspx
Personally I also prefer exporting C functions (as opposed to C++) where I make the this pointer explicit to avoid having to care about compiler specific method name decoration and exposing compiler generated functions.