Mirror of from 10/8/12 Licensed under CC BY 3.0

Original contents:


This article aims to provide complete information about how to deploy IronPython scripts to client computers.


Both the IronPython interpreter and runtime are made of Microsoft Intermediate Language (MSIL), meaning that it is bytecode like all .NET programs. Therefore it requires the IronPython binaries and either the .NET Framework 2.0 (Windows) or Mono (*nix). All files from the IronPython distribution are not required to run IronPython scripts on Windows. Therefore the following must be true about the machine.


.NET 2.0 or 3.0 installed
IronPython binaries exist in the same folder


*nix (Linux, Unix, Macintosh)

Mono installed
FePy – IronPython community distribution, includes the CPython library.

For information on how to acquire any of the above please see the Downloads article.

Python Libary

The standard CPython library must be installed on the target machines if the client is a Windows machine and the libary is used. A clear give-away is when the following code exists in any of the python files:

Please refer to Using the Python Standard Library for more information on when and how the standard Python library is used.

.NET 3.0

The .NET 3.0 framework is required on the target computer whenever any of the enclosed classes are used. If the author uses the words Windows Communication Foundation (WCF), Windows Workflow Foundation (WWF), Windows CardSpace (WCS), Windows Presentation Foundation (WPF), or XAML then the file is likely to require the .NET Framework 3.0.

Some examples of statements which require .NET 3.0:

File Associations

File associations can be created so that whenever a .py script is double-clicked, it will call the IronPython interpreter. You should think twice about modifying any file associations if the standard CPython library has been installed as you may break some standard Python programs.

You can set up file associations in Windows XP by following these instructions:

  1. Double-click “My Computer” on the desktop.
  2. Click on the “Tools” menu.
  3. Click the “Folder Options” menu item.
  4. Click the “File Types” tab, it may take a few moments to load.
  5. Scroll down to the “PY” extension…
    1. If it does not exist then you can add it to the list by hitting the “New” button.
    2. If an association already exists then click the “Change” button to change it.
    3. If you want to right-click and choose “Run” then click the “Advanced” button.
  6. In any case point the extension to the “ipy.exe” IronPython interpreter.

Batch Files

An alternative to setting up file associations, which entails more involved changes to your or the user’s system, is to deploy a batch file along with your script. The batch file should reside in the same directory and bear the same name (but using the BAT extension, of course) as your main Python script. The batch file can then be used to launch your script either from the Windows Command Prompt or the Windows Explorer assuming the following contents:

This is a very generic line that basically launches ipy.exe (assuming it is in your environment PATH) and supplies the name of your python script as the first argument (this is the odd-looking bit reading “”) and passes-through the remaining arguments from the batch on to your script (this is the %* bit). You may be wondering what means after all. Taking the simple case first, a %0 appearing in a batch file gets replaced at run-time with the text you typed to invoke the batch file on the command-line (excluding arguments). When you insert a ~ and some reserved letters between % and 0 then the various path components of the batch file path are expanded at run-time based on the modifiers you supply. The useful modifiers to know are d (drive letter), p (directory path), n (file name) and x (extension). So by saying, we told the batch interpreter that we want to expand the drive, directory path and file name of the batch file, but note, not the extension (no x was mentioned). Instead we supplied the conventional Python extension (py). This may also explain why the batch file name must be the same as the file name of your main Python script. The surrounding double-quotes (“) ensure that paths with spaces are handled as a single atom and not mistaken as multiple arguments to the batch. Finally, the @ at the beginning tells the batch file interpreter not to echo the statement it is executing to the console. The at-sign (@) shortcut basically avoids having <et another line at the start of the batch reading ECHO OFF. Ffor single-liner batches, a simple @ does the job well.

Back to Contents.

Wayback Machine link: