I desperately trying to convert .vdproj proj. into wix project, with same custom actions(reason is that i dunno exactly what all is installation supposed to do) - right now confused about this:
/installtype=notransaction /action=install /LogFile= /sd="[SourceDir]\" /td="[TARGETDIR]\" /cf=[CF] "[#_DF75DCA6_84B6_7B49_8F15_EAEE08D32EA4]" "[VSDFxConfigFile]"
No idea what [VSDFxConfigFile], and missing overall picture what is behind this Custom action generated by Visual Studio in WinService project.
If anyone give me clue about PROCESS i would highly appreciate it!
Update:
today i discussed installer requirements and one which is known among collegues is that it should be able to change .config file according to parameters - XML has whole configuration element tree in it - and it should replace installed .config file - i just wonder if there is direct way to accomplish this in WIX
Moreover - .vdproj files already has some custom actions in it(which i guess aren't standard custom actions) - which calls some dll lib .NET installer component - which i guess changing .config according to parameters, but way it is happening isn't really clear to me. I used ORCA and MSI logs, however i still feel like Alice in world of dreams. Well thing is that also i'm unable to say what all parts of code called so that's why i still thinking call all CustomActions which are generated in msi file throught vdproj
Ignore all that stuff. it's related to managed code custom actions, and managed code custom actions don't use the same framework in WiX - they use DTF. VS setups put several custom actions in that you don't need to worry about, such as checking for the NET Framework. So it's going to be pointless trying to transfer internal VS custom actions (because WiX has its own that do similar things) and because your managed code custom actions won't use the same framework of installer classes, Install methods etc.
VS setup projects install services with Installer classes, and WiX doesn't use those either - there's no reason to, because Windows Installer has built-in support for installing/starting/stopping services, so if your manage code is realted to that then again, ignore it.
p.s. This may be useful:
http://blogs.technet.com/b/alexshev/archive/2008/02/10/from-msi-to-wix.aspx
Related
We have a product with more than 100 'pieces' most of which are optional 'plug-ins'. We would like a non-programmer to be able to make a "customized" installer on a per-customer/sale basis. Our ideal would be simply a single executable/msi with a folder structure from which files/folders could be deleted, then when run the installer would simply not offer features corresponding to the deleted bits.
A separate, but similar issue is that the developers of these plug-ins are not installation experts and we would prefer not to have to edit shared installer source to add/remove one from our build-set. We've been using the "synchronized folders" feature of Advanced Installer for this, but we would like a separately selectable feature for each plug-in.
Is there an installer tool-chain that can support such(or similar) behavior?
If so does anyone have tips on how to actually implement it using said tool?
I created such a tool stack at my last job. We did product line development with dozens of service families, hundreds of features, thousands of merge modules and tens of thousands of files in a typical installer.
Each merge module was authored using IsWiX and compiled using WiX. We then used WiX XML as an input to our build automation system to generate InstallShield installers. A service family would have an XML file to describe it's portion of the feature tree and it would all get emitted into an empty InstallShield project.
Finally a product XML file would describe the INSTALLDIR, UpgradeCode and other meta along with which features to consume. We built dozens and dozens of installers off this common base code.
It would take days to explain everything but that gives you the idea. For a simpler environment you could create a UI to generate WiX code and then compile it into an MSI.
But I don't know that I'd ever give this to a non-programmer. Creating installers is programming.
There is no tool that creates features at runtime in the MSI package, at least no MSI based tool. This complicates too much the installer logic, as you would need a very complex custom action that reads the contents of the folders found next to the installer and then generate entries in the following MSI tables: Files, Directory, Component, Feature, FeatureComponents. And then inter-connect all of this.
That is not something easy to do at all, and very error prone is tried by something how does not have extensive experience in building MSI packages.
have you considered/tried any non-MSI package builders?
I've managed this in Wix but my colleague wants to replicate it in Installshield 2013 Express. We have found the 'custom actions' section in Installshield but we cannot see where we can make it run after Installfinalize, it needs to come after copyfiles AND have Execute="immediate". All of the options after copyfiles have Execute="Deferred".
In Wix I have a VBScript which reads the MSI Session.Property("OriginalDatabase") and then uses this to write to some config files which are installed by the MSI. The point being that if we rename the MSI then the config is adjusted to reflect the MSI filename.
I would have posted a screenshot of the IS custom actions UI but I need '10 reputation' to post images - So the link to the image is -> Here
Two possibilities here....
1) Since you say it's MyFile.cfg I'll assume it's not .INI or .XML format. In that case, use the InstallShield Text Files Changes view to author a search and replace on the files. The InstallShield custom actions support UAC and Rollback so you'll be good to go there. You will probably need a very simple InstallScript custom action to read the OriginalDatabase property, parse out the part you care about and assign it to another property. Then use that property in the Text Files Changes view.
2) Why have the entires in the .cfg file at all? What application reads these values? Refactor that to not need the cfg files. Windows Installer exposes an API that allows you to query the installer service for information related to installed products. You can ask MSI what the MSI name was for an installed application and then use that information for whatever you need it from. Put the logic in the application and simplify the deployment story for a more robust installer experience.
You are going about this all wrong. Custom actions that modify the machine state should always be deferred and scheduled between install initialize and install finalize. Failure to do so will break in an UAC environment and also not support transactional rollback on failure.
Are these XML files? I'd use immeadiate custom actions scheduled just after installinitialize to emit temporary records into various MSI tables. The concept is to leverage DuplicateFiles to clone the file to a name based on the MSI name. You'd also have some work if you need to modify the files. Done correctly and your installer will still have full rollback functionality and work in an advertised / UAC scenario.
Also, VB/JScript custom actions are not reliable.
We have an off the shelf application with hooks built in to handle customer specific needs.
The custom code uses the same core libraries as our standard application.
Our current process is ship the standard app via an MSI and then separately send along the custom dll.
How is this typically handled?
create a setup project for each customer with the custom dll included with the main app(this seems unmaintainable)
keep sending the standard msi and send the dll separately (this has already proven to be terrible idea)
send the standard msi in addition to a custom code msi
other
If I'm understanding your question, you have one part of the application that is common to all users, and another part of the application that is custom-made for each user?
If that's the case, you should consider implementing the common part of the application as a Merge Module. Then, you create the custom part as an MSI and include the merge module inside. This would make the common part much easier to manage.
MSDN article on merge modules
See this question, our requirement was to embed custom configuration files in the MSI.
You should be able to modify this fairly easily so you have a "standard" MSI, and then ship an MST+CAB file containing the custom code. MST files are already familiar to administrators deploying applications over a network, if your customers generally double-click to install then you'll want to include a batch file or instructions on how to install with a transform.. e.g:
msiexec.exe /i setup.msi TRANSFORMS=test.mst
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.
There are lots of tools for creating installers on Windows (InstallShield, InnoSetup, NSIS, just to name a few). All tools I've seen fall in one or both of these categories
Point-and-click. Nice GUI for creating the installer, but the installer definition/project file can not be manually edited.
Textfile: No (official) GUI. The installer is compiled from a definition in a text-file which is manually edited.
The installers I'm building are all defined using a DSL (represented as YAML files), so using a GUI is out of the question, and creating is textfile is cumbersome although doable.
What I really would want is a tool which exposes a (complete) API, through which I can control the creation of the installer. Are there any such tools out there?
Edit: I'd love to hear about non-MSI based tools as well. MSI is not a requirement (rather the other way around...)
Wix 3.0 beta has .NET support included for this purpose. I don't know how well it works but it includes documentation. It's a framework of types for manipulating the installation creation process and all that goodness, so I don't think you even need to write a line of WiX XML if you don't want to.
WiX is a great tool, but you will have to do a lot of direct coding in order to make things happen. Fortunately the documentation is pretty good and there are several GUI tools, such as WixEdit on SourceForge to aid in the process.
Well, there is the Windows Installer API which you could use to create MSI files directly, however I think you'd be better off using WiX.
The "direct coding" will be much less than dealing with the Windows Installer API directly, I'm guessing that's probably going too "low level" for what you need. Depending on what you're looking to do, you could use WiX to generate an MSI and then tweak that afterwards using the API.
What's wrong with generating XML? That's really going to be your simplest option... you won't need to manually edit it, just write your own code to generate the required XML from your DSL files and a few templates.