When you install your product locally, all the needed files are stored in the machine.
When you set the features to Advertise, files will be installed locally when the user launches the application.
What happens then when yo set the features to "run-from-source"? I Googled it and was only able to find this: http://msdn.microsoft.com/en-us/library/aa367538%28v=vs.85%29.aspx
Thanks!
This is a rarely used feature of Windows Installer and I don't normally reccomend using it. It was invented back in a day when hard drives were small and the thought was you 'advertised' ( pretend install aka install source ) a feature and that when the user clicks the shortcut it would go to the source and finish the installation of the feature ( aka install local )
It just adds a lot of complexity to your servicing model. It's not worth it IMO.
When placing all installation files next to the MSI (similar to advertised installation), you can install features from source. This means that all files in these features will be used from the MSI location (they are not copied in the target folders during install).
Running from source can be used when the installer remains permanently on the target machine. So the application can use the installer directly instead of using installed files.
Related
I've cloned it but I didn't find any .exe file, Nor do i see it in programs list in Control Panel of windows. I'am a bit confused as to what cloning means. I know that there is direct download .exe file on vim.org website. Its for sure that I'am beginner for all these. Please help. Thanks for the help in advance.
reading the "installation" section found in the README.md of the vim repo, you can see the filenames containing the instructions that will help you with the installation, depending on your OS.
README_ami.txt Amiga
README_unix.txt Unix
README_dos.txt MS-DOS and MS-Windows
README_mac.txt Macintosh
README_haiku.txt Haiku
README_vms.txt VMS
So, for the full information I suggest you go to those files, or go to the vim website where there is also good information about the installation.
Anyway, I will briefly explain below the information that those files and the vim website say for most common operating systems
If you're on Unix:
git clone https://github.com/vim/vim.git
cd vim/src
make
If you're on Mac
The Macintosh binaries are not on the Vim ftp site. They are produced by a few Macintosh lovers. Often they lag behind a few versions.
MacVim has more a Mac look and feel, is developed actively and most people prefer this version. Most of MacVim was made by Björn Winckler.
MacVim can be downloaded here: link
Or if you prefer, here is the MacVim homepage.
If you're on Windows:
The next instructions were copied from here.
Option A: Using the self-installing .exe
Go to vim.org/download.php and click on self-installing executable (or just click here) and follow the prompts.
Watch out for:
When an existing installation is detected, you are offered to first remove
this. The uninstall program is then started while the install program waits
for it to complete. Sometimes the windows overlap each other, which can be
confusing. Be sure the complete the uninstalling before continuing the
installation. Watch the taskbar for uninstall windows.
When selecting a directory to install Vim, use the same place where other
versions are located. This makes it easier to find your _vimrc file. For
example "C:\Program Files\vim" or "D:\vim". A name ending in "vim" is
preferred.
After selecting the directory where to install Vim, clicking on "Next" will
start the installation.
Option B: Using .zip files
Go to the directory where you want to put the Vim files. Examples:
cd C:\
cd D:\editors
If you already have a "vim" directory, go to the directory in which it is
located. Check the $VIM setting to see where it points to:
set VIM
For example, if you have
C:\vim\vim82
do
cd C:\
Binary and runtime Vim archives are normally unpacked in the same location,
on top of each other.
Unpack the zip archives. This will create a new directory "vim\vim82",
in which all the distributed Vim files are placed. Since the directory
name includes the version number, it is unlikely that you overwrite
existing files.
Examples:
pkunzip -d gvim82.zip
unzip vim82w32.zip
You need to unpack the runtime archive and at least one of the binary
archives. When using more than one binary version, be careful not to
overwrite one version with the other, the names of the executables
"vim.exe" and "gvim.exe" are the same.
After you unpacked the files, you can still move the whole directory tree
to another location. That is where they will stay, the install program
won't move or copy the runtime files.
Change to the new directory:
cd vim\vim82
Run the "install.exe" program. It will ask you a number of questions about
how you would like to have your Vim setup. Among these are:
You can tell it to write a "_vimrc" file with your preferences in the
parent directory.
It can also install an "Edit with Vim" entry in the Windows Explorer
popup menu.
You can have it create batch files, so that you can run Vim from the
console or in a shell. You can select one of the directories in your
$PATH. If you skip this, you can add Vim to the search path manually:
The simplest is to add a line to your autoexec.bat. Examples:
set path=%path%;C:\vim\vim82
set path=%path%;D:\editors\vim\vim82
Create entries for Vim on the desktop and in the Start menu.
That's it!
Vim is open source software, and its source code, i.e. all the technical files that make up Vim is (nowadays) hosted at GitHub.
Cloning that repository means you'll download all of those files to your computer (and with Git as the underlying revision control system, you'll even get the full history of all changes ever done). As Vim supports a very big set of very diverse platforms (Windows, Linux, Mac, ...), the repository itself does not (and should not) contain pre-built binaries, nor a full installer that most users expect to run. So, unless you have the intention to actively contribute to Vim by submitting bug fixes or enhancements, you don't need to clone or do anything with GitHub. If you do want to get technical, src/INSTALLpc.txt contains the instructions for building Vim on Windows. This includes choosing a compiler, installing it and the required dependencies, configuring the build, building, and then finally copying the files to a permanent location on your PC, either manually or by building and then running an installer.
For plain passive consumption of Vim (which is rewarding in itself, but may even lead you to eventually also programming it), the Downloading Vim page on vim.org has all the information that you need, with links to the most popular installers right at the top.
a word on versions
For a casual user, using the latest stable version is recommended; this is 8.2 right now; gvim82.exe is a corresponding installer for Windows. This offers the best compromise between stability and latest features. In the case of Vim, expect a new release roughly every year.
You'll also find development builds (something like 8.2.0740); these usually function as well and have the very latest features under development, but often are less stable. I would use these only if you really need a leading-edge feature, or want to report a bug. You should then probably update very frequently, and from there it's only a small step to actually cloning the repository and building everything on your own!
I have been running berrybrew on Windows
(here's the home page and GitHub repository).
I'm having some trouble with it and I want to uninstall and reinstall it, but I can't figure out how to do that.
I am hoping it is as simple as just deleting the directory where it was installed and C:\berrybrew, which is where it seems to keep files, but I don't know for sure. The instructions contain installation instructions, but no uninstallation instructions.
Disclaimer: berrybrew author here...
To uninstall and return your system back to default:
berrybrew off
berrybrew unconfig
then delete the directory you downloaded it to, as well as the installation directory (by default, C:\berrybrew)
Edit your PATH variable to remove any entries that start with C:\berrybrew (or the base install directory if you've changed it from the default). One of the path entries will point to C:\berrybrew\bin, and there may be one more that points to the currently in-use Perl installation (also under C:\berrybrew\...). Technically speaking, there shouldn't be any after the first two commands are run, but one should always verify
Essentially, there's really nothing to "uninstall". It comes down to removing $ENV{PATH} ie. specific environment variables that point to a) berrybrew.exe binary itself, and b) the Perl installation that you last used.
I will update the documentation to provide more clarity in this regard.
The Code documentation suggests that it is added to the PATH during installation, but that did not seem to work for me (at least not in PowerShell). Where is it installed such that I can add it myself?
The install path is C:\Users\username\AppData\Local\Code
C:\Users\username\AppData\Local\Code\bin is added to the PATH by the installer, but it might be that tools such as PowerShell will pick this change up only until after a log off/log on or a restart
On macOS, VS Code these days seems to have a Command Palette (shift + Cmd + P) command to install it to the path called "Shell Command: Install 'code' command in PATH".
It seems that a good old restart of the box fixed the issue. Interestingly, merely restarting PowerShell or logging out and back in didn't fix it.
Modern Software Installation.
Many of the larger software packages have finally caught-up with the times. Make sure the correct choice(s) are made during the software download and during the software installation.
Most individual PC users are the sole users of their PCs. Yet many software packages have always defaulted the installation processes to assume otherwise. This is why so many software packages install to a path that includes C:\ .... user\ ...
But most of us individual PC users don't want the software installation including a path that involves using the ... user\ ... path. And instead we want the software installed into the default C:\ path without the "user name".
Some of the most common software installation packages are becoming available for the individual PC user and these packages install on the PC in our preferred path - (not involving a path through the ... user\ ... ).
And if there is not a separate download package for the individual PC user, then during installation make sure to closely read each step which will often now include a checkbox of whether the installation is for a "user" or for "all users". Select all users.
We have a windows app and we were using Wise for deployment. Recently we switched to InstallAware and though it has some good points we are facing some issues. Can someone recommend another deployment and packaging app? We are a small company and we do not have a dedicated staff for packaging etc. Also our package includes SQL server express installation and we would love to have the simplicity of such includes as is in IA.
How about NSIS or InnoSetup? They're both widely used, and not that hard to use. (If you choose InnoSetup, also download ISTool, it's a lot easier than writing the script file manually.)
We've used NSIS several times, both for full regular desktop installers, and for small, silently installing patches. It's easy to write a basic installer, especially if you use HM NIS Edit which acts as a wizard and IDE for NSIS. Because it's scriptable, you'll be able to check if SQL Server Express is already installed - if not, it can be installed as part of your installer process.
I have never used anything but Windows Setup and the setup projects that come with Visual Studio. Do you have any unusual requirements that prevent you from doing that?
I assume your requirement as follows,
You are using wise package studio to create\customize the application to create MSI and these msi package will be deployed or installed to your environment.
My question is : How many desktops \laptops are their in your company (Infrastructure)
Solution to your question based on my assumption:
At present Admistudio is the best product to replace the Wise and you can use Installshield repackager to create or customize the applications.
Install anyware is used to customize the Dll files (Build and release method) and create custom actions in that build file and build it to MSI
Installshield Repackager is used to create MSI from Exe files and also customize existing MSI using transform file (no need to modify existing MSI instead we can create MST file to MSI and perform the customization to MST file and same file will be applied while deployment.)
Please let me know if you need further assistance.
I've got a number of batch processes that run behind the scenes for a Linux/PHP website. They are starting to grow in number and complexity, so I want to bring a small amount of process to bear on them.
My source tree has a bunch of cpp files and scripts, organized with development but not deployment in mind. After compiling all the executables, I need to put various scripts and binaries on a cluster of machines. Different machines need different executables, scripts, and config files for their batch processes. I also have a few of tools that I've written that belong on every machine. At the moment, this deployment process is manual and error prone.
I'm guessing I'm just going to end up with a script that runs at the root of the source tree and builds a smaller tree of everything necessary for any of the machines. Then, I'll just rsync that to the appropriate machines. But I'm curious how other people are managing this type of problem. Any ideas?
There are a several categories of tool here. Some people use a combination of tools from these categories. I sometimes use, for example, both Puppet and Capistrano. See Puppet or Capistrano - Use the Right Tool for the Job for a discussion.
Scripting Tools aimed at Deploying an Application:
The general pattern with tools in this category is that you create a script and/or config file, often with sets of commands similar to a Makefile, and the tool will ssh over to your production box, do a checkout of your source, and run whatever other steps are necessary.
Tools in this area usually have facilities for rollback to a previous version. So they'll check out your source to releases/ directory, and create a symbolic link from "current" to "releases/" if all goes well. If there's a problem, you can revert to the previous version by running a command that will remove "current" and link it to the previous releases/ directory.
Capistrano comes from the Rails community but is general-purpose. Users of Capistrano may be interested in deprec, a set of deployment recipes for Capistrano.
Vlad the Deployer is an alternative to Capistrano, again from the Rails community.
Write your own shell script or Makefile.
Options for getting the files to the production box:
Direct checkout from source. Not always possible if your production boxes lack development tools, specifically source code management tools.
Checkout source locally, then tar/zip it up. Use scp or rsync to copy the tarball over. This is sometimes preferred for something like an Amazon EC2 deployment, where a compressed tarball can save time/bandwidth.
Checkout source locally, then rsync it over to the production box.
Packaging Tools
Use your OS's packaging system to generate packages containing the files for your app. Create a master package that has as dependencies the other packages you need. The RubyWorks system is an example of this, used to deploy a Rails stack and sample application. Then it's a matter of using apt, yum/rpm, Windows msi, or whatever to deploy a given version. Rollback involves uninstalling and reinstalling an old version.
General Tools Aimed at Installing Apps/Configs and Maintaining a Set of Systems
These tools do not specifically target the problem of deploying a web app, but rather the more general problem of deploying/maintaining Apps/Configs for a set of servers, or an entire company's workstations. They are aimed more at the system administrator than the web developer, though either can find them useful.
Cfengine is a tool in this category.
Puppet aims to improve on Cfengine. It's got a learning curve but many find it worth the time to figure out how to do the configs. Once you've got it going, each box checks the central server periodically and makes sure everything is up to date. If someone edits a file or changes a permission, this is detected and corrected. So, unlike the deployment tools above, Puppet not only puts files in the right place for you, it ensures they stay that way.
Chef is a little younger than Puppet with a similar approach.
Smartfrog is another tool in this category.
Ansible works with plain YAML files and does not require agents running on the servers it manages
For a comparison of these and many more tools in this category, see the Wikipedia article, Comparison of open source configuration management software.
Take a look at the cfengine tutorial to see if cfengine looks like the right tool for your situation. It may be a little too complicated for a small website, but if it is going to involve more computers and more configuration in the future, at some point you will end up using cfengine or something like that.
Create your own packages in the format your distribution uses, e.g. Debian packages (.deb). These can either be copied to each machine and installed manually, or you can set up your own repository, and add it to your list of sources.
Your packages should be set up so that the scripts they contain consult a configuration file, which is different on each host, depending on what scripts need to be run on each.
To tie it all together, you can create a meta package that just depends on each of the other packages you create. That way, when you set up a new server, you install that one meta package, and the other packages are brought in as dependencies.
Although this process sounds a bit complicated, if you have many scripts and many hosts to deploy them to, it can really pay off in the long run.
I have to roll out PHP scripts and Apache configurations to several customers on a frequent basis. Since they all run Debian Linux, I've set up a Debian package repository on my server and the all the customer has to do is type apt-get upgrade and they get the latest version.
The first thing to do is get all these scripts into a source control repository (svn or git are good) so that you can track changes to these scripts over time.
If you are interested in ruby, check out Capistrano, it is well suited deploying things to multiple machines in a cluster, and is fairly easy to set up. It can read files directly from your version control system.
Puppet is another tool that can be used in this situation. It is similar to cfengine - you create a model of the desired deployment and Puppet figures how to get the environment to this state.