I have an old Legacy Application Developed in VB 6.0. They used some 3rd Party controls using IGSplash40.OCX,PVCalendar9.OCX etc..The code works fine in one server.
They have installed Infragistics NetAdvantage 2004 Vol.1 tool to use those controls in VB Application. Now I have to move the application to another computer.
When I open the application especially forms..It says unable to load xxxform.refer logs for details and while running also It says 'License information for this component not foud. you do not have appropriotate permisson to use this functionality in designer environment'.
Also, I collected those ocx files from another server and tried to run my application.
How to resolve this?
The developer package for controls normally includes not only the OCXs and DLLs involved, and not only the documentation, but an installer that puts the libraries, docs, and any necessary design-time licenses in place and registers them.
If you find yourself copying such files in place and manually registering them you're likely to fail unless you have some freeware library.
Even freeware libraries should come with a proper set of docs, a DEP file, and dev machine install package to put everything in place. Merge modules are a nice thing to offer as well. Sadly most freeware authors are generous if they offer a readme file.
There is more to the ecosystem of an OCX than just the OCX file itself.
The only fix is to replace these controls with controls that you do have licenses for, buy alternatives, or try to contact the original vendor about supplying a replacement install package or acquiring a new license and new package.
In Windows 7 you will find the usual .ocx files in the folder Windows\SysWOW64. In that folder there are a number of .srg files that seem to be the corresponding licenses. My problem was with richtx32.ocx and I had to open the corresponding RICHTEXT.SRG file, and create in the registry the corresponding key and introduce the license string manually.
Related
I have an app that I am moving to another server. It is complaining that it is missing TABCTL32.OCX. I have located this file on another server and I want to copy and paste it across.
I have discovered that there is also a file called TABCTL32.DEP on the server I am moving from. Do I have to copy both files across or is the dependency file optional?
I have tried it with an without the DEP. The app works in both cases. It is a production server so I want to be sure.
Those .DEP (depdendency) files are instructions about a library meant to be used by packaging tools. These files have no run-time significance, containing only development metadata. They are text files.
They contain the preferred ("designed") location to install the library, sub-dependencies of the library including optional localization "satellite" resource DLLs, version information, etc.
See articles such as INFO: How Setup Wizard and PDW Use Dependency Files.
This is information a packager should use along with other "rules databases" such as VB6DEP.ini. Programmers are also supposed to create them if they expect other developers to use their libraries.
If you are using an "impaired" 3rd party packaging technology that is ignorant of .DEP files it is up to you to read them and incorporate the information they contain in your build process. You are also responsible as a developer to keep your dev machine's .DEP files and VB6DEP.ini file up to date, since they often are not updated by Microsoft anymore.
You can't just copy files willy-nilly from one machine to another. Go find this program's installer and run it on the new machine.
A .dep file is a file used by the Visual Basic Setup Wizard to determine what dependencies your ocx file have. You can open the file with Windows Notepad to view the contents.
Unless you are using the Visual Basic Package and Deploy Wizard, you can ignore this file.
For more info, see INFO: How Setup Wizard and PDW Use Dependency Files
I need to create a custom installer that supports French, German, Spanish, Italian, Polish, Russian, English, chinese (mandarin script), more languages to be added for a .net based application.
This installer also needs to be able to check whether the target system has got adobe installed or not. If the target system doesnt have adobe or is a lower version than required then it should install from the CD. if it does then bypass that step.
The installer also needs to prompt the user to browse to any location on the system to pick up a file which will be place in the installation folder.
The installer also need to register this program in the add remove programs list.
Is there a custom installer that can do all of these tasks or do I need to build an application from scratch for it?
Thoughts... ideas???
Thanks for your time...
Short answer : Yes, all those things can be done, most of them easily.
WiX or NSIS are probably your two best free options. NSIS uses a plugin architecture for most of it's functionality, but the plugins are text-files, so you should have no problems downloading them. However, if your company is "funny" about licensing, then check the relevant licenses for each plugin early on - most are completely free to use, but Legal can fail to understand this sometimes...
Please find below pointers to the relevant sections of the documentation, so you can get it downloaded (I feel your pain by the way!)
Language Support
See Docs
Allow user to select a file and copy it
You will need the InstallOptions plugin. This allows you to create an extra page in your install wizard which can prompt for information. It allows various controls, one of which is a file explorer control (search for FileRequest in the link).
To copy the file, you cannot simply use the File instruction, as that extracts and copies files from the installation media, and will not act on files on the target computer.
Instead, you will need a plugin - e.g. this wrapper around the WinAPI. Alternatively, use the CopyFiles instruction.
Register program in Add/Remove programs
This is standard in both WiX and NSIS.
Detect Adobe is installed.
NSIS has the ability to check if registry keys exist, or named files exist, which are the two normal methods of detecting installed programs.
Due to severe limitations of the Microsoft Windows Installer (MSI) system it is required to create a bootstrapper in order to install multiple MSI files (due to pre/post-requisites). However, this introduces an distribution problem because you now have multiple files that need to be included with the distribution. There are of course multiple ways to distribute this as a single file.
1: An archive
You can put all the files into a single archive that users download. The obvious choice for MS Windows is of course a PK-ZIP archive. But this is not very user friendly. Users will first have to extract the archive, and then run the bootstrapper (which would be called setup.exe).
2: A SFX archive
Instead of distributing an plain archive file you could wrap it into a self extracting archive. Executing this SFX archive would prompt the user to extract and/or run the contents. But this adds yet another prompt to the whole installation process (#1: SFX prompt, #2: bootstrapper prompt, #3: main installer prompt). This is also not very user friendly, as it increase annoyance due to multiple prompts.
3: Single file bootstrapper
Of course there is the option to embed all the extract files into the bootstrapper. This is probably the most user friendly for a normal end-user. However, this is less friendly for system administrators, because usually bootstrappers are less manageable than the MSI files. An admin would rig the system so that all requisites are also installed when the main MSI is installed, thus the bootstrapper would not be needed.
4: Other?
An other unlisted method?
So what do you think is the best way to distribute a installer for MS Windows software that requires a bootstrapper?
We provide a single file bootstrapper for retail distribution and all single-user installations.
Volume licensing customers (e.g. 10+ seats) receive one (or more) MSI files along with instructions and a list of prerequsites that must be installed before our application will run (which slightly differ between XP, Vista and Win2k). The EXE blocks installation if the prerequisites are not installed, the MSI will permit installation under the assumption that the sysadmin knows what they're doing and might be installing the prereq's at the same time, before the next reboot.
Basically the single bootstrapper is for non-sysadmins, people who want a single click solution. System administrators and corporate IT support who prefer more fine grained control over their installation are happy for multiple files, even if it means more work for them. The single EXE file is available publicly, the instructions + multiple files are only available by contacting our sales team.
This method gives us the best of both worlds, as well as the ability to provide different default configurations for home and corporate customers - hints, tips, splash screens, auto-updates and welcome dialogs are all disabled by default for corporate installations but enabled for "single" users.
We use Wix to create MSI files which is hugely flexible and can easily be automated with build scripts.
To chain multiple MSI/EXE files together for distribution via single bootstrapper I would highly recommend DotNetInstaller. I'm in no way connected or affiliated with this product, but it has been a lifesaver on projects for generating highly configurable bootstrappers in unmanaged code.
I wrote up my recent experiences in developing a multi-language MSI and bootstrapper using these technologies here. This talks through the process from start to finish. Using DotNetInstaller you can download and install dependencies from a URL on demand, or embed them directly within the bootstrapper with ease. I did also consider WIX's own SETUPBLD bootstrapper generator and the GenerateBootStrapper MSBuild task but they are pretty basic. That said WIX 3.5 Burn utility is currently in the pipeline and could be a pretty decent alternative once it's released.
Regarding: 1: An archive: 2: A SFX archive
You could use a self-extracting .ZIP that automatically launches a Setup.exe. WinZip offers this support inexpensively. That way, it would be more customer-friendly. It can be configured to launch the bootstrapper without a prompt.
Regarding: 3: Single file bootstrapper
At the risk of sounding like an InstallShield salesman, InstallShield 2009 will take care of everything you're asking about -- it smooths over the MSI shortcoming of needing a bootstrapper. You could use the Release Wizard to create a single-.EXE all-in-one bootstrapper. Or you could create a web-deploy setup that is very small and then downloads the payload from a web site. Or you could put different features in separate .CAB files, and the user only needs to deploy those CAB files corresponding to the features he wants to install. InstallShield comes bundled with dozens of prerequisites ready to add to your Setup.
Depending on your siutation, MSI v4.5 and 5.0 might help you -- they have native support for multi-package transaction chaining. Of course, depending on what OSes you support, you may still need a bootstrapper to make sure the right level of MSI support is present.
I had a similar problem where I needed to distribute some optional support software, MSI installer, and another file just incase the MSI file needed it. I basically created a native application to handle the whole process. I wrote a blog about it here (http://blog.foldertrack.com/?p=45)
i'm using vs installer to build a setup package for my vb6 app.
and the problem is i can see that under the project explorer there's a list of dependencies attached to my exe file.
alt text http://img505.imageshack.us/img505/9696/croppercapture259lr8.png
and under the file system on target machine treeview, i can actually store the dll/ocx on a folder or in the windows system folder itself[the left window].
alt text http://img101.imageshack.us/img101/9224/croppercapture251qm1.png
so what i don't understand is .. is there actually a difference?
if i just set the dependencies and didn't add the dll or ocx to the folder or win sys folder, does the dll automatically get copied over too?
It is not guaranteed that all those dlls will be present on the system that the software is being installed on. So they need to be included in your installer. From there you have two choices.
You can install them in your windows system folders or in your application folder. The difference is that if you install them in your application folder you can set things up on XP and Vista so that the different version of the software with different version of the components can be fired up and run side by side. Installing them into the system folder will break any older version that depend on older version of the components.
Installing in the application folder rarely doesn't work if a component depends on other components that can't be updated. When this occurs it is usually with with Microsoft libraries. They have gotten better over the years on this issue.
You can read more about the issues involving side by side execution here
Finally the dependencies need to be in your installer so that they are registered in the Windows Registry. Unlike most .NET assemblies any ActiveX/COM application needs to have the component registered in order to use it even if you are using CreateObject and Variant types to access it.
I will admit the whole process is idiosyncratic and is one of the sources for the stories about DLL Hell. Start with the MSDN article, use wikipedia, and of course ask further questions here.
You should usually not have a "dlls" folder under the app folder for a normal Installer package but there are many factors involved (private standard DLLs, Reg-Free COM, etc.). Yes, the dependencies get included (unless you exclude them). They should each have a property that determines where they install on the target systems.
You also have a number of components in that list that are either not redistributable this way because they are OS-dependent system components, MDAC components, or not licensed for redist (fm20.dll for example).
Sadly this is an example of the type of package that can lead directly to DLL Hell for your users' systems. Fixing this can mean researching every MS component in MS KB articles to determine what can or should be redistributed and how.
Deployment can be a messy business to get right.
I have a VB6 application that needs to be installed on Windows Vista as a Standard User. Using Visual Studio 2005 I have created a setup project that will place the application in a standard user safe place or folder. I also have a dll that I want to install and register to the users application data folder. Once my windows installer is created in VS'05 I flipped the word count properties' 3rd bit using msiinfo.exe so that Vista will not prompt Admin credentials when it runs the msi. The application installs without any problems until it tries to register the dll to the users application data folder. When it reaches that point it throws an error stating that it cannot register the type library for the dll. It appears the installer does not have the authority to register a dll to the users folder. Is this correct? My understanding was that Vista only complained about standard users updating or changing items that affected all users of a machine. Any ideas? Thoughts? Suggestions?
Steve
My suggestion is, if you are able, to use regfree com / manifest files instead of registering the ocx/dll files, which as you mention is a real chore under a basic user account.
There is an excellent free app you can use to build the manifest for you as well here: http://mmm4vb6.atom5.com/
We have been using this for a few years now, with no issues.
EDIT The MMM website is down. I see here that the author was having trouble with their hosting and has provided another location to get Make My Manifest - download it here.
Instead of registering your DLL files directly, you can use RegFree COM.
This involves creating an XML manifest file for your app, so Windows will look for your DLL files in the application folder, instead of using the system registry to find them.
This means your app will run properly without your installer having to register DLLs.
These links have more info:
http://msdn.microsoft.com/en-us/magazine/cc188708.aspx
http://www.devx.com/vb/Article/32888/1954
You can use the free Make My Manifest software to create the manifest files you need:
http://mmm4vb6.atom5.com/
Generally I agree to what Joel Coehoorn says in his answer.
However, knowing how the registry works in this regard, I can make the suggestion that you try to manually register your DLL to HKEY_CURRENT_USER\SOFTWARE\Classes, basically repeating what regsvr32.exe would do to HKEY_LOCAL_MACHINE\SOFTWARE\Classes.
It's a bit of a hack, and maybe it won't work, but you can try it.
related post on MSDN: http://msdn.microsoft.com/en-us/library/ms693350.aspx (thanks to MarkJ pointing this out in the comments)
related post on vbforums.com: http://www.vbforums.com/showthread.php?t=507228
Unattended Make My Manifest is a remake of MMM that can be used to generate manifests in automated builds. It uses a script file to add depended COM components.
Registry-free COM: MakeMyManifest is well spoken of. It is an automatic tool for creating manifests for VB6 projects: I haven't tried it myself.
DirectCOM is an alternative to registry-free COM. It also has fans, again I haven't tried it.
EDIT The MMM website is down. I see here that the author was having trouble with their hosting and has provided another location to get Make My Manifest - download it here.
There is a semi-automatic technique for creating manifests for registry-free COM. You can create the manifests with Visual Studio 2008 (you can use a free version like Visual Basic Express Edition). Then make a couple of edits by hand to make the manifests suitable for use from VB6. See this section of this MSDN article for step-by-step instructions - ignore the rest of the article which is about ClickOnce.
Registering a DLL does impact all users (DLLs are registered globally) and therefore requires Admin permissions. There is no way around that.
The solution for newer programming environments is that the DLL doesn't need to be registered to be used. However, since vb6 relies on COM you're probably out of luck.