i have been using Installshiled for installing this SDK, but this is giving us lot of troubles sometimes with users accounts etc...but my SDK has few com components and few regular dlls and help files.
my tasks are very few and i don't think i need to use this costly software
Installation:
1)copy the dlls into a specific folder
2)register the COM dlls
3)Add few registry entries
4)copy help files
uninstall:
1) unregister all COM dlls
2) delete all dlls including regular dlls
3) remove registry entries
4) delete help files
can anyone suggest any free installer where i can do the above things easily
This pretty routine stuff - all installers do this basic stuff. If it's WiX (which is free), use Heat to extract the registration, install the files, and the rest just works. Your question is too broad to answer, so here's the WiX tutorial.
http://wix.tramontana.co.hu/
Installs are generally more complicated and more work than people expect.
Apart from WiX maybe the Visual Studio you use will have either InstallShield LE or the new VS 2012/2013 installer extension.
Related
How can I create the .msi package for visual Basic 6.0. I tried to search internet, but found only how to create the installer package for .net. I want it for Visual basic 6.0.
Any help will be appreciated.
Inno Setup is a very good (free) installer for VB6, and if you must have an MSI you can find a converter to wrap an Inno EXE with an MSI wrapper.
I recently went through the same struggle as you. Your best option for VB6 is to purchase a third-party package to create the msi. A google search for "Windows Installer" or "MSI Installer" should get you started.
Here is a discussion on the various options:
What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc
Microsoft's native way of creating .msi files in VB6 was by using the Visual Studio Installer Add-in. That's what I used back in the day.
You might still be able to find it online somewhere. I googled around looking for a download for some time and wasn't able to find one.
The other option that might do in a pinch is the package and deployment wizard, although I always found it to be rather hard to work with. If you're not careful to avoid installing certain protected DLL's you can get caught in serious DLL Hell. I generally used the Installer add-in.
Jim Mack's solution is increasingly popular as support for VB6-specific tools wanes away into nothingness.
Currently I'm distributing a software product that includes three merge modules:
Microsoft_VC80_CRT_x86.msm
ATL.msm
policy_8_0_Microsoft_VC80_ATL_x86.msm
Some customers use packaging technology that doesn't like these MSM files (I think because they have technical problems with them writing to WinSxS). Can I just distribute the dll files directly into my application's Program Files folder, and if so which dlls do I need? Is it just atl80.dll?
Your alternative is to run the VC_redist.exe for that version of Visual Studio, run it from the bootstrapper with whatever setup tool you're using.
I don't know what you mean about packaging technology. The only way merge modules (msm files) can be installed is to add them at build time to an MSI file build. In other words, the only packaging technology that's relevant is Windows Installer and MSI files. So you need to find out exactly what this issue is. Everyone uses the merge modules or the VC_redist.exe because it's the only reliable thing to do.
One issue with doing it yourself in an unofficial way is that Windows Update can't find them (and that applies to static linking to). So when Microsoft applies a security fix to those Dlls then you are leaving your customers vulnerable.
I have an excel plugin that I want to distribute as a single installation package, preferably MSI. Is there an easy way of doing this?
I've created many office addin installers for customers and basically have it down to a template starting point. For pointers see my blog article:
VSTO 4 ( 2010 ) Lessons Learned
ClickOnce is still technically used but the |vstolocal tag is used to run from source and not deploy to the click once cache. Basically you get a per-machine MSI experience and a setup.exe that makes sure all of your prereqs are present.
The best way is to create an MSI installer from scratch, not try to wrap your ClickOnce package. Any MSI package, no matter the tool you use to build it, can install the addin, as long as it install the files and registry entries required, as documented in the following MSDN article.
If you are looking for a free tool and have some time on your hands to learn using it than WiX is the best.
I'm developing a Visual Studio application with WPF, but right now is the moment where I have to choose my installer.
I need my project to be able to write on the GAC and on registry, but I'm not sure if I should use Visual Studio installer or Wix... I can't find on Google information that says exactly the differences between both of them.
I found that Wix is more complete, but I can't find any article that specifies real differences between one or another...
Can anyone help me to find more specific information or to choose between both of them?
EDIT: Sorry, I specify:
I'm using Visual Studio 2010 professional.
The end product is the same, a windows installer msi.
It's just different how you get there. With the old vdproj there wasn't much other than setting up files to be copied and registry keys as far as I remember. Anything else and you would have to create a custom action in C++ or VBS, not a particularly easy task if you are .net developer.
However with the advent of Wix there are a lot more in-built custom actions which enable you to create a rich installation experience and if you need to create your own custom action you can use .net. Also it is much easier to create a bootstrapper which can install dependencies along with your msi as well as being able to create a front-end in WPF.
As #nvoigt said the old vdproj type is not supported in VS2012 and it also cannot be built by a build server without doing some nasty setup (you have to install VS).
All in all there really should be no question of what to use, Wix is the way forward.
Caveman_Dick wrote:
"Anything else and you would have to create a custom action".
And that in a nutshell is the difference. Visual Studio Deployment Projects heavily abstracts you from the underlying windows installer and seals away a great deal of it's ability. This goes against the very design of Windows Installer which is supposed to be a declarative, transactional programming model.
Take installing a Windows Service as an example? Windows Installer has the ServiceInstall table. VDPROJ fails to expose this so you are off writing brittle custom actions resulting in a less elegant and less robust installer.
WiX on the other hand is a very thin abstraction. It's all about XML XSD elements and attributes that represent the underlying Windows Installer table data. The build process simply transforms the XML to SQL tables. If MSI can do it, WiX can (99%) do it.
VDPROJ was a horrible mistake and Microsoft has finally owned up to it and killed it. Now WiX doesn't have UI designers ( I've written one on CodePlex though) so you might also want to consider InstallShield Limited Edition (FREE).
Using a combination of ISLE and WiX I can get the best of both worlds.
With Setup projects no longer shipped with current versions of Visual Studio, you might want to use Wix. Otherwise, you will have to write it again once you switch to a current version of Visual Studio.
I was wondering if anyone knows how easy it would be to convert an install project created with the standard visual studio 2010 install project to a WIX project.
This install project has a custom actions dll as well. I read about Heat but I'm not sure what it does.
I'd describe the process more as refactoring then converting. For example, the custom actions you are using very well may not be needed. Often times CA's are used to do things that MSI supports natively such as installing a windows service. (Reinventing the wheel.)
I approach situations like this with:
1) Examine the VDPROJ and custom actions for intent.
2) Possibly use Dark to decompile the MSI to wxs files.
3) Reauthor the WiX as cleanly as possible.
I've done this many times so it's 'easy' for me. If you don't have the underlying Windows Installer experience and/or WiX experience, it'll be far more difficult yet also rewarding in terms of building your skillset.