I am creating an msi installer using an Installshield setup project. The application is currently working correctly and is in use as a Click-Once application, but there is now a business requirement to create installation package (i.e. an msi installer).
Installer "works fine on my machine", but on a user setup it throws:
Error 1904. Module [path]\flash.ocx failed to register.
HRESULT -2147220473
I have confirmed that flash.ocx is being copied to the program directory.
The file appears to be a dependency of Crystal Reports, which is embedded in the application.
Edit
flash.ocx, I've found out, is specifically a dependent of CrystalDesisions.Windows.Forms. It is used in the CrystalReportViewer control.
I googled for just that string and this was the 2nd response. Have you tried this?
Related
I have created a new Visual Studio Word 2010 Template project, now I want to deploy it using a Windows Installer setup.
I followed this tutorial using Visual Studio 2012 with InstallShield 2013LE.
After installing the setup and opening the Word Template, it seems to work fine. However, after saving the template as *.dotx-document and opening it again the Installing Office customization dialog appears.
The message says There was an error during installation: Downloading file file:///[Path to the dotx file]/WordTemplate.vsto did not succeed.
To check whether I've made an error creating the setup and registry entries, I also tried Advanced Installer 10.9 Office Add-In setup, that creates the required entries automatically. It also fails with the same error message.
There is nothing special about the VSTO Addin. I started a new project for testing purposes, that adds a ribbon and a header to the Word Template file.
Finally I tried the built in Click-Once installer, with success, newly created documents can be opened without any exception. But it comes with some limitations. I would like to add some files and let the user choose the installation path, what doesn't seem possible.
So what am I missing to deploy my VSTO AddIn?
I believe that such a problem is coming from proxy server issues. The proxy server on the client machine is blocking the download of your vsto file that is considered as an executable file.Unfortunately the only solution I see was stipulated in an old post proposing to zip your installer and to send it to users ( which is not optimal, I must agree).
You must also run a command to clear the app cache any time you deploy (from your windows console):
rundll32 dfshim CleanOnlineAppCache
Hope that helps !
I have developed an Excel XLL using ExcelDNA and C#. I am at the point where I would like to begin testing the deployment, but cannot find much information that actually provides steps that work.
My project was developed as a Class library with ExcelDna references. In the .dna file, I have the code below that will pack all resources into a packed version of the XLL (i.e. the Pack="true" attribute).
<DnaLibrary Name="ExcelXLL" RuntimeVersion="v4.0" Language="C#">
<ExternalLibrary Path="ExcelXLL.dll" LoadFromBytes="false" Pack="true" />
I would like to deploy the packed XLL to the target machine in the path:
%APPDATA%\Microsoft\AddIns
In order to automatically register the XLL with Excel, I need to add a registry key that depends on the version of Excel that the user has.
For instance, on my computer (Windows 7 64 bit running Excel 2007 32-bit), I would need to add a registry key to the following path:
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Options\
The key would be type REG_SZ with the name OPEN (or OPEN1, OPEN2, etc.) and the value
/R "ExcelXLL-packed.xll"
I have 2 problems though. The first is in determining which version of Excel that the user has to get the correct path and the 2nd is to determine the correct OPEN version that I need to create (for example, if the user already has OPEN, OPEN1, and OPEN2 then I would create an OPEN3 key).
I am trying to do the installation using either the Setup and Deployment project or a InstallShield LE project and cannot determine how to go about this. Does anyone know how to do this or a better way of doing it?
EDIT 1:
I have done a great deal of research on this and have looked at several windows installers.
In the Package and Deployment and InstallShield LE, I can get the install/uninstall to work by putting an installer class into my class library and bundling project output with the install. In this approach, I handle inserting/removing the registry key using the installer class. The problem that I have is that the user must uninstall first before running a new install (no update capability).
I downloaded the Setup Factory demo version and can get install/update to work but cannot do the framework check (not shipped with the demo). Also, the uninstall fails (though I may be able to get this to work with some more investigation).
I am interested in using the WiX installer, but would like to know if anyone has a sample of how to perform the deployment using WiX. I would also like to know if I need to use the installer class or if there is a different way to handle the search for the OPEN[n] key under HKCU\Software\Microsoft\Office[Version].0\Excel\Options. If I were to use the project output to enable the installer class, then I need to have 2 separate target directories (one under Program Files for the basic project output and one under %appdata%\Microsoft\AddIns for the packed XLL).
Any help is greatly appreciated.
Thanks,
Lee
To detect Excel 32-bit vs. 64-bit, you can check the registry: Detect whether Office is 32bit or 64bit via the registry
For the OPEN, OPEN1, OPEN2 etc. you typically need a Custom Action in the install script that enumerates the keys.
Using IsWix and Wix 3.7, I was able to resolve this.
Useful links for how to register the components are as follows:
For generating a C# class to handle Windows Installer Custom Actions:
http://www.codeproject.com/Articles/132918/Creating-Custom-Action-for-WIX-Written-in-Managed?fid=1599130&df=90&mpp=25&noise=3&prof=False&sort=Position&view=Quick&spc=Relaxed&select=4131367&fr=1#xx0xx
http://blogs.msdn.com/b/jschaffe/archive/2012/10/23/creating-wix-custom-actions-in-c-and-passing-parameters.aspx
For setting the property of the CustomAction.config file to Content
WIX Custom Actions built for .Net Framework 4.0 does not work? Ways to resolve?
EDIT 1:
For general knowledge on WiX (Very important)
http://channel9.msdn.com/blogs/scobleizer/wix-team-the-most-used-piece-of-software-at-microsoft-and-its-open-source#Page=2
I added a service reference that points to http://api.microsofttranslator.com/V1/soap.svc in my project. After adding the reference an app.config file was created.
When I run the project everything works. After creating a setup file with Advanced Installer (program for authoring Windows Installer setup packages) I get the following error message when I run the installed program.
"Could not find default endpoint element that references contract TranslatorService.LanguageService in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element."
Can someone help?
This problem is not generated by the setup package created with Advanced Installer, it seems to be .NET specific. Here is another similar thread: Microsoft translator error
This is a problem I have been battling with for a few days and am now at my wits end. I am creating an MSI with Wise Installation Studio but I would bet it could be repro'd with any MSI authoring program. I have created a test sample for those that wish to repro with the MSI, DLL or WSI files that I have posted.
Create a new wise solution, saved as 'test.wsi' and creates 'test.msi'
Do nothing to this file except to add two custom actions after the MigrateFeaturesState action in the 'UI Sequence'
The first custom action is a 'Call DLL From Installation' that passes in no parameters and ignores the return code
The second custom action is a 'Call Custom DLL From Installation' that passes in no parameters and ignores the return code
Both actions reference the same DLL and same function, helloworld.dll and HelloWorld() function that just displays a 'HelloWorld' Message box
Expected Result:
Two hello world prompts and then the regular UI screen to start the installation process.
Here is my current setup:
Development Box:
- Wise Installation Studio 7.4.0.214
- Win7 x64 running with UAC turned off,
Test Box:
- Windows XP SP3
- Windows Installer v4.5.6001.22159
- .Net Framework v4.0
Here are my test cases:
Non-admin with ascii user name - Results are as expected for both 'ALLUSERS=""' and ALLUSERS="1"
Admin with unicode characters in name 'あくぇえ' - Results are as expected for both 'ALLUSERS=""' and ALLUSERS="1"
Non-admin with unicode characters in name '发涩' - Only the first prompt appears and an error is displayed for the second as follows:
"Error in custom action. The library C:\Documents and Settings\??[LongAlphaNumericString].TMP\WiseCustomCalla.dll is invalid or could not be found."
This happens for both 'ALLUSERS=""' and ALLUSERS="1"
Login with another admin and set user in #3 to admin, login with user in #3 again and we get the expected results.
I've tried messing around with forcing short paths and passing in an alternate path to the users data folder but nothing works. Anyone know why this is happening and how to fix it?
I've included all the files I used for this testing here, this includes a screen shot of the error message, the msi and msi.xml, the wsi file, the helloworld.dll (test with rundll32 helloworld.dll,HellowWorld) and logs for each test case above.
http://dl.dropbox.com/u/1797288/error.zip
What needs to be changed in the MSI/WSI file so that #3 works correctly for the 'Call Custom DLL from Installation' action?
Thanks,
Aaron P
I think the problem is caused by the way these DLLs are handled. A DLL from installation is stored in Binary table and automatically extracted during install. It's native, so it works as expected.
Call custom DLL from installation most likely uses an incorrect path for extracting the DLL during install. It may be a per-machine location which cannot be accessed by a non-admin user.
Try building the MSI with a codepage that supports the Unicode characters (you can set the MSI language). Also, try creating a log and post the actual DLL path.
Running any of the Crystal Reports 10.5 redistributables (CRRedist2008_x86.msi, CRRedist2008_x64.msi or CRRedist2008_ia64.ms) is supposed to, according to the Crystal_Runtime2008.txt file, deploy the following files:
CRVsPackageLib.dll
CrystalDecisions.CrystalReports.Design.dll
CrystalDecisions.CrystalReports.Engine.dll
CrystalDecisions.Data.AdoDotNetInterop.dll
CrystalDecisions.Enterprise.Desktop.Report.dll
CrystalDecisions.Enterprise.Framework.dll
CrystalDecisions.Enterprise.InfoStore.dll
CrystalDecisions.Enterprise.PluginManager.dll
CrystalDecisions.Enterprise.Viewing.ReportSource.dll
CrystalDecisions.Keycode.dll
CrystalDecisions.ReportAppServer.ClientDoc.dll
CrystalDecisions.ReportAppServer.CommLayer.dll
CrystalDecisions.ReportAppServer.CommonControls.dll
CrystalDecisions.ReportAppServer.CommonObjectModel.dll
CrystalDecisions.ReportAppServer.Controllers.dll
CrystalDecisions.ReportAppServer.DataDefModel.dll
CrystalDecisions.ReportAppServer.DataSetConversion.dll
CrystalDecisions.ReportAppServer.ObjectFactory.dll
CrystalDecisions.ReportAppServer.ReportDefModel.dll
CrystalDecisions.ReportAppServer.XmlSerialize.dll
CrystalDecisions.ReportSource.dll
CrystalDecisions.Shared.dll
CrystalDecisions.Web.dll
CrystalDecisions.Windows.Forms.dll
But I am unable to find these anywhere on the PC. Does anyone know what location they're installed to? All the other DLLs listed in the .txt file appear in
c:\Program Files\Business Objects\Common\2.8\bin
the GAC
Starting with the .NET Framework 4, the default location for the
global assembly cache is %windir%\Microsoft.NET\assembly. In earlier
versions of the .NET Framework, the default location is
%windir%\assembly
Use Process Explorer on a running version of the app, such as your dev machine, to see from where all of its DLLs are loaded.
EDIT:
Process Explorer is a great way to find out what DLLs are loaded into any Windows process be it from the GAC or any other location. This method (using ProcEx) is general, but IMO useful in many scenarios. ProcEx would indeed show you that a program's Crystal Redist was being loaded from the GAC.
SUGGESTED EDIT:
Find .NET DLLs in this way:
Find your task in the process list of Process Explorer
Double click on the task to show Task Properties
At .NET Assemblies tab open plus(+) sign, display App Domain etc. (only .NET processes will have this tab. Non.NET process will not have the tab at all)