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.
Related
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.
I have a .MSI installer project created in vs2010. This .MSI includes many *.msm (merge module file). Is there a way to select specific *.msm based on different windows platform(ex: xp, win7, vista..)during installation?
For instance, if the target platform to install this .MSI is winXP, my .MSI will know what .msm to choose instead of choosing all .msm during installation.
BTW, is there a way for .MSI to access a specific *.dll which resides in .msm ? Again, for instance, if the .MSI project includes a .msm and this .msm includes many *.dll, is there a way to select a specific *.dll in .msm during installing this .MSI ?
my main purpose is to have my .MSI knowing what .dll/.msm to use under different windows platform during installing my .MSI.
What you basically need is to assign each merge module to a new feature and set install conditions on that feature. I don't think this is possible with VS 2010 however, but there are some commercial setup authoring tools that can do it.
Merge modules (.msm) are similar in structure to a simplified Windows Installer file (.msi). A merge module cannot be installed alone, it must be merged into a .msi file. The best alternative is to obtain a freely distributed merge tool or purchase one of the merging tools available from independent software vendors. You can then use the functionality provided by Mergemod.dll.
The intended use of merge modules was to provide a standard method for developers to deliver shared Windows Installer components and setup logic to their applications. Merging is therefore something typically done by the author of the installation package prior to deployment. Trying to determine and perform the correct merge when the application is being installed does not seem like the best approach.
You could instead create a separate .msi for each target platform. Merge the appropriate .dll into each package. Then include logic in your setup application to check the user’s system and then install the correct package.
As was suggested by the previous answer, you could merge all the .dlls into a single installation package which you have authored such that the installation of certain features and components are conditional upon Operating System Property Values .
You can consider Using Transitive Components in your package. The typical use for transitive components is to prepare a product to reinstall during a system upgrade. The author of the installation package specifies those components that need to be swapped out during a system upgrade as having the transitive attribute. When the user later upgrades the system, the product must be reinstalled. Upon this reinstall, the installer removes the earlier components and installs the later components, without having to install the entire product. This might serve your scenario well if you expect your users to upgrade their systems.
I have made a program in VS2010, written in C#. It uses extra libraries and databases.
My teacher wanted to test it a few days ago, so I had sent him the setup file which publishing the project created. This setup didn't work because there were "files missing".
I then just sent him the whole published map.
Which files do I need to include for a published program to install and work on another pc?
It depends on several things. Usually the contents of the bin\debug or bin\release should be sufficient providing your teacher has the same version of .Net installed. One thing it depends greatly on is whether or not you are using any libraries outside the core .Net. If not, then the bin directory should be sufficient. If you are using third party libraries and those libraries are GAC'ed on your machine then VS will not copy them to the bin directories.
This is a very similar question: Dependencies and references - What exactly should I reference?
Greetings!
I have a solution in VS2010 that defines 3-4 individual applications.
These 3-4 apps are individual (but related) components that I need to have individually installed on our production servers during deployment. I toyed with using WIX mondo to generate a multi-feature WIX installer, but found that it would be more beneficial to allow that these applications be able to be installed individually as well as via a single-source for all of them, preferably configurable to choose which to install during an installation.
I noticed that there is a WIX project type called "Bootstrapper Project" but I cannot find much documentation around it on the web, and do not know if it is a project type that will actually assist me in creating a deployment installation bootstrapper for my projects. (i.e. a setup.exe file that will install, one after the other, each project as either defined in the installer, or optionally selectable via the installer as it runs)...
what is the best method to do this within WIX, using pre-existing WIX installers for individual programs?
In Wix, the support to create a bootstrapper is through a tool called "Burn". Burn has been pushed out to v4.0 (or version 3.6). So that isn't much help.
You can use an open source tool like dotNetInstaller: http://dotnetinstaller.codeplex.com/
Here is an overview on how to create a setup installer that checks for the .NET Framework (which in and of itself is not very useful, but shows you how to work with dotNetInstaller):
http://www.lostechies.com/blogs/gabrielschenker/archive/2010/05/19/creating-a-bootstrapper-with-dotnetinstaller.aspx
Or you can follow the instructions here: http://msdn.microsoft.com/en-us/library/ms165429(v=VS.100).aspx
And use the Bootstrapper Manifest Generator here (although there appear to be 64-bit issues): http://code.msdn.microsoft.com/bmg
Why should one go for Windows Installer XML (WiX) when we have in built .net MSI installer?
It would take me hours to rant about everything I hate about VDPROJ. I won't because in my (expert) opinion it's already settled law that VDPROJ sucks. If your install is so simple that you haven't noticed any problems, then be my guess and stick with it. But if you already find yourself fighting the tool trying to get it to do things it doesn't do, then take my advice and dump it fast for WiX.
10 things I hate about VDPROJ
No MSBuild Support. Sure, you can call devenv from the command
line but it's not as good.
No exposing of the critical concept of
a component. Every file/reg key is a keyfile of it's own component.
No effective way to fully exclude automatic dependency scanning.
Shortcuts are always Advertised
No way to describe a service.
No way to describe many things which leads to overuse of custom
actions.
No way to fine control the scheduling / execution of
custom actions. Too abstracted.
Abstraction is wrong. Deferred
CA's are scheduled with Impersonation which breaks on Vista.
Various limitations lead you down a path of massaging the built MSI
during postbuild to get around all the limiations. Results in a
very poor build automation hacks.
Merge Module directory tables
are authored incorrectly.
100 other things suck that I'm not
remembering right now.
The introduction of WiX tutorial gives the basic idea about WiX advantages comparing to other setup development tools (including VS setup projects):
declarative approach
unrestricted access to Windows
Installer functionality
source code instead of GUI-based
assembly of information
complete integration into application
build processes
possible integration with application
development
support for team development, both
in-house and third-party
free, open source
Hope this helps.
Visual Studio deployment packages can only be built by visual studio. They cannot be built using plain MSBuild command lines, which makes them less than ideal for e.g. build servers.
All the above answers have included most of the annoying features of Visual studio setup projects (.VDPROJ), one thing that most people have missed.
.VDPROJ file format is such that, and if we make a small
change to one single entry it completely rewrites all the entries
within which makes it impossible to merge changes from 2 different
branches.
Some of us don't want to use / can't use the .NET installer.
Some of us don't want to have to install Visual Studio to distribute a program, written in, say, Borland Delphi. WiX and .NET have nothing to do with one another.
WiX provdes a much more complete feature set than the .NET installer.