Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
does anyone know an Open Source Software for creating own MSI packages?
I wanna create an MSI file for installing a 3rd party Software. Currently it's installed via different commands (bat-file) and with different configuration files.
Is there a free Open Source software for recording an installation so that i get a MSI package as a result?
WiX is open source and is one of the best way to create MSI file. Some other tools (mostly commercial). Please check this answer for more information: WiX Quick Start Suggestions and links (has grown too much, maybe focus on first sections - including "Hello World & Hello WiX").
The linked answer contains links to descriptions of how WiX compares to other deployment software - both commercial and free as well as download links and "get started" recommendations.
I would recommend packaging with WiX, but if you want to capture the install as an MSI file you can check the discussion here: Capturing all changes during an application install on Windows.
You might want to try ISWix - a simple GUI front end for Wix that allows you to quickly throw together an installer by inspecting the config files and recreating the actions in Wix.
Finally you could download a trial version of Installshield AdminStudio - capture your install as an MSI using the built in capture tool. Then you can decompile the MSI with the tool dark.exe from Wix and recompile it as a Wix MSI to get around any trial restrictions in the Installshield capture.
You could even use the method suggested here: Tracking file and registry changes. As this answer mentions you could try to locate the old version of WININSTALL LE on a Windows 2000 Server CD in \VALUEADD\3RDPARTY\MGMT\WINSTLE.
Advanced Installer Architect allows capture, but I am not sure you can export a proper MSI file with the trial version.
There are several solutions, for example:
Wix Toolset
Nullsoft Scriptable Install System
There is also this free one, (from comment: although it's not open sorce) also open source:
Inno Setup Source available at github
Related
I have question regarding WiX/MSI packaging, wanted to check feasibility, I have Installer1 bundle with n number of files(probably 100) and have another small installer2 with less no of files(near about 20 files). Now my question is can I package small installer2 into bigger installer1. This is similar approach as most of installers package vcruntime installers in their installers.
Experts do you see any issues in this approach?
You may want to ask question, what type components installer2 has- so it kernel mode drivers and user mode services and some DLLs.
Also you may suggest why we are not bringing one by one component, instead packaging one installer into another installer.
Chained Setups: WiX's Burn module can create setup.exe files with embedded installers that can run in sequence. Installshield also has a feature for this called Suite Projects - see screenshot here.
Hello Burn: Here is a small, hands-on example of a Burn source.
More on Burn: Some more details on WiX / Burn versus other deployment tools.
Two, separate answers here on Burn, Installshield and Advanced Installer
Short, ad-hoc list of various common MSI tools here.
Links:
WIX Toolset I want the ActionData log to continue to be written as a scroll
WIX Installer with modern look and feel
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I need to create MSI using Wix. My application has Active X control. When any user gets connected or visit the URL on the web my application needs to be installed in the user machine.
The path where I need to install is C:\Windows\Downloaded Program Files\CONFLICT.xx and this folder should contain the file ATL80.dll, app.dll, MSVCP80.dll MSVCR80.dll.
I saw few articles but got confused with them. please let me know how to start for this and what steps i need to follow in order to make MSI.
There is more to this: Packaging ActiveX Controls.
Essentially a web page will request a signed cab to be downloaded and installed via a CODEBASE URL, like this:
(sample from the Microsoft article linked above)
<OBJECT CLASSID="clsid:dcf0768D-ba7a-101a-b57a-0000c0c3ed5f"
CODEBASE="http://webserver/time.cab"
ALIGN="CENTER" WIDTH=270 HEIGHT=26 ID="T1"><PARAM NAME="Interval" VALUE=1000>
<PARAM NAME="Enabled" VALUE=1></OBJECT>
The requested cab is downloaded (time.cab), and installed (standard Microsoft cab installation / extraction). The next time the web page is opened the Active X control should work as expected. That's the normal case (admin rights are required for this to work). A successful install here can be captured and packaged as an MSI. Heavy cleanup is required though, due to all the certificates that are involved to complete the install. None of the certificates are required in the MSI as I recall, since an MSI runs with admin / elevated rights and dump files straight in the folder. Quite a security problem if you ask me, but these cabs are rarely deployed this way. Unsigned cab files won't work though (unless IE is customized).
The CONFLICT folder that is created in this users case indicates that there are discrepancies between the installed files from the cab and the version of those files specified and expected by the web page. This causes IE to trigger a new CAB download. Upon discovering the same files already exist in C:\Windows\Downloaded Program Files\ a new CONFLICT sub folder is created each time, and the user gets prompted for a new Active X installation every time the page is opened.
You must work to resolve the file versions specified by the web page and the versions of the files found in the cab. These versions must match. I can't recall all the details, but it might be that all that is checked is the CAB file version:
(Sample from this Microsoft article)
<object id="CommonDialog1" width="32" HEIGHT="32"
classid="CLSID:F9043C85-F6F2-101A-A3C9-08002B2F49FB"
codebase="http://activex.microsoft.com/controls/vb5/comdlg32.cab
#Version=1,0,0,0">
</object>
This is really a question about the Visual C++ redistributables because ActiveX controls installed from a web page don't need installing with an MSI. If that's all you're doing then the short answer is that you get hold of the VC 2005 redistributable and run it, this kind of thing:
http://www.microsoft.com/en-us/download/details.aspx?id=3387
This installs the C++ support files like ATL80.dll etc in the right places and it just works. You don't get much say in where they go:
http://msdn.microsoft.com/en-us/library/ms235316(v=vs.80).aspx
It's dangerous to have your private versions of those Dlls because there are security fixes for them, and if you have a private copy that the MS security updates can't find and fix then you effectively become responsible for maintaining them on the client systems.
On the other hand, I can't be sure from your question if you have a separate MSI file with a lot of other stuff in it (not the ActiveX) that you want to install by having people download it.
Are there any good references/examples for WiX Burn 3.6 custom UI?
I googled around, but they are broken pieces of the information.
The WiX installer itself is a good example and the source is freely available via CodePlex (WiX 3.6 Beta). Check out the WixUX project, which is the bootstrapper for the WiX 3.6 install. Another Stack Overflow question is Custom WIX Burn Bootstrapper user interface?, describing how to get started.
Or if you get the latest weekly WiX releases, the project has been renamed to WixBA. See src\Setup\WixBA.
Yes, they are scattered all over. I am using Visual Studio 2010 to maintain my Product.wxs with a separate WXS file for the UI. Basically I've downloaded WiX Edit to design the UI.
A good start is to download the WiX source which has WXS UI files you can load into WiX Edit to see how they work. You can download the source from here.
What I did was to copy one of the WixUI files to my project in Visual Studio 2010. When you download the source they can be found under wix36-sources\src\ext\UIExtension\wixlib. In here you will find:
WixUI_FeatureTree.wxs
WixUI_InstallDir.wxs
WixUI_Advanced.wxs
WixUI_InstallDir.wxs
WixUI_Minimal.wxs
WixUI_Mondo.wxs
You can tell from this the dialog flows. However there are the individual dialog files in here such as:
CancelDlg.wxs
BrowseDlg.wxs
You can load these into the Wix Edit to preview the dialog. You should get a better understanding.
Additionally, the main Wix Page can be found at Wix Toolset.
I have ordered the Wix book, WiX: A Developer's Guide to Windows Installer XML, from Amazon which I hope will help me understand this more. £30.99 in the UK. Hopefully, this book will be money well spent. There is one review with five stars so fingers crossed.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have built a project using VS 2010 and I have 2 reports I am creating within the project. While in VS2010, I can debug the program and the reports work perfectly.
Now I have come to the point where I want to publish my project and install it on a machine that my program will be used on. I tried 'Publishing' my project and running the 'Setup' file on the other computer and I get the following error:
Unable to install or run the application. The application requires
that assembly CrystalDecisions.ReportAppServer.CommonObjectModel
Version 13.0.2000.0 be installed in the Global Assembly Cache (GAC)
first. Please Contact your System Administrator.
Doing some research, I have found out that you can manually change the GAC or have Windows Installer fix it for you. To be honest, I don't know where the GAC is or how to modify it. My ideal solution would be to figure out how to setup Windows Installer to fix the GAC and configure Crystal reports however to get my project to run on a basic machine.
Can someone help me setup Windows Installer to install the appropriate Crystal Reports Engine so my project will work??
I am new to Windows Installer, so overkill on details won't bother me a bit!! Thanks so much in advance!!
You can try adding a Crystal Reports runtime installer as a prerequisite to your main package. You need the one with version 13.0.2000.0.
You can read more about prerequisites here:
http://msdn.microsoft.com/en-us/library/77z6b8tz(VS.80).aspx?ppud=4
http://msdn.microsoft.com/en-us/library/ms165429(VS.80).aspx
http://msdn.microsoft.com/en-us/library/ms165429.aspx
You could also try setting CopyLocal=True for the crystal references.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have a pretty huge web application developed using asp.net 3.5 and I need to prepare an installer package which will be using to deploy the application on IIS 6 and 7. I have done a lot of research on Wix and Installsheild 2010 (pro) and need some advice before making decision. I notice that the installsheild is quite expense in terms of license but for me, I have enough budget so that won't be an issue. the installer should be able to perform the following processes.
Deploy the published web resource
(aspx etc).
Create Virtual
Directory.
Create Database on sql
server and run some initializing
scripts.
Modify XML files and
web.config files.
Set the
permission to allow writing to the
files in the virtual dir.
I found that both technologies are capable of doing the above scenarios but I would like to get personal experience and advices.
Having created a Wix installer to do exactly what you're looking to do, I'd happily recommend it.
The benefits of Wix over InstallShield as I see it:
Since Wix is free, everyone on your team can install it, and thus everyone can contribute to the installer. If one dev adds a library to the project, they can update the installer as appropriate, without waiting for the "Setup guy" to do his bit.
There are no issues with installing Wix on a Build Server, making it a nice fit for an environment where you use Continuous Integration. It integrates nicely with MSBuild (see the Votive project).
Wix installers are built from text files, making them very easy to version control.
Wix includes Deployment Tools Foundation (DTF) which makes it very easy to create custom actions using .Net code.
Wix is close to the metal: you can usually apply your knowledge of Windows Installer quite directly to Wix. Conversly, learning Wix teaches you a lot about Windows Installer which is always good when it comes to providing support for deployments.
To balance this, there are a few things to be aware of:
Wix does have a steep learning curve. If you haven't already, check out the WiX tutorial.
WiX isn't a "visual" environment like InstallShield - it's usually text and xml all the way. Having said this, there are editors, free and commercial.
Specifically relating to IIS setups: Wix 3.0 only works against the IIS 6 metabase APIs. To install on IIS 7, you'll have to enable the Metabase Compatibility feature on the target server. Full support for IIS 7 is coming in Wix 3.5 - I've tried the beta of this, and it seems to work fine so far.
Based on my experience with Wix and InstallShield, I would recommend using InstallShield unless you need a fairly basic and straightforward installer. I say this because the huge Wix learning curve is made even more difficult by the lack of information available
There are no books on Wix, so your resources are limited to the Wix tutorial, which is detailed and lengthy but still doesn't cover much beyond basics, and blog posts you find via Google. Granted, there are many good blog posts which detail how to accomplish specific things, but unless you don't have deadlines to meet, you probably can't afford to sit and research how to do specific things in Wix for days at a time. Personally, I found myself doing this way too much for Wix to be a feasible solution (again, unless you only need a simple installer)
Ultimately, in my case, we had existing installers which were developed with InstallShield and we are simply able to be productive quicker with it. InstallShield also has its own scripting language which has pretty good documentation too.
Another big plus for me was that InstallShield eases the pain of multiple instances (try searching for how to do this with Wix and you'll get an idea of what I'm saying) and upgrading/patching. I was able to accomplish both of these (especially multiple instances) in a fraction of the time with InstallShield than what it took to accomplish in Wix.
My advice would be to choose based upon your time constraints/deadlines/commitments, complexity of your installer, and maturity of your product. Wix requires LOTS of research for things InstallShield provides a fairly quick way of doing. This can be even more painful if you have a mature product versus a fairly young product.
Hope this helps.
To address Samuel's points above....
I've created a project on CodePlex that is called IsWiX that addresses the democratization issue. You use it with WiX to create Merge Modules and then consume the Merge Modules with InstallShield to get the best of both worlds. This allows a setup guy to use InstallShield and dozens of my developers to use IsWiX/WiX. The XML can still be marked up with additional metadata so we aren't restricted in what the modules can describe.
InstallShield has a stand alone build engine that integrates with MSBuild/TFS and provides an automation interface. There is no advantage for WiX here.
InstallShield is a text file also. It's an uglier DTD format but IsWiX solves that problem by abstracting the frequently changing portions from the rarely changing portion of the installer.
I highly encourage the use of DTF with InstallShield. After all a Type 1 Exported Function is the same to any MSI based tool.
InstallShield has a direct editor which shows you the underlying tables. This is actually closer to the metal then WiX which uses an XSD based DSL to output the metal.
All in all, there are really good things about WiX AND InstallShield and I use them together to create extremely complex installers.
PS- IsWiX put a lot of thought into hashing and sorting to solve branch merge problems. ( We use Base Clearcase on dozens of branches so this was very important to us. )
+1 to Samuel's answer. As for the steep learning curve... if you don't understand the way the underlying technology (Windows Installer) works, you'll have problems with the support of your installation, either InstallShield or WiX you choose. But WiX encourages you to learn Windows Installer to use WiX abstractions correctly.
I personally started my setup project (a huge web application) with InstallShield, but I recently moved to WiX and I'm happy about it. The key points of my choice:
it is free
it is XML (no more pain diffing and merging)
it is friendly to NAnt
it does exactly what you instruct it to do (no more and no less)
Hope you find this information useful.