Using Installshield 2013 Professional, and need help understanding how it registers dll's, ocx's, etc. in my Basic MSI project. I know that some of them are self registering, but I also know that marking a component as self registering violates best practices.
Therefore, I don't quite understand what I need to do. Should I just include the component leaving the self register box unchecked? Does the COM Extract at build setting have something to do with this?
Brian,
Com extract at build time is best practice option. It will extract registry data at build time and same you can see in different tables of MSI, appid, progid etc...
Related
Having been happy with ClickOnce for a long time, I've been thrust into the weird and wacky world of windows installers. It appears to be a world very short on documentation, unless I don't know what I'm searching for.
I'm aware there's lots of options for building an installer, including Visual Studio setup projects and WiX. Given that I'm looking at a fairly complex scenario, I suspect I'll be going with the latter. What I'm struggling with is doing something like this:
Two things to note about this.
First, it already knows what versions of SQL Server I've got installed. Second, the user can select which options to install and which to skip.
I don't know if there's a particular label for these functions that will help me search for them. But I can't find any details on how to start building this sort of logic into an installer, preferably with WiX.
Can anyone get me started?
This installer UI is WixUI_FeatureTree and it selected by UI reference.
Each line in the UI is a feature.
Each feature can be nested under other feature.
The name of the feature is a property that is set by searching the registry.
To choose if the feature should be enable, expanded etc. check the Feature Element.
Hope it will get you started...
I'm building a bootstrapper installer with custom UI. It has some prerequisites that it needs to check before installing and if anything is missing - show it in UI.
I have 2 possibilites:
Check it in XML of my bootstrapper with utils like RigustrySearch
Check it in UI and set some variables in bootstrapper
Have a custom extension and call it from XML
What is the best approach here?
Pros for having it in XML:
Native way of doing it
Pros for having it in UI part:
I could organize code nice and clean
I can have a separate Dll for prerequisites validation, or even a nuget package
I have way more flexibility and it's more simple to make complex assertions
I can have extra information for each prerequisite, like license info and user friendly name
Pros for having a custom extension:
Don't need to fiddle with variables in XML
I personally am more inclined towards the second option as option one is going to make my XML huge and more difficult to read if I have a lot of prerequisites. Option 3 is nice, but It's more difficult to show the user friendly name for a prerequisite and its license information in UI. What do you guys think?
I think this really depends on what your prerequisites are, and how you intend to handle their presence/absence. Here's my personal preference.
Generally, If I'm going for a managed bootstrapper application I'll have that do the detection of the prereqs if I then need some input from the user, ie. an installation directory, credentials, or whatever. I then pass some values from the managed app, into burn variables, and in turn into Wix properties for the individual msi's to respond to. This is my most used approach.
If all of your prerequisites are part of your bundle anyway, and you don't need any interaction from the user, I tend to go ahead as if I'm installing each package, and the packages themselves are responsible for handling their own upgrade/installation not required behaviours. ie. bundling .Net, or 3rd party installers with your application.
I tend to avoid custom actions for this sort of work, I find them a bit cumbersome when trying to deal with all the successful/failed paths of install/upgrade/repair/uninstall etc.
I think it's a bit subjective to your specific use case, and there's not a single best approach for all situations.
This question already has answers here:
MSI register dll - Self-Registration considered harmful
(4 answers)
Closed 7 years ago.
I am building an installer and use heat.exe to harvest all the required files. however I need to register some DLL and OCX files, I looked around how to do it bud there seems te be some debate aboud how to implement registering those files, on stackoverflow as well as on other websites and forums.
I would like to use the following: SelfRegCost="1" since it looks like the most simple way to register files. bud people dont like it because it could give problems when repairing or uninstalling the program.
what is your opinion regarding this method and what would you suggest me?
a example of the code implementation recommended would be highly appreciated.
thanks in advance.
Simply put, any form of self registration (COM being one of them) is an antipattern. There are various reasons a few of which are:
1) They add fragility to the install
2) They can halt a silent install when they fail.
3) They don't log any information on why they failed.
4) They are out of process; the installer isn't aware of them (no repair)
5) They break the transactional nature of Windows Installer (no rollback)
6) They slow the install down
7) They hide implementation details and can't be observed or transformed
I'd go so far to say this isn't a matter of opinion but rather a matter of best practice facts. But I suppose at the end of the day best practices are just opinions also. Still, I've authored thousands of installers over the last 20 years and I can say without a doubt that self registration should be skipped whenever possible. Instead use Heat to "harvest" the COM meta data and author it into your wxs code so MSI can handle this natively for you. There are other tricks that can be employed if Heat is unable to get all the details.
Finally, don't use COM whenever possible. For example you could consider using a RegFree COM manifest instead to simulate the registration of the component.
See: Do not use the SelfReg and TypeLib tables.
I'm trying to create a setup project and I can't believe how painful it could be. Non of the tools that I've tried to use, haven't satisfy me.
How come? Well, let's see:
First and easiest option: Setup project built in Visual Studio. Easy and fast. you can easily implement custom actions, even if you're code was written in c# or vb.net. Exactly what I wanted. But this approach has some drawbacks and the major one is unbelievably painful way to implement custom dialogs. For example if I need to ask for DB credentials, authorize the user and proceed with the rest of installation. But no. There is no way to build custom setup dialog in VS. Actually there is a way, but it's not an easy one. I mean what, are you kidding me? I have to spent a day to create a couple of simple dialogs?
Second option: Use some kind of a tool. Like InstallShield. You have to pay for it, yes, fortunately it's damn cheap. Only $5500. Not a big deal, right? Well maybe, but for me it's like "dude, forget about it"
Third option: Use WIX Nice, has many options. Not so easy to use like the one built-in VS but has many much better features. The only problem - I spend a few hours trying to convince that thing to run my code written in c#. I failed. Nothing helped and I give up.
Now. Please, please my fellow experts, all knowing developers. Help me. What should I do? What's the best way to solve my problem (believe me my boss will kill me, he likes to achieve results over dead bodies of his employees).
Tell me is there any better way to edit .wid files. Using Orca tool, isn't an easy solution.
Or show me a real example of setup project built with WIX which can run managed c# code.
Thank you!
I implemented a custom dialog by simply displaying a form in my custom action. This is a straightforward thing to do.
I don't suggest using either "Setup Projects" ( aka Visual Studio Deployment Projects ) or Managed Custom Actions ( in your context you are referring to InstalUtil custom actions ).
For managed custom actions I use Windows Installer XML - DTF ( Deployment Tools Framework ). This builds and packages your CA to look and feel to MSI like a C++ CA which means you can then consume it using InstallShield, WiX, Wise and so on.
I also don't suggest using CA's as fake dialogs. If you want a fancier UI write an external UI handler ( not a simple task ). I suspect your real problem though is that VDRPOJ doesn't expose this very well, that WiX is lot's of writing in XML. InstallShield gives you a drag drop IDE for working on custom dialogs. But then that would be one of the many reasons it isn't free.
I'm currently learning how to create msi installers using WiX and it seems I've hit a wall.
All is well when I create an MSI containing everything needed for a single environment.
I have features, and components, and can install my MSI.
Now I'm at the stage where I want to convert this in a SQL Server-style installer, where you have multiple instances support.
At the start I want to user to get a screen which allows him to create a new instance, or manage already existing instances. (to update/remove them)
I've spend 2 full days looking everywhere for a solution, without much luck.
I've found the following resources with some info on it, but either they're limited in the number of instances, or don't describe how to such a bootstrapper which gives a user the option described above.
Multiple Instance MSI's and InstallShield 12
Multiple Instance Transforms Walkthrough
Multiple instance installations and patching
Has anyone achieved this already using WiX? Or can anyone point me towards some working examples on how this is achieved?
I know Installshield 2009 can do this, but since this is just a hobby, I don't have the money to buy that. Also I'd like to do it in WiX, since the upcoming Visual Studio 2010 will improve support for it.
Creating multiple instances is pretty easy with WiX v3. You just use the InstanceTransform and Instance elements to create everything. Now, the bootstrapper problem requires something outside of the WiX toolset since we don't have burn, yet. I'm not sure we'll get this functionality in WiX v3.5 (with burn) but it is on our list for burn post v3.5.
Although I've never created a multi-instance setup, I also noticed that Acresso announced MI support in IS 2009. We have IS 2009 but didnt use this feature.
However, Installshield often simply makes use of new MSI features by offering an "intuitive" frontend to them (like for chaining multiple MSIs together into one). So you might want to look for general information on how to achieve that by using the MSI SDK.
Here are some useful links that might point you to the right direction:
Authoring Multiple Instances with Instance Transforms
Multiple Instance Transforms Walkthrough, Proposed Simple Addition to WiX to Make Them Easier