I read something about PowerWrap which is supposed to allow you to static-link a vb6 .exe to it's dependent files (.OCX, etc.)
However, the website for the product appears to be just a squatter.
Anyone know anything more about the product or something similar that's still being supported?
I discovered another solution called UMM (Universal Make My Manifest). You give it a list of files and some options, and out comes a manifest ready-to-go. I've been using it for a half-million line VB project with dozens of ActiveX modules, and it works well. Requires tlbinf32.dll.
Related
This question might seem to be duplicated with this and this that are similar. But it is not! First- I am getting this error from the setup file and not from the program that I am distributing Second -the version is different, the directories in Installshield 2009 an 10.5 differ. .
I'm trying to fix an error caused by Windows compatibility mode in my setup, which is built with Installshield 10.5. So far my research led me to a conclusion that i need to add [this][3] to my manifest file. I saw that Microsoft's tool mt.exe could extract a manifest file from a dll, however I did not see anywhere that it can extract it from an executable file.
So my questions are the following:
Is there any way to view the manifest file of a Setup.exe built with Installshield?
Is there any way to configure this manifest file for the certain project in Installshield?
[3]Can one edit an InstallShield setup.exe's manifest file?
As far as I know, mt.exe will work fine on EXE files; both EXE and DLL files are Portable Executable (PE) files, and PE files use the exact same structure for resources such as the manifest. Visual Studio, CFF explorer, and countless other tools (including raw resource APIs) will also work to view and possibly update manifests in general.
However for a built InstallShield setup.exe, there is a twist. InstallShield uses areas in the file to store information that are not described in the PE format. Tools that update the resources on an EXE can inadvertently destroy this data as they do not expect it to be there, nor do they know how to detect or adjust it.
InstallShield 12 or so and later allow you to specify a manifest, and it selects the manifest from files it ships that you can update before it adds them to the setup.exe. In addition, there is a tool called ISReMan that is aware of the extra information and can update the manifest correctly when that data is present.
By the way, it's generally helpful to mention the actual problem you're trying to solve, in case the method you've chosen (in this case updating the manifest) is not the correct solution. Note as well that InstallShield 10.5 is over 10 years old, and knows nothing about UAC, PCA, and other Vista and later technologies; adjusting the manifest may not help fix, say, an elevation-related problem.
Note as well that I am paid to work on InstallShield, so I may be biased when I recommend things like upgrading. :)
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 have an existing MFC product and am planning on supporting a couple of other national languages thru the use of resource-only DLLs. I've read a number of articles and tutorials on how to go about this, but admit that I don't have a lot of in-depth knowledge of Windows resources (mostly just use VS 2008's graphical interface).
The major area that I am trying to understand is that it seems like all of the resource source files (i.e., resource.rc) for these DLLs -- and the main program -- should be sharing the same copy of resource.h. After all, all those IDD_xxx values have to be consistent, and it seems like making updates to the resources would be even more complicated by having to keep multiple resource.h files in sync!
So am I correct on this, and does anyone have any tips for how to best implement this? Should I modify resource.rc in the DLL projects to point to the "master" resource.h in the main program directory?
Yes, use the same resource.h file for sure.
One way is to just copy the resources you need to be translated into the the new resource project--stuff like menus, strings, dialogs. Bitmaps and icons probably don't need to be translated unless you put some text on them that is language specific. If you know your localse, at program startup you can call AfxSetResourceHandle() with the resource DLL you manually load.
Another way to approach the problem if you have a multitude of DLLs and EXEs is to use binary resource editing tools. What they do is create token files from your resources. Your translators edit the token file with the binary editing tool. When all is done, you run a tool to apply the translation to the binaries. Basically, you don't distribute resource DLLs, but distribute different versions of your DLLs for each language. The tools are smart enough so that if you make a change like add a string or dialog, it will get picked up and your translator can see that he needs to translate something new. The previously translated work will be saved in the token files. This is how we do it at my shop. We used to use Microsoft's Localization Resource toolkit. I don't know if we still use it or not since it is somebody else's responsibility now.
I found the MSDN article ID 198846 a good starting point for sharing of resources via a dll, though it does need updating for newer versions of visual studio, it was quite easy to follow and understand.
http://support.microsoft.com/kb/198846
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/
Maybe that's silly, but I'm confused again when trying to find appropriate names for my projects.
I have a solution with two projects. First project is a library, which will be used by other libraries in the future, for creating plugins for my app. Second project is a exe, which uses first project to create GUI and do some stuff, eg. load plugins.
In similar situation, when one project is a dll and second is an exe, how do you choose names for each project?
Lets say, that I would like to peek a name GraphDemonstration. The exe should be GraphDemonstrationGUI and dll - GraphDemonstration? But exe is not just a GUI. So maybe GraphDemonstration for exe and GraphDemonstrationLib for dll?
I have had similar situation in the past. Maybe there is some kind of naming convention? I don't even know if my "problem" is related to VS only.
GraphDemonstration for your EXE is fine because it describes the purpose of the EXE. However, you said the library will be used by other projects later so the "GraphDemonstration" part of GraphDemonstrationLibrary may not be the best choice. Perhaps GraphLibrary, or GraphHelper, or maybe more specific depending on what is actually included in the library. For example, if the library handles instantiating an Excel object to generate a graph you could call it ExcelGraphHelper.dll.
If this is library of main class CSomeClass I name project SomeClassLibrary.
For projects smillary but non from main object.