I'm having issues with a few .ocx files in vb6. I have 2 components registered but when I attempted to add both into my project it says that I need to register them. I have tried copying new files into the sysWOW64 folders and still it does not work.
This occasionally happens when there is some corruption and conflict in the registry. One way to fix this is to place the two items in a folder within the project and add them by manually going to the reference and selecting that local copy, it will automatically register it as a new object and often (although not always) will fix the corruption by tagging the new path and it often resolves the issue you are facing. The only problem is that in the future projects, you may need to repeat the process or have access to the items.
The cleaner approach is to find all instances of the files on the system by doing an advanced search and finding ALL COPIES of them on the system, often they are all over the place. Once you have those paths, you need to regsvr32 /u <filepath.filename> each one to clean remove them from the registry and then place them in a common area and then register them from ONE location using regsvr32 <filepath.filename> and now things should work fairly cleanly.
Easiest way to find all instances on your machine (at least for me) is to simple go to your command prompt (if using more recent than XP, then as administrator) and then simply type:
C:
cd\
dir /s <filename.ext> > c:\files.txt
and wait until its done, at that point you open that file and it should give you all the paths to the files you need and you can easily turn the text file into a batch file by adding the commands you need to unreg and run it, voila, quick and fairly painless. If at anytime you unreg and it whines about it not being registered or can't do it, don't worry, just acknowledge and move on. Some OCX and DLL don't have registration entry points. If you register and it complains saying it can't do it, then you pretty much have no choice but to it the way I mentioned at the very beginning, by direct linking in your reference and having it drop into your project.
Final note, unless they are 64 bit compatible, you don't need and often shouldn't put them in the WOW system folder but rather system and system32 folders depending on version control and binary control of the original OCX.
Related
I have a fairly large application (~750k LOC) that I distribute using the Package and Deployment Wizard. I fully understand that it would be nice to migrate to .NET (that ain't happening - see the code size above), and that the PDW is deeply flawed. However, for the most part I've made it work well for my end users, by customizing the Setup1 application, writing a menu-driven wrapper for the Setup application, and by running it in silent mode. (Note that the problem I'm about to describe occurred even before I started using silent mode.)
The issue I'm having is that my application requires quite a few auxiliary files, which I've added to the PDW project in the "Included files" section. When a user does a clean installation (either from scratch, or after un-installing a previous installation), everything works fine. However, if they simply run the installer to update the existing installation, the executable file and any OCXs I've updated get copied over the previous versions just fine, but my auxiliary files don't - I have to have the user manually delete them, and then the Setup1 program will re-install them as it should.
I've checked in the Setup.lst file, and all of the files are listed there, with their current date stamps. In fact, in my "BuildAll.bat" file, I do the Windows equivalent of a "touch" (copy /b "TheFile.dat" +,,) to force the date stamp to be current. However, if the file exists on the target machine, it won't be over-written even though it's older. There are no errors reported, either visibly or in the .LOG file (which is required if using the silent option).
A couple of additional points: Some of the auxiliary files are themselves VB6 applications - just the .exe files. Those do get copied correctly if they're newer than the existing files. Other than being files with internal versioning information, there's no difference between them and the other auxiliary files (which are things like media files, or text-based .txt or .dat files).
So, what's going on, and how do I fix it (besides moving to Inno or some other solution that won't work for me...)? Thanks in advance for any help!
~~
Mark Moulding
I am wanting to setup a project and potentially an existing project to be SVN version controlled. I am using uberSVN for the svn server. I have installed AnkhSVN for visual studio.
Currently, the team I am working with is using visual source safe and one of the problems we have is when someone adds a reference to a DLL, it modifies the project file as you would expect, but our paths are different between different team members (XP boxes, 7, you get the idea). What I was wanting is making the project file ignored when checking in/out so that we don't mess up the references for everyone else.
Is there a way I can make SVN ignore these files within the plugin? One of the side effects of this is a person would not know if a new file has been added in the project as this modifies the project file. Other than telling everyone "hey, you need to manually add this file to your project," is there a cleaner way of doing it?
If you copy the DLL to a folder inside your VS solution folder before linking to it, I think the project link will be relative not absolute. So you can check the DLL and the updated VS project into your configuration management and everyone should be able to share it.
You should start using virtual paths for development work; that way each team member can keep work-related files at any physical location but the virtual path (the one seen by tools is always the same.
For example, my team does all work under Q:\. My physical source for work is under physical path C:\Work\<project_name> where the project_name part depends on the project. When I want to work on a given project, I map the Q:\ virtual path to the right physical path using
subst q: c:\work\project_name
When I need to switch, I run a similar command. This way there's no need to worry about different paths on different computers. This worked very well for the whole team and eliminated most issues you describe above. The only thing you need to make sure is that everyone always uses the virtual path (Q:), not the physical path when dealing with project-related files. For my team it took about a week to get used to that, after that there were no more problems.
Your project file is an important part of your project so ignoring it in the source control tool will eventually lead to problems. I recommend you don't do it (even if you can).
Edit:
If you have DLL-s in different physical folders on different machines, the best choice is to copy those DLL-s (and their dependencies) to a known location. It's fine that they can't run from there, as long as the compiler finds them.
This known location could be inside your virtual path or a common physical path (if the same DLL-s are needed for multiple projects). You can use Dependency Walker to determine what dependencies you need for native DLL-s and Reflector for .NET DLL-s.
If the size/number of DLL-s is so large that creating a copy is not an option, you can actually tell AnkhSVN to ignore certain versioned files when committing changes. Right-click the file, select Subversion > Move to Change List > ignore-on-commit. After this the file will show up in the commit dialog unselected but you can still commit it if you manually select it.
We're finally getting around to moving our software's documents out of the program's own directory and into "My Documents". We're also adding a "requestedPrivileges" line to the manifest to prevent further trouble with virtualization.
However if we only did that then anyone who had been running the old versions in Vista/7 is likely to lose their work somewhere within the hidden VirtualStore directory after updating. So what's the preferred way of migrating into the 21st century?
Frankly I'm a little wary of copying files around, especially as I can't seem to find a programmatic way of getting at the shadow directory, but presumably plenty of other people must have had the same problem before us.
Don't add requestedPrivileges unless you legitimately need administrative rights in order for your program to work - nothing in your description suggests that you do. That should also let you simply copy the files on the first boot as if they were still in your program directory, because any virtualization would still be in effect.
However, if you absolutely must do the migration without UAC enabled, you can find your files in %LOCALAPPDATA%\VirtualStore\path\to\file. For example, if your file would have been stored in C:\Program Files\OurApp\, you'll find it in %LOCALAPPDATA%\VirtualStore\Program Files\OurApp\.
To get the path to %LOCALAPPDATA%, you can use SHGetSpecialFolderPath with CSIDL_LOCAL_APPDATA as the CSIDL parameter.
I am developing a package using Installshield 2008 Primer Edition and Project type is Installscript MSI project.
The problem I am facing is during installation I am installing some of the files to the following location C:\Program Files\Company\SystemFiles from this location I am copying and adding the set of files into System32 folder, it contains DLLs and OCX files, copying into the System32 folder has been done using Installscript.
Due to this during uninstallation, the installed file is getting removed from System32 due to this other dependent application which requires the same set of DLLs have stopped working.
I have approached Installscript to copy files from ProgramFiles to System32 Folder rather than using built-in options because we have an issue during the upgrade in order to avoid that I am using Installscript.
Even I have tried several workarounds like setting the file attributes after file copies to System32 using Installscript like FILE_ATTR_SYSTEM which sets the system attribute but still files are getting removed during uninstallation.
Any idea how to give file attributes as PERMANENT or SHARED; will this help, and if it will, then how can I set it using Installscript?
I have 2 ideas
1)I think you can use SHARED option as this wont remove the files while uninstallation.
2)Also when i was facing similar issue , what i did was putting all the required files in the installation directory itself so that while uninstalling only the installed files will be removed.(I know this is not a best solution)
(NOTE:I have worked on Install shield some 6 years back and so remember only certain things)
You can also disable logging from Install Script. This will make the installer "forget" that it installed specific files groups or features.
You should make sure to enable logging once again after you have copied the files that you want to permanently leave on the system.
If you don't remember to enable logging after you have disabled it, your uninstall process may not work correctly.
Syntax is as follows:
Disable(LOGGING);
//Add code to copy your permanent files here
Enable(LOGGING);
For InstallScript projects:
To prevent the files in a particular Component from being removed during uninstall:
1-Select the Components view from within the Organization folder.
2-Select the component that contains the files you do not wish to remove during uninstall.
3-Change the "Uninstall" property in the right pane to a value of "No."
For MSI Projects:
To prevent the files in a particular Component from being removed during uninstall:
1-Select the Components view from within the Organization folder.
2-Select the component that contains the files you do not wish to remove during uninstall.
3-Change the "Permanent" property in the right pane to a value of "Yes".
I see this is an old question but I just came across this. Seems to be a common problem. One good solution is to stage the files to a private directory mostly program files and then have a custom action do the copy and register (ocx etc). Installshield remembers what it copied so it tends to remove them. Do not disturb anything else like logging (my recommendation). Set conditions on the custom action so that it doesn't run during Uninstall.
Although sometime back I did another weird implementation which only programmers are used to doing.. Packed the files as resources and created my own code to extract and deploy (Something that Process Explorer kind of tool does). There were certain use cases that warranted this kind of implementation. But again this is complicated and obviously reinventing the wheel. Unless you are good with C/C++ and Windows API this would be difficult. I would still suggest you stay away from this kind of implementation because it is also considered a "virulent behavior". Yet, so far I never got warnings from the Anti-malware products.
I have an automatic update system that replaces my existing program files on reboot. (Suffice to say, it's a very complicated program with many drivers, services, and user level modules. There really is no other way. Trust me.)
The function MoveFileEx is used with MOVEFILE_DELAY_UNTIL_REBOOT to setup this file replacement. I'm finding that it works just fine, normally. However, if the source and target files are on different drives, the target is deleted but the source is not moved. The result is that when the user installs the software on a drive different from the system partition, an update deletes the product file rather than update them.
Now, I see in the documentation for MoveFileEx that MOVEFILE_COPY_ALLOWED should be used when moving a file from one volume to another. But it also says that flag cannot be used with MOVEFILE_DELAY_UNTIL_REBOOT.
Q: How can I move a file on reboot, overwriting an existing file, when the source and the target are not on the same volume?
Why don't you just copy the files to the drive where the user installed your program?
As far as I see there is no direct way to do what you want relying only on this function.
Finding writable location on the same drive might be a problem on Vista, but you mention you have services - if they run with LocalSystem privilleges have them write the new files.
One other simple update mechanism that I have used ( not working for drivers though) is to have dedicated update program - kill/end everything, let the update program do its work and start everything up again.