Some programs installed by Chocolatey have the feature to self-update. Examples are VS code and PyCharm. Will there be any side effects if one uses choco to upgrade the software after the software has done the self-update?
I am using Windows 10, python 3.8, anaconda distribution.
If by "side effects" you mean try to download when they shouldn't, or download and revert to outdated files that they shouldn't, the answer is no. They don't just retrieve the packages, they manage them.
handling dependencies during installs and upgrades is the main purpose for package mgrs. to exist. They manage stuff like that so developers do not need to. Otherwise, building any type of project with current methods and standards would be extremely challenging so you don't have to.
Chocolatey, like most package mgrs., runs a 2 step process as a result of the upgrade command. First it checks for newer versions, If there are none, it does nothing. The convention for nearly all automatic upgrade processes is the same. Because of this, either one only retrieves when it needs to.
Companies like IntelliJ and Microsoft usually have relatively robust Deployment schemes, regardless of the method. If a package manager was going to break (or breaking) their automatic update, they would either fix the compatability issue or choose to forgoo the install method. So long as you verify your sources before downloading anything from anywhere, you should be ok.
Side Effects
Side effects should not be present, as it depends on whether the application also successfully overwrites the files, which should be the case.
If PyCharm executes the self-update and the Chocolatey package manager updates the PyCharm application at the same time, errors may occur and the files may not be overwritten successfully.
1. Solution — Deactivate Self-Update
You can manually disable the self-update option integrated in the application.
If the application does not allow you to disable the self-update option, try disabling the update service via the Services application.
2. Solution - Deactivate the Update Service via Services
The Services application allows you to make configurations of the services developed by the respective application.
It is strongly recommended that you create a restore point before making any changes to services.
If you make a mistake that cripples your computer, you can use the restore point to perform a system restore and undo the changes.
If you have disabled the wrong service and lost access to the computer, try booting into safe mode to change the service back.
Configure the update service via the Services application and set the status to Disabled.
Example: Deactivating the Brave Update Service
Related
I'm building an Azure Function that depends on another project I'm building that's on Nuget. Everytime I update the nuget project, I publish the updates to https://nuget.org. Then I wait for the validation. Then I update my other project to pull the latest version. It's really annoying waiting for the validation... sometimes a couple times per day.
Is there a way I can use my nuget package without waiting for validation to complete? Keep in mind I'm developing both packages side-by-side on the same laptop.
There are three levels to doing this efficiently:
Whenever possible, do local development within the same solution using project references instead of package references. As zivkan said in the comments, this "inner loop" is fastest. Do this until you need to test the package itself (e.g., making sure it installs correctly).
Use a local NuGet feed if you are able to test the package without hosting it on a cloud repository. (nuget add my-package.1.0.0.nupkg -source C:\somedirectory\localnuget) Visual Studio and the nuget CLI can both be configured to look in a local directory, which makes the testing loop much quicker.
If your Azure functions must get the package from a real hosted repository, use MyGet (or if you want to DIY it, Artifactory) to host your own NuGet feed. Publishing your packages to that feed and consuming them from your function should be faster than waiting for official verification on nuget.org.
I have created MSI using WIX 3.11. I have made some customization to the Installer to install the application in a custom folder. I am also writing Install path to registry value under HKLM\Software.
I am reading registry value in batch file for one of my use-case.
Installation is successful and the application is running fine.
But while uninstalling, I am facing below issue -
Uninstall window pops up with the message - The following applications should be closed before continuing the Install: [MyApplication]
In uninstall log while removing the service, I see below error - Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.
If I remove the service manually, no errors can be seen and the service is getting deleted. Not sure why Uninstall is failing.
Please shed some light on this.
Stop Service Before Uninstall: In the compiled MSI, what entries do you have in the ServiceControl table? You need to stop the service before its executable is deleted. See WiX service installation sample linked to below.
Failing Custom Action: It is also possible that you have a custom action which tries to run a batch file that has already been uninstalled when you try to run it. This can be a custom action that should not run on uninstall (conditioning is wrong), or you have sequenced it incorrectly so the batch file is gone from disk - courtesy of the uninstall - before the custom action can run successfully. You need to move the custom action earlier in the installation / un-installation sequence or condition it better so it never runs on uninstall. Both issues are very common. Be aware that it is common to fail to condition custom actions so they run unexpectedly. Very often they run during major upgrade uninstalls undesirably.
Batch Files CAs: For what it is worth - and no offense: using batch files in custom action is an MSI anti-pattern in my opinion. There is basically zero error handling and hence no management and recovery from error conditions. And generally no MSI rollback support. C++ custom actions are best in my view (minimal dependencies, good debugability, full featured language, large down-to-the-metal API). Just so it is mentioned. It all depends how large your distribution is. For in-house appliations one can get away with more than for truly global package distribution. This has to do with the complexity of deployment (see section a bit down the page). There are so many error sources.
WiX Service Installation: Maybe see this hands on WiX-markup sample from Rainer Stropek: WiXSamples - github.com/rstropek. Please check
the ServiceControl element.
Common MSI Problems: I hate to "pitch" this content. It is essentially the things you can't easily find in books - and for good reason. Some rules of thumb and opinions in a chaotic form, but here it is if you want to check it out: How do I avoid common design flaws in my WiX / MSI deployment solution? Just honest opinions and practical advice - no claim to be "right", but it should help setup reliability. Hopefully.
When ever there is an update patch of files that have to be replaced with the existing files and if one of the files is being used by any of the processes, then a file in use dialog box pops-up.I wanna avoid that dialog box and get that file queued up for installation so that it can be installed at the time of system reboot.
I have read that the queuing the files for update at the time of reboot is the inbuilt functionality of windows installer.
Can someone suggest me the way to remove that FileInUse Dialog box.
I tried setting up the "MsiRMFilesInUse" property to "0" but it didn't work.
"Short" Answer
Essentially: you could 1) run completely silently (suppresses the files-in-use dialog), 2) shut down locking
applications gracefully (application update to allow graceful shutdown - with or without restart manager support), 3) ensure proper service control (if dealing with services), 4) force-kill
running processes (the "sledgehammer-approach"), 5) abort setup if locks are detected, 6) require logoff before deployment, 7) install to a new folder for each version (side-by-side install), etc...
Below is a little drill-down of files-in-use issues and the Restart Manager - intended as a quick review for files-in-use and reboot issues.
In terms of your actual problem. I wouldn't mess with the FileInUse dialog(s). It won't really solve your problem. Maybe consider these pointers:
Services: If you are installing services and they trigger files-in-use issues, please see section on services towards the bottom to determine if you can improve your setup's logic.
Silent Mode: Running your setup in silent mode would be an obvious way to suppress such files-in-use dialogs, but then you have to suppress automatic reboot, or the system will spontaneously reboot without warning. Details below.
Policy: Please check if the DisableAutomaticApplicationShutdown policy is enabled on your box / standard PC configuration. See details below.
Registry location is: HKLM\Software\Policies\Microsoft\Windows\Installer.
I am not sure if enabling this policy will make the files-in-use dialogs disappear.
Restart Manager Compliance: Maybe check if you should update your application to heed the design of the Restart Manager feature - to allow for auto-magic and problem free upgrades by applications shutting themselves down gracefully (provided you are dealing with binaries that you can actually change yourself - in other words: you have the source code). Lots of details below.
"Setup Overkill": If you deem it safe to kill your application without mercy during upgrades, see section on this below.
Graceful Shutdown Custom Action: If you make your application capable of graceful shutdown (restart manager-style), then you can trigger such a shutdown yourself as well (easiest for user context processes) via an immediate mode custom action (in case Restart Manager is disabled by policy - look out for timing and timeout issues though - especially for silent running - "deadlock").
Side-By-Side Installation: some details below. Some companies decide to install applications truly side-by-side so there are no file overwrite issues with their new deployments (old versions uninstall may still trigger required reboots though).
I suppose you could also abort the install if locked files are detected, or you could require users to log off before the installation is run - if you have a distribution system.
Please at least skim the rest of the answer for more details and context.
Restart Manager
Your applications and services should be prepared to be shut down by the Restart Manager and save user data and state information that are needed for a clean restart. This requires updates and changes to the application / service to adhere to standards for shutdown and restart of the application.
The Restart Manager: is a new C-style API available beginning with Windows Vista and Windows Server 2008. Restart Manager consists of a single DLL that applications can load to access the Restart Manager API. The idea is that the Restart Manager will auto-magically shut down and restart your applications during installations / updates, by having the application / service follow a set of guidelines:
Guidelines for Applications - (the crucial tech-read)
Guidelines for Services
In essence: The whole idea is basically to prefer restarting applications rather than restarting the OS - and also to avoid reboots in general.. To that end: 1)
Your application calls RegisterApplicationRestart() with a command
line specified for its eventual restart - it "signs up" for restart
management. 2) Your application watches for WM_QUERYENDSESSION
messages and shuts down gracefully saving data in an appropriate way
when told to do so. 3) Then Restart Manager can restart the
application when finished installing (restart can be disabled).
More Technical stuff:
Here is a nice Symantec article on "Files In Use & The Restart Manager".
How do I add support for Windows Restart Manager to my application? (Advanced Installer)
Restart Manager Configuration: There are a number of properties that will affect how the Restart Manager will operate with Windows Installer:
MSIRESTARTMANAGERCONTROL - use the Restart Manager or FileInUse Dialog
MSIDISABLERMRESTART - restart or don't restart shut down applications
MSIRMSHUTDOWN - shutdown, force shutdown or do not force shutdown
When Restart Manager is used, the MsiRMFilesInUse dialog is used instead of the FileInUse dialog to show a list of applications that have locked files.
N.B! The whole Restart Manager feature can also be disabled by policy:
DisableAutomaticApplicationShutdown policy.
Check in HKLM\Software\Policies\Microsoft\Windows\Installer.
Restart Manager behavior with Windows installer
FileInUse
If you don't have the time or resources to implement proper interoperability with the Restart Manager (which is frankly the only sane thing to spend your resources on at this point in Windows's development), then there are a few things that might be good to know:
Silent Install: The first obvious thing to point out is that there will be no FileInUse dialog if you install the setup in silent mode. However, this could trigger a system reboot unless you specify the REBOOT=ReallySuppress property.
Services: Do you install services that you do not properly shut down during upgrade? There are built-in MSI constructs to shut down services during upgrades - the Service Control table.
Used properly, this ServiceControl feature means you no longer have any problems with service executables triggering a reboot to be replaced (barring shutdown problems in the service itself).
This is a built-in MSI constructs and works well when used right. People should not resort to custom actions to install services.
Application Support: Beyond interoperability with the Restart Manager, some application - that have files in use - can shut down gracefully when told to do so.
Some applications shut down properly when sent a command line, for example App.exe -shutdown, despite not having been written to be interoperable with the Restart Manager. Maybe system tray applications that save no data for the user?
This obviously has to be implemented specifically for the application in question - and if you do that, you should use the Restart Manager instead at this point (or additionally, you could have both call the same actual shutdown implementation).
"Setup Overkill": some setups are designed to just kill application processes that are open at the time of installation.
Not ideal, but it can work for certain types of applications that run in the background (OK, it is nuts, but it is done regularly).
Use a custom action or whatever built-in constructs are available in your deployment tool.
WiX: Kill windows service forcefully in WIX. WiX: CloseApplication.
VBScript: Close an application using VBScript.
Advanced Installer: How to detect or stop a process.
Installshield: Kill process. Kill process documentation.
REINSTALLMODE: Do you perhaps use REINSTALLMODE="amus" to force overwrite files during installation?
This can dramatically increase the amount of files in-use and reboot prompts since all files are attempted replaced - and generally unnecessarily so - especially in repair and modify scenarios.
This is particularly true for setups that install services that do not use the ServiceControl table properly to shut down the service before trying to overwrite its binary.
Side-By-Side Installations (SO): adding this for reference, it is beyond the scope of what is "normally relevant". This approach requires quite a bit of technical changes and proper distribution processes to be successful - it is primarily for in-house, core corporate applications (full app control possible) - in my opinion.
New versions, targeting new installation folders (add version number to installation folder?), can generally install without any file overwrite issues (unless any system-shared files are updated - in which case you should split them to a separate pre-requisite MSI - with its own distribution logic - when required - which should be rarely).
Older version uninstall can still trigger reboot requirements as the files can be in-use and not ready to be uninstalled. Obviously.
You can use automatic GUIDs for the setup components - so MSI can keep them tracked separately in a correct fashion. You must generally eliminate all need to set static components (or they must be installed to shared locations and kept static - or updated via a separate pre-requisite MSI when required).
The whole application must be "well behaved" for side-by-side use and installation. In other words not fight over file associations and load all resources properly and manage database connections that could be shared between instances, etc...
You add the version number to the start menu shortcut? Somehow you must be able to differentiate installations and launch the desired version - obviously. The application should be aware of its doppelgängers?
I might consider setting a new upgrade code for each release, in order to decouple the products from one another, and then use the distribution system to uninstall older, legacy versions (as a weekend or monthly batch job?). This is not 100% necessary, it all depends on your scenario. Lots of things can work when planned coherently - obviously.
Applications not suitable for normal side-by-side operation may sometimes be virtualized and sandboxed using App-V (virtual packages) to allow different versions to co-exist on the same box. New challenges.
Some Further Links:
FileInUse or FilesInUse (lots of inside information from a Symantec employee towards bottom)
Terminating process in CustomAction
Restart Manager behavior with Windows installer
How can I stop an .exe on repair, update and delete in wix?
RmGetList() API fails when file is locked using Ez file locker but works with another file locking utility
Suppress an MSI error code
Wix stop service on uninstall/upgrade: prevent "restart popup" (file-in-use situation)
Assuming you are the package author, I would suggest following the norms, which are to use the MsiRMFilesInUse dialog. But if you want to attempt to disable things anyway, start by understanding the guidance for package authors on Using Windows Installer with Restart Manager:
Add the MsiRMFilesInUse dialog box to your package. If the MsiRMFilesInUse dialog box is present in the package, the Windows Vista user running an installation at the Full UI user interface level is given the option to automatically close and restart applications. An installation package can contain information for both the MsiRMFilesInUse dialog box and the FilesInUse dialog box. The MsiRMFilesInUse dialog box is only displayed if the package is installed with at least Windows Installer 4.0 on Windows Vista, and is otherwise ignored. Existing packages that do not have the MsiRMFilesInUse dialog box continue to function using the FilesInUse dialog box. A customization transform can be used to add an MsiRMFilesInUse dialog box to existing packages.
End-users typically run installations at the Full UI user interface level. Basic UI or Reduced UI level installations give the user the option of using the Restart Manager to reduce system restarts even if the MsiRMFilesInUse dialog box is not present. Silent UI level installations always shut down applications and services, and on Windows Vista, always use Restart Manager.
: : :
Package authors can base a condition in the LaunchCondition table on the MsiSystemRebootPending property to prevent the installation of their package when a system restart is pending.
Package authors and administrators can control the interaction of the Windows Installer and Restart Manager by using the MSIRESTARTMANAGERCONTROL, MSIDISABLERMRESTART, MSIRMSHUTDOWN properties and the DisableAutomaticApplicationShutdown policy.
Setting MSIRESTARTMANAGERCONTROL=Disable, possibly removing the FilesInUse and MsiRMFilesInUse dialogs from your package, and optionally tweaking further settings discussed on System Reboots (such as setting the REBOOT or REBOOTPROMPT properties) may have the effect you desire.
If you are not the package author, you are probably asking in the wrong forum. The
DisableAutomaticApplicationShutdown policy sounds like it could do most of what you describe, and would apply to all packages installed on your machine. It is intended for use by systems administrators instead of package authors. Alternately you could create transforms (or specify properties on the installation command line) to effectively alter the package like the package author would have.
Hopefully not repeating too much here, but I'll start by pointing out that the reason for that dialog is to avoid reboots. You didn't say why you want to wait for a reboot instead of using the in-use functionality that lets you avoid rebooting in the first place. It's also unclear about when your next reboot is expected, the issue being that the install of the app is not complete until all the files have been completely replaced and updated. It's not unusual for an incompletely installed app to crash because its current state is some set of old and new files mixed together.
There is no MsiRMFilesInUse property, so setting it has no effect.
The MSIRESTARTMANAGERCONTROL property tells Windows whether to use the older FilesInUse behavior or the new Restart Manager FilesInUse methods of in-use detection. It does not turn off files-in-use behavior detection, it's just a switch between old and new methods. Because the detection methods differ you may see different behavior depending on what files are actually in use (only apps with open windows are detected by the old methods).
You should say which tool you are using to build your MSI file because they have different capabilities. Visual Studio setups have virtually no support for automatic shutdown, except that if you are installing services with installer classes then your Uninstall method could be extended to stop the service at uninstall time. If you are using WiX then there are util::CloseApplication capabilities.
The supported Windows shutdown method is to integrate your apps with Restart Manager, and Stein has links. For services, the "normal" service install with MSI ServiceInstall/ServiceControl takes care of this, but not for Visual Studio setup projects with installer classes.
Finally, create an MSI verbose log and look for in use entries, usually with a 1603 error (the file in use flavor, not the install crashed flavor). You may not need this log if the dialogs tell you the apps that need shutting down, so just focus on a way to get them stopped on an update, because that's a better solution rather than attempting to suppress the default Windows behavior.
I am required to install firebird super server on windows as a service, as a part of my application installation through wix for windows machines.
The machines might have a another firebird instance, usually default instance running, thus must be installed on a different port. User should not see any dialogues and installation should happen in the background.
I am able to do the installation through instsvc, installing firebird on a different port with a new instance name. However on windows you get the file execution security warning for instsvc execution. Thus I was looking in to http://www.mwasoftware.co.uk/firebird-msm merge modules but, it does not provide me with information on how to install on a different port/service name(if required).
Could you please provide me info on how to install firebird using wix, so that it would install firebird as apart of my wix installation, on a specified port, without obstructing existing installations, and no interaction from the user.
The Firebird installer only installs the service as the default instance with the default port. If you want to run on a different port and use a different servicename, then you need to change the port in firebird.conf yourself, and execute instsvc with an alternative servicename.
What I got from the merge module dev. While I havent tried the solution yet, seems to be straight forward.
The build scripts including WIX scripts are all available for
download. The direct link is:
http://www.mwasoftware.co.uk/download-msm/download/8-current-version/130-msm-build
To install a (possible) second server, you should do two things:
Build use a modified firebird.conf
Change all the UUIDs so that the package is unique.
You will also need to copy the build251.bat script and update the
environment variables to the Firebird version you are using. See also
readme.htm.
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
Every time a new developer joins the team or the computer a developer is using changes, the developer needs to do lots of work to setup the local development environment to make the current project work. As a SCRUM team we are trying to automate everything including deployment and tests so what I am asking is: is there a tool or a practice to make local development environment setup automated?
For example to setup my environment, first I had to install eclipse, then SVN, Apache, Tomcat, MySQL, PHP. After that I populated the DB and I had to do minor changes in the various configuration files etc... Is there a way to reduce this labor to one-click?
There are several options, and sometimes a combination of these is useful:
automated installation
disk imaging
virtualization
source code control
Details on the various options:
Automated Installation Tools for automating installation and configuration of a workstation's various services, tools and config files:
Puppet has a learning curve but is powerful. You define classes of machines (development box, web server, etc.) and it then does what is necessary to install, configure, and keep the box in the proper state. You asked for one-click, but Puppet by default is zero-click, as it checks your machine periodically to make sure it is still configured as desired. It will detect when a file or mode has been changed, and fix the problem. I currently use this to maintain a handful of RedHat Linux boxes, though it's capable of handling thousands. (Does not support Windows as of 2009-05-08).
Cfengine is another one. I've seen this used successfully at a shop with 70 engineers using RedHat Linux. Its limitations were part of the reason for Puppet.
SmartFrog is another tool for configuring hosts. It does support Windows.
Shell scripts. RightScale has examples of how to configure an Amazon EC2 image using shell scripts.
Install packages. On a Unix box it's possible to do this entirely with packages, and on Windows msi may be an option. For example, RubyWorks provides you with a full Ruby on Rails stack, all by installing one package that in turn installs other packages via dependencies.
Disk Images Then of course there are also disk imaging tools for storing an image of a configured host such that it can be restored to another host. As with virtualization, this is especially nice for test boxes, since it's easy to restore things to a clean slate. Keeping things continuously up-to-date is still an issue--is it worth making new images just to propagate a configuration file change?
Virtualization is another option, for example making copies of a Xen, VirtualPC, or VMWare image to create new hosts. This is especially useful with test boxes, as no matter what mess a test creates, you can easily restore to a clean, known state. As with disk imaging tools, keeping hosts up-to-date requires more manual steps and vigilance than if an automated install/config tool is used.
Source Code Control Once you've got the necessary tools installed/configured, then doing builds should be a matter of checking out what's needed from a source code repository and building it.
Currently I use a combination of the above to automate the process as follows:
Start with a barebones OS install on a VMWare guest
Run a shell script to install Puppet and retrieve its configs from source code control
Puppet to install tools/components/configs
Check out files from source code control to build and deploy our web application
I stumbled across this question and was very suprised that no one has mentioned Vagrant yet.
As Pete TerMaat and others have mentioned, virtualization is a great way to manage and automate development environments. Vagrant basically takes the pain away from setting up these virtual boxes.
Within minutes you can have a completely fresh copy of your favourite Linux distro up and running, and provisioned exactly the same way your production server is.
No more fighting with OSX or Windows to get PHP, MySQL, etc. installed. All software lives and runs inside the virtual machine. You can even SSH in with vagrant ssh. If you make a mistake or break something, just vagrant destroy it, and vagrant up to start over fresh.
Vagrant automatically creates a synced folder to your local file system, meaning you don't need to develop within the virtual machine (ie. using Vim). Use whatever your editor of choice is.
I now create a new "Vagrant box" for almost every project I do. All my settings are saved into the project repository, so it's easy to bring on another team member. They simply have to pull the repo, and run vagrant up, and they are literally ready to go.
This also makes it much easier to handle projects that have different software requirements. Maybe you have some projects that rely on PHP 5.3, but some newer ones that run PHP 5.4. Just install the version you want for that project.
Check it out!
One important point is to set up your projects in source control such that you can immediately build, deploy and run after checkout.
That means you should also checkin helper infrastructure, such as Makefiles, ant buildfiles etc., and settings for the tools, such as IDE project files.
That should take care of the setup hassle for individual projects.
For the basic machine setup, you could use a standard image. Another option is to use your platform's tools to automate installation. Under Linux, you could create a meta-package that depends on all the packages you need. Under Windows, a similar thing should be possible using MSI or the like.
Edit:
Ideally, instead of checking in helper infrastructure, you check in the information that allows the build to generate the helper infrastructure. This is the approach taken by e.g. the GNU build system (autotools etc.), or by Maven. This is even more elegant, because you can (theoretically) generate infrastructure for any (supported) build environment, thus you are not bound to e.g. one specific IDE, and settings in the helper infrastructure (paths etc.) don't need to duplicate the main project settings.
However, this also a more complex approach, so if you can't get it to work, I believe checking in stuff like IDE files directly is acceptable.
I like to use Virtual PC or VMware to virtualize the development environment. This provides a standard "dev environment" that could be shared among developers. You don't have to worry about software that the user could add to their system that may conflict with your development environment. It also provides me a way to work to two projects where the development environments can't both be on one system (using two different versions of a core technology).
Use puppet to configure both your development and production environment. Using a top-notch automation system is the only way to scale your ops.
There's always the option of using virtual machines (see e.g. VMWare Player). Create one environment and copy it over for each new employee with minimal configuration needed.
At a prior place we had everything (and I mean EVERYTHING) in SCM (clearcase then SVN). When a new developer can in they installed ClearCase|SVN and sucked down the repository. This also handles the case when you need to update a particular lib/tool as you can just have the dev teams update their environment.
We used two repo's for this so code and tools/config lived in separate places.
I highly recommend Blueprint from DevStructure. It's open-source and your use case is actually the exact reason we originally wrote the software. Our goals have somewhat changed, but it still is the perfect tool for what you are describing. In short, you can create reusable server configs - dead simple configuration management. I hope this helps!
https://github.com/devstructure/blueprint (Blueprint # Github)
I've been thinking about this myself. There are some other technologies that you could throw into the mix. Here's what I'm currently setting up:
PXE based pre-seeded installation images (Debian Squeeze). You can start up a bare-metal machine (or new virtual appliance) and select the image from the PXE boot menu. This has the major advantage of being able to install your environment on physical machines (in addition to virtual appliances).
Someone already mentioned Puppet. I use CFEngine but it's a similar deal. Essentially your configuration is documented and centralized in policy files which are continually enforced by an agent on the client.
if you don't want a rigid environment (i.e. developers may choose a combination of tool-sets) you can roll your own deb packages so new devs can type sudo apt-get install acmecorp-eclipse-env or sudo apt-get install acmecorp-intellij-env, for example.
Slightly off-topic, but if you run a Debian based environment (i.e. Ubuntu), consider installing apt-cacher (package proxy). In addition to saving bandwidth, it will make your installations much faster (since packages are cached on your local network).
If you're using OSX and working with Rails. I'd suggest either:
https://github.com/platform45/let-there-be-light
https://github.com/thoughtbot/laptop
If you use machines in a standard configuration, you can image the disk with a fresh perfectly configured install -- that's a very popular approach in many corporations (and not just for developers, either). If you need separately configured OS's, you can tar-bz2 all the added and changed files once a configured OS is turned into your desired setup, and just untar it as root to make your desired environment from scratch.
if you're using a linux flavor, you've probably got a package management system: thinks .rpm for fedora/redhat, or .deb for ubuntu/debian. many of the things you describe already have packages available: svn, eclipse, etc. you could roll your own packages for company specific software, create a repository (perhaps only available on the local network) and then your setup could be reduced to a single bash script which would add the company repo to /etc/apt/sources.list (debian/ubuntu) and then call a command like,
/home/newhire$ apt-get update && apt-get install some complete package list
you could use buildbot to then automate regular builds for company packages that change often.
Try out DevScript at http://nsnihalsahu.github.io/devscript .
Its one command like ,
devscript lamp or devscript laravel or devscript django . In around a few minutes ,depending on the speed of your internet co