I have a VB6 project, when I came to check in changes to the VB6 project file I noticed that the Visual Studio 6 IDE had automatically inserted the following line:
VersionCompatible32="1"
What does this mean?
As an aside: Is there a good resource to help me make sense of the VBP file?
The VersionCompatible32 value in the VBP file seems to be part of the binary compatibility settings of an ActiveX project, maybe the typelib it needs to be compatible with (there can be several in a library).
When my project is set to no, or just project compatibility, this value is removed.
Note that the compatibility setting itself is stored in the CompatibleMode value.
First of all, I don't think it is a good idea to edit the VBP file manually. As far as I know, VersionCompatible32 is a hint about the VB(A) version that was used to save this file, probably for newer versions to recognize changes in the file format.
Related
Let's say you update your project to a new OCX reference. As a result the GUID and other details of that OCX will change in the project's VBP file. So far so good.
However VB6 also writes the same information to FRM files (and maybe others, like user controls). But these files are NOT updated until they themselves are specifically / manually saved. This can lead to confusion when it appears that references are inconsistent.
There are other sorts of automatic changes VB6 makes to files also, but seemingly only when you touch the file manually.
It would be very handy if there were a way to force VB6 to resave every file and make sure it is totally up to date - say, on the build machine. Then you'd know for certain what the most up to date clean copy was as a point of comparison.
I don't know of a command-line option that can do this... but maybe someone knows a trick.
There's an add-on created by Martin Liss in this thread:
SaveAll.DLL
I didn't try it myself but it could do what you are looking for. I assume you tried Save Project?
I have this old VB6 project that is composed of a few DLLs, OCXs, and GUIs.
There is a GUI component that includes this in it's VBP file:
Type=Exe
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#C:\Windows\SysWOW64\stdole2.tlb#OLE Automation
Object={EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0; ieframe.dll
Object={3050F1C5-98B5-11CF-BB82-00AA00BDCE0B}#4.0#0; mshtml.tlb
Reference=*\G{64E54C86-D847-48F7-9AE5-D6C9B8E6A3A2}#3.0#0#..\..\bin\Crypt.dll#Crypt
Reference=*\G{B3E7F95C-B6D9-458E-B4D4-5272759B139A}#4.0#0#..\..\bin\SpeechMike.dll#SpeechMike_DLL
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; MSCOMCTL.OCX
Object={AB4F6C60-4898-11D2-9692-204C4F4F5020}#29.0#0; Ccrpsld.ocx
Object={48E59290-9880-11CF-9754-00AA00C00908}#1.0#0; msinet.ocx
Object={9C526969-AA6E-4D61-BAFA-117FD20C2B38}#3.0#0; SpeechMike.ocx
The Reference settings are a pain since they always change from one machine to the other. I mean, the GUID '9C526969-AA6E-4D61-BAFA-117FD20C2B38', for the last one as an example, will be something on my system, but something else on somebody else's machine.
For now, to make it work, I erase References to Crypt.dll and SpeechMike.dll. Also Object SpeechMike.ocx. Otherwise, Visual studio looks for something that does not exists. Then in "project > references" I check both Crypt and SpeechMike and the Reference goes back to the VBP with the proper GUID and version. Finally, in 'project > components' I add the OCX and I'm good to go.
Am I wrong about that? How can I share the project with some else without going through hoops and loops to start the project?
I'm using MS Visual Basic 6 (part of VS 6 enterprise).
This sounds like "failure to maintain binary compatibility." Normally you only do this to yourself, but of course it can be a bigger headache if multiple people are compiling your libraries from the source Project files.
When you create ActiveX EXEs, DLLs and OCXs you need to create a "base" version where type and class ID values (GUIDs) get assigned. The documentation even suggests that you do this leaving the procedures empty: just a comment line or something so the IDE does not remove the empty declarations.
You don't have to use an "empty" base reference library, it can be one with full code in it.
Once you have compiled this baseline library, you'd exit and save your Project. Then rename this "empty" library as something else and from there keep it along with your Project source files.
After this you re-open the Project and go into Project Properties and on the Component tab change the Compatibility setting to Binary Compatibility and in the box there enter the full path and name of your compiled baseline library. Save the Project. Now you can add code and compile the "real" library to be used by other programs.
When you distribute these libraries (DLLs, OCXs) to somebody else in source code form so that they can compile them you must provide this renamed compiled baseline library along with the source code files, VBP file, resource files, etc.
From there your GUIDs will be stable until you make a change to something that breaks binary compatibility (changing a method's argument list, etc.).
There is more detail on this in the online Help (MSDN Library). See:
Using Visual Basic|Component Tools Guide|Creating ActiveX Components|Debugging, Testing, and Deploying Components|Version Compatibility in ActiveX Components
I'm looking for general advice. I created a Visual Studio 2010 project that outputs an ocx file that is used on XP and Vista machines. The DLL on which it depends has been updated on our Win7 machines. I simply needed to rebuild for Win7 using the exact same code with an updated .lib file. I created a second project configuration (ReleaseW7) and it only differs from the original project config (Release) in that it points to the new .lib.
So now I have 2 files both named xx.ocx. Besides looking at the name of the folder each file resides in (or looking at the creation time of each) there is no way to determine which is which. I thought of using different file version numbers but as far as I can tell (and I'm relatively new to this so I could certainly be wrong) that would require two separate projects each with a slightly modified resource (.rc) file, instead of simply having two configurations within the same project. If nothing more, that seems like a waste of hard drive space. It also feels like the "wrong" way of using file version numbers
Is there a cleaner or more "standard" way of handling this? All I really want is a way for the folks who install the ocx and support the end user to know for certain that they are working with the correct file.
Long story short, I decided to use different version numbers. I was able to setup a preprocessor definition for the resource compiler and use that to handle different versions of VS_VERSION_INFO in my .rc file.
In case anyone is interested, this is the resource I found:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/605275c0-3001-45d2-b6c1-652326ca5340/
I have to maintain a number of minor legacy apps and most of them have no or minimal documentation. There are a couple of these which were written either in VB5 or 6, but I can't tell which. There doesn't seem to be big difference in the appearance of the source code, and I can load either one using VB6, and even run them in the IDE, but I have the feeling that the older of the two is VB5. Is there a way to tell by code inspection which one a project was created in? Or some other way.
The .VBP file for a VB6 project will contain a line like this:
Retained=0
VB5 project files do not contain this line. You can load VB6 project files in VB5, but you get a warning about the invalid "Retained" key.
It's in the project file.
Also, if you have had both installed, when you OPEN the project file from Explorer, it should start the "VB Selector" tool that will figure out which version to open for that project.
I would like to change the output file name based on certain criteria that I'm checking with #defines. A little background, I'm doing this because I've decided to use VS2010 in one of my projects to regain intellisense. However, this is causing some other problems with Google Test, and the rest of my team is on VS2008. So, I would like to build a GTEST_VS2010.lib if I'm on VS2010, and GTEST.lib otherwise. I was hoping I could trick the compiler with #pragma comment(linker...
but that doesn't seem to be allowed by MS. Thanks for any help.
VS2010 converts project and solution files, doesn't it? Then you don't have a problem since you can't use the project file with VS2008 anyway. Just change the linker's Output File setting.
Otherwise, you probably should just consider adding another configuration to your solution.