I am using MSVS 2015, and creating an installshield (limited edition) project to package my program files along with a COM dll. I could register the dll but I don't know how to unregister it during uninstallation. Where can I insert the unregistering code in which custom action of the project ?
In Item/step 5 (Define Setup Requirements and Actions), there is Custom Actions During Uninstallation of Custom Actions item but actions in After System Changes are futile because the dll I want to unregister is already gone before the code is executed.
If you simply need to register your dll during installation and un-register during uninstall, just mark your dll as "self registered" and MSI will take care of automatic registration/un-register at the proper time.
Sure enough, you are able to register and un-register your DLL manually with Custom Action. In this case schedule your CAs:
for registration somewhere after "InstallFiles" for example right after "SelfRegModules"
for un-register somewhere after "InstallInitialize" for example right after "SelfUnregModules"
Related
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?
Recently, I was assigned the task to create a deployment package for an application which btw, I'm totally new at. So far, so good.. Now there is a requirement to extract files from a zip file which will be bundled with the setup file. So, I had to write custom actions in the 'Commit' section of the Installer class. I added the Installer class in a new project of type 'Class Library' under the same solution. I wrote the code after 'base.Commit(savedState)'.
I tried showing MessageBox at the event entry point, used Debugger.Launch(), Debugger.Break() but somehow, no matter what I do, it seems that the custom action is not willing to be hit at all and the application just installs itself. I searched a lot of sites and blogs but no help so far.
I've assigned my installer class (SampleApp.exe, in my case) to all the Custom Action's modes (Install, Commit, Rollback and Uninstall) in the Deployment project. Any help.
P.S. I'm using a Visual Studio 2010 setup project.
Thanks, in advance!
You should probably be trying a class library Dll, not an executable (which is typically for something like a service).
You don't need it all the nodes if all you're doing is calling at Commit. And why Commit? Install is just the same in most cases.
If you're not seeing a MessageBox then probably your CA isn't being called, and that may because it's not a class library. Note that your CA is not running in the interactive user context - it's being called from an msiexec process running with the system account, so you must be very explicit about (say) the path to the zip file, and any user profile folders will probably fail because the system account doesn't really have them.
What files are these and where are they going on disk? If they are user profile files you can install the zip files to a per machine location and then have the application itself unzip the files to the desired location on first launch. Unzipping from within your setup is not good practice - it is error prone and bad design.
Using the application allows proper exception handling and interactivity (the user can be informed if something goes wrong). Set some registry flags in HKCU when you have completed the unzipping so it doesn't happen more than once, and perform the unzip once per user.
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
We have an eclipse feature that is licensed and the license is handled by our own code. The user can go in on our update-site and upgrade his feature. The problem we face is when the user's license needs to be updated before he can use the new upgrade.
What I want to do is to validate the feature version against the users license and warn the user that his license needs to be updated before he install.
I thought I would do this using a custom eclipse p2 touchPoint action validateLicense.
Example:
My code is called, where I validate the version against the user's license. If it fails I warn the user and he can then cancel the installation.
So my first question is:
Do I get this right, or is it some other way to do this?
My second question is pretty basic:
Where do I tell eclipse to run my code?
I have looked here at eclipse help where they explain what it is. But I don't understand where to put the information to run my code? Is it in the feature.xml.
Lastly:
Is there an example how to create and use p2 touchPonts?
I implemented a custom action as shown here and I have a system that seems to work. I left out "touchpoint" extension as it's unnecessary in my case, but the rest is the same.
My action is executed during install phase of my feature (instructions.install) but maybe configure phase could work too. Collect phase did not work.
The action is executed during installation process, after the download was already performed. Ideally it would be before the download but it's not a big issue for me. Returning an error status from the action cancels the install. It leaves some downloaded files around but they do not get activated and are probably removed later by p2's garbage collector.
I also managed to do some more interesting things. My actions plugin has a dependency (optional and non-greedy) on my main plugin. So the install works like this:
Actions plugin is downloaded
Custom action is executed
The action detects whether my main plugin is already installed and if yes, it calls into it to retrieve licensing info. The main plugin has to expose an API for the action. The action also checks main plugin's version to detect whether the API is there or not.
The action now can decide whether to proceed or cancel the install. It can even interact with the user using Display#syncExec (this is what the code in checkTrust phase does so I think it's safe). If needed, the action could also detect whether the install is headless.
Some gotchas:
Action itself must be versioned. It's the version you declare in plugin.xml and p2.inf files and it's different from plugin's version. I just replace 1.0.0 with the same version my plugin has. This way the latest version of the action plugin is always downloaded before being executed. This is great because now any problem changes to licensing rules can be implemented in actions plugin.
Actions API changed between Eclipse 3.5 and 3.6. I will probably drop support for 3.5 as it's pretty old anyway.
Actions plugin should probably be signed. It's the case in my case. The system seems almost too powerful to me as just pointing Eclipse to an update site gets it to execute downloaded code.
I still need to test how this works with different versions of Eclipse and other IDEs. I saw a strange (non-blocking) error with 3.6. However the results are promising and it looks like the system might actually work.
Touchpoints are executed at installation time, which means that the resolution (validation) has already happened. I'm not sure they would help. What about creating an Installable Unit (IU) (or Eclipse Feature) that represents the license the user has installed. Then you would put a dependency from your product to that license.
For example, create an IU called com.mycompany.license (1.0.0). You would create another one called com.mycompany.license (2.0.0). When you installed a license, the appropriate IU would be added to the profile.
Now, when you go to install you product, the new version of the product would require license version 2.0.0. If this license was not installed, the resolution would fail.
Does this make sense? Do you think this would help?
I have a setup project with InstallShield 2010. I'm deploying a configuration file during installation. However, when uninstalled, InstallShield decides to delete it (which is normal).
The question is, is there a way to keep the file on the hard disk even after the application in uninstalled? I don't want to reconfigure the application every time the user uninstalls/installs.
Edit: I'm using MSI project.
You don't say what project type you are using. Either way, put the config file in it's own component. For MSI projects, set the Permanent attribute to true. For InstallScript projects, set the Uninstall attribute to false.