I am using installshield LE 2012 for visual studio to create a installable file for my problem written in VB on .NET.
While my problem requires a third party driver to be installed first. So I added to run it as a custom action during installation "before first dialog".
However, every time I tried to install it, it shows the "error: catastrophic failure", which I have no idea what it means. Does it mean the process of installing the driver take too much time? or there is any resource collision problem between these two?
How to solve this problem? I really needs some help.
The OS I am using is Windows 7 Ultimate.
You need to get support from your third party driver vendor. Your custom action is calling out of process code that InstallShield has no control over. We don't know what your driver vendor, name and version is or how you are calling it so there's nothing we can do to help you here.
FWIW, InstallShield and Windows Installer has support for using DIFx to install drivers based on .INF files. But this isn't supported in the crippled InstallShield Limited Edition.
Related
I am trying to build a few different 32-bit C++ applications with Visual Studio 2015 that use CEF. To use CEF, I am currently acquiring the CEF prebuilts from Spotify. The dll wrapper for CEF is built using Visual Studio 2015 with some modifications to its CMake files to force it to build with MD and MDd mode regardless of other settings. This was sufficient to make these C++ applications run on some machines. Any machine on which Visual Studio 2015 is installed on before anything else they can run on, however some machines seem to exist in a state such that the program will produce an error on starting when lacking the MSVC 2015 runtime (as expected), but when adding the MSVC 2015 runtime the program simply crashes; however, it only crashes after CEF is used. These programs work fine when they don't link to libcef.dll and don't include the browser functionality.
Upon investigating, I found that libcef.dll, as built by spotify, links to MSVCP110_WIN.DLL, which is from the Visual C++ 2012 Redistributable package. Naturally, the application I am building links to MSVCP140.DLL, which is from the Visual C++ 2015 Redistributable package. This means that the application ultimately links to two runtimes simultaneously. I do not know if this is an issue, but so far it seems to be my best lead. Installing the Visual C++ 2012 Redistributable does not change the outcome and it continues to crash when CEF is used.
This issue has been witnessed on both Windows 7 and Windows 10 and the application works without CEF on both of those operating systems as well, so the operating system is not likely to be the cause of the failure on these systems specifically.
Has anyone else encountered this issue and does anyone know a workaround? Also, does anybody know if it is okay to mix these two runtimes and what the limitations are? It seems that the installation history of a given machine affects the success of running the application, so any hints into what combination of things leads to this failure would be helpful as well.
You have some options:
Use the lastest version of VS that will allow a selection of Platform Toolset that matches libdef.dll. For example, VS2013 might allow the selection of the 2012 CRT.
Or convince Spotify to rebuild libcef.dll such that it matches your version of CRT
Or convince Spotify to not release libraries that depend on the CRT (yes that's probably a bit of work).
Or make a small app built against the older CRT, this app can then successfully use libcef.dll. Then you get to use any IPC technique so that your main VS2015 app can talk to this wrapper. Running out-of-process is one way to segregate the unruly third party libraries.
EDIT:
This is open source? Well good news, you can fix this yourself, built the CEF against your favorite version of VS.
I have a software that is coded in C#. It depends on two(!) third party dll which require Visual C++ 2008 and Visual C++ 2005 redistribute. Originally the installer was built in InnoSetup with all "vs200x_sp1_vcredist_x??.exe" embedded and run on install time. However since it lacks of some advanced features we decided to migrate to Wix Toolset.
The problem is, MSI was running in a more restricted environment, so I didn't figure out what is the best way to require those redistributable file being executed properly. I was tried to use merge modules instead but it didn't work - I can see that the files were installed but dependency walker shows that dll is still not link to the right version.
I think that WinSxS makes things worse at least in this case, since the software keep failing with some error message regarding "Windows Side by Side configiration (14001)" when I use the merge module approach.
So the question is:
Are there any way to build a MSI that runs a exe that install some prerequisites? I wouldn't mind those prerequisites being downloaded or just embedded.
I know that WinSxS information is stored in the manifest of the dll. So if I was permitted to remove the manifest information by the third party company, and use dynamic dll loading instead the problem could be resolved. However is this legitimate? Since I will then need to embedded the Microsoft dlls directally in the msi.
I have noticed one of the dll's manifest says its required version is "9.0.21022.8" but the one in my MSM file is "9.0.30729.6161". Is this the issue? If so can I resolve the issue by I modifying the manifest to allow the right version? I don't think this will cause the dll not working, anyway.
The msi file should install only your software. If you need to install pre-requisites, you should use a bootstrapper for it. Bootstrapper's responsibility is to install pre-requisites and it's not a task of your msi.
If you see that wix bootstrapper is complex you can try on a simple bootstrapper like the dotnet installer bootstraper. you can download it from
http://dblock.github.io/dotnetinstaller/
I develop an unmanaged DLL with Visual C++ which is part of my application. I have always had various problems with linking the VC runtime library. Somehow I managed with VS 2005, but since I moved to VS 2008, the release version of my DLL no longer works on any PC other than the one with my development tools (namely VS 2008).
I link the runtime library as multi-threaded DLL (/MD). I tried the /MT option but that causes a lot of error messages. I allow isolation of the manifest file, and of course installed the VC++ 2008 runtime (although I don't think it should be needed). I also tried the dependency walker to check what is missing. On my development PC (VS 2008 SP1 installed) three files are reported missing:
MSVCR90.DLL, GPSVC.DLL, IESHIMS.DLL
But that does not stop the application (and my DLL) from running.
On all other PCs I tried to install my application on, apart from these three, a fourth file is reported as missing by dep. walker: MSVCP90.DLL.
More importantly, my own DLL is not working as well.
I know this is nothing new and I tried to read everything I could find about SxS problems but I still don't know what to do. Hopefully my description of the 'phenomenon' is good enough for someone more experienced to give me some help.
Thanks in advance.
You may need to distribute and install Microsoft Visual C++ 2008 Redistributable, OR SP1 versionf of it.
I am trying to deploy a Visual C++ application (developed with Microsoft Visual Studio 2008) using a Setup and Deployment Project. After installation, users on some target computers get the following error message after launching the application executable: “This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem.” Another user after installation could run the application properly. I cannot find the root cause of this problem, despite spending several hours on the Visual Studio help files and online forums (most postings date back to 2006). Does anyone at Stack Overflow have a suggestion? Thanks in advance. Additional details appear below.
The application uses FLTK 1.1.9 for a GUI library, as well as some Boost 1.39 libraries (regex, lexical_cast, date_time, math).
I made sure I am trying to deploy the release version (not the debug version) of the application. The Runtime library in the Code Generation settings is Multi-threaded DLL (/MD).
The dependency walker of myapp.exe lists the following DLLs: wsock32.dll, comctl32.dll, kernel32.dll, user32.dll, gdi32.dll, shell32.dll, ole32.dll, mvcp90.dll, msvcr90.dll.
In the Setup and Deployment Project, I add the following DLLs to the File System on Target Machine: fltkdlld.dll, and a folder named Microsoft.VC90.CRT with msvcm90.dll, msvcp90.dll, mcvcr90.dll and Microsoft.VC90.CRT.manifest.
The installation process on the target computers getting the error message requires having the .Net Framework 3.5 installed first.
Any suggestion? Thanks in advance!
Add the Visual C++ Redistributable to your Deployment project and be sure to run Setup.exe instead of the MSI when installing. This will invoke the VCRedist bootstrapper to ensure your PC has those pieces before installing your app.
Dependency Walker only shows static (link time) dependencies - it cannot possibly know about dynamic dependencies such as COM objects.
I had a similar problem after the ATL security updates last year. My app needed a later version of the C++ runtime libraries than the deployment project included.
Try running Windows Update on the target machines after installation, or download and install the latest (28 July 2009) C++ redistributable package directly.
http://support.microsoft.com/?kbid=973551
That solved the problem for me. I haven't fixed the deployment project yet though.
I have a set of Windows programs that is mostly created with VB6 and VC++ 6. Its installer is created using InstallShield.
A couple users have recently reported a problem trying to install it on Vista. It is complaining that "MDAC 2.6 Sp2 cannot be installed on this machine. MDAC 2.6 Sp2 requires any one of the following configurations", and then lists several OSes, Vista not among them.
A little googling shows that there's a bug in InstallShield's handling of MDAC - it shouldn't be checking for it on Vista, because there is no such thing as MDAC on Vista (there's a new thing - "Windows DAC").
I could make the change to my InstallShield project suggested on that page, but I am concerned about doing so, because I have no way to test it (this problem does not occur on all Vista machines, and I haven't been able to make it happen on any Vista machine I have access to).
However, after looking at Wikipedia's page on MDAC, I can't imagine why we would need it for our programs in the first place. We're not using any databases, at least not explictly (maybe some Microsoft component that we're using is using it, though?).
I was not the original author of the InstallShield project. I am beginning to suspect that MDAC might have been inadvertantly added to it, or perhaps advertantly but just as "uhhh, maybe we need that".
How can I explicitly tell whether my programs need MDAC or not? I can look at the references and such in the VB6 and VC++ projects; is there any way to tell from those whether I can safely remove MDAC from the InstallShield project? For example, perhaps there's a single MDAC reference which, if not present in my VB/VC++ projects, means that my programs definitely do not require MDAC?
Thanks in advance for any help.
I expect you are right, MDAC was probably included with the original InstallShield project configuration, and nobody has bothered to remove it.
On the VB6 side you should be able to tell if MDAC is being used by going into the "References" dialog (I think its in the Projects dropdown menu of the ide) and checking to see if there is anything in there to do with MDAC or MSAccess. I haven't worked with VB6 in a while, but the text should look something like "Microsoft ActiveX Data Objects 2.x Library".
I'm guessing it is less likely that it is being used On the C++ side, but you could try searching for keywords like msdado, mdac and msaccess to see if theres any sign of a #import on one of the mdac dlls.
When deploying to Windows XP and later there is no reason to include MDAC or Jet 4.0, since even XP RTM (gold) shipped with MDAC 2.7 as well as Jet 4.0.
Microsoft Data Access Components (MDAC) release history
How to obtain the latest service pack for the Microsoft Jet 4.0 Database Engine goes into more recent Jet history.
MDAC releases include compatibility typelibs for ADO, so even if your program was compiled against MDAC 2.6 it will actually use the latest ADO on a target machine. The real grief can come if the program early-binds to ADOX.
ADOX never shipped with appropriate compatibility interfaces, so programs should almost always use late binding with ADOX.
DAO is another issue, but (a.) nobody should really be using it anymore without a good excuse and (b.) it died at DAO 3.6 so there should be no compatibility issue as long as your programs were upgraded to 3.6 and Jet5x (Jet 4.0, Access 2000 format).
The story gets more complicated when deploying downlevel from XP of course.
Beginning I think with Windows XP Microsoft began including MDAC. However, in MDAC version 2.6 and later they no longer included the Jet 4.0 components. (Jet 4.0 SP8 can be found here)
If you are using Visual Fox Pro you need to install either the ODBC or OLEDB drivers depending on you code for that.
ODBC
OLEDB
All of these downloads depend on having at least MDAC 2.6 installed.