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.
Related
I need to install multiple MSIs from a single unified UI.
I also need a 'feature' tree to let the user select which product(s) to install.
Having looked at similar questions, it seems Burn is the way to go.
Looking at this, it seems I must write a custom BA and implement my own feature tree.
Is this correct?
It seems I'll end-up with a custom UI that won't look like the standard UI for MSIs. This seems a pity when IMHO one the great thing about MSIs is that they always present the same UI to users and have been doing so for years.
If that's the way to go, is there a simple example to get started?
Does wix3.6 really not natively support feature tree? ...seems like a pretty basic and useful feature to have IMHO ...
The feature tree is a custom control on MSI and not available for general use. A standard tree control could be used but no one has added that feature to wixstdba. Of course, you could add the feature (start discussion on wix-devs#lists.sourceforge.net) or implement your own BA. The wixstdba code is in src\ext\BalExtension\wixstdba or for managed example there is src\Setup\WixBA. Both are reasonable places to start.
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.
I'm currently trying to compile an old program (made with C++ builder 2 or 3) with the "current" Embarcadero RAD Studio XE2.
So, I was wondering whether there is an easy way to use the old code, as Borland once claimed to be fully compatible to lower versions... however I couldn't find a "project-file", only source-code (.cpp, .h, .res, etc.).
I tried to "add to project" the main .cpp, however there seem to be some wrong include-paths... it also seem to use the OWL-package and includes its important source-files...
I'm a bit confused which type of main project I have to open first, since you need to open a new project before adding the source to it. As the running .exe has a GUI, I tried a Form-Window first, but it may be better to use a console or service as the real form is produced within the code as far as I understand.
So, after installing OWL and correcting the include-paths, do you think it should be running fine? Or is there something else to take care of?
If your old project was using OWL, you're probably well outside of the supported upgrade path.
That being said, valid C++ code should still compile and work and I've heard of people using OWL with recent versions of C++Builder. (via OWLNext)
Regarding your confusion as to which type of project to use, I believe a console application would be your best bet. A forms application is completely wrong, that will bring in the VCL and give you no end of problems trying to reconcile the different windowing systems. A service application is a completely different beast as well, and isn't meant for GUI applications. A console application should work, but you'll need more. The OWLNext project has a wiki that should help quite a bit.
I have a small diagnostic VB.Net application ( 2 forms, 20 subs & functions) written using VB.Net 2008 that targets Framework 2.0 and higher, but now I realize I need to support Framework 1.1. I'm looking for the most efficient way to accomplish this given these constraints:
I don't know which parts of the application are 2.0-specific.
I could reconstruct the forms without too much trouble.
I need to support SharpZipLib
My current idea is to find and install VB.Net 2003, copy over my code and iteratively re-create the tool. Are there better options?
Your app sounds small enough that I would create a fresh project/solution in a separate folder for the 1.1 framework, copy over the necessary files, use the "Add Existing Item" option, and then build. All the problems will bubble up to the surface that way.
A rather "ugly" approach, but it'll show you everything you need to fix up front.
Probably not. If you don't understand which bits are 2.0-specific, you're probably going to have to go the trial-and-error route. However, you can probably save yourself quite a bit of work if you go looking for generics beforehand. In my experience, those are the most numerous 1.1-incompatible bits that tend to make it into my code.
If you can gets your hands on VS 2010, you can (finally) target multiple frameworks. So within one project, you should be able to compile your 2.0 project to 1.1 and see what breaks.