Application deployment

From PixelLight Wiki

Jump to: navigation, search

For application deployment it is necessary to deliver everything required to run your application developed with PixelLight on another system. Because we have to assume that no PixelLight SDK is installed nor compiler specific runtime this is not always as easy as it may sound. Within this article we provide you with information that should enable you get started with the application deployment topic, but please keep in mind that we can't discuss every possible situation in here.

We cover the following situation:

  • We have a 32 bit Windows platform
  • As development environment we use Visual Studio 2010, also known as VC 10, we are using Visual C++
  • We are using the scene system, OpenGL for rendering, Newton Game Dynamics for physics used through the scene system
  • To keep it simple, we want to deliver your application as a ZIP file
  • We don't want to install 'anything' on the system of the user


Contents

Visual C++ 2010 compiler runtime

Because we develop within our situation with Visual C++ 2010, your resulting binaries require the Visual C++ 2010 compiler runtime. For Windows users with up-to-date systems, this is no problem because they often already have the required runtime installed. But we can't expect that everbody has the required runtime already installed, so we need to take a deeper look. We have multiple options:

  • We tell the user to download the Microsoft Visual C++ 2010 Redistributable Package or we even provide this file package ("vcredist_x86.exe", 4,76 MB) within your ZIP. Although this is the cleanest solution with the fewest problems - the user now tells us he is not allowed to install anything on the target system, so we can forget this option.
  • We put the required Visual C++ 2010 compiler runtime files directly into your application directory. As a result, we don't need to install anything - but it is to assume that not just your application is using Visual C++ 2010, so we end up with multiple copies of one and the same compiler runtime on the system. But because we have no other option in our situation, we have to go this way...

For our PixelLight based application we need the following Visual C++ 2010 compiler runtime files:

  • "msvcr100.dll"
  • "msvcp100.dll"

... and because there are many security issues, we need to put these files into each directory with executables or dynamic libraries, otherwise Windows refuses to start the application and you get an error message like: "The application has failed to start because the application configuration is incorrect." As a result, it is a good idea to put all executables and dynamic libraries into one and the same directory.


Dynamic PixelLight libraries

Beside your application executable and the Visual C++ 2010 compiler runtime, you also need to deliver the required dynamic libraries (DLLs) coming with PixelLight. Because PixelLight is highly modular you don't need to ship all DLLs of the PixelLight SDK - just the ones that you are really using. Experts can use tools like Dependency Walker to see the DLLs the application depends on. Please keep in mind that you can only see 'directly linked' components with such tools - because the application executable itself is not dependent on pure plugins, you can't use tools to get an overview of the dlls you need to provide. Lets have a look at the used PixelLight components in our situation:

The scene system is implemented within "PLScene.dll", so you need this DLL. This PixelLight component depends on:

  • "PLCore.dll"
  • "PLMath.dll"
  • "PLGraphics.dll"
  • "PLGui.dll"
  • "PLRenderer.dll"
  • "PLMesh.dll"
  • "PLInput.dll"

These are the 'must have' DLLs, if they are not available Windows can not even start your application and an error message dialog will appear! Usually "PLEngine.dll" is required, too.

Now to the 'loose' components. "PLRenderer.dll" is backend-based, in your situation we use OpenGL implemented within the "PLRendererOpenGL.dll" plugin. Because "PLRendererOpenGL.dll" is a PixelLight plugin, you also need to put PLRendererOpenGL.plugin" into the same directory the plugin is in. If you need support for NVIDIA Cg shaders, do also add the "PLRendererOpenGLCg.dll" plugin and it's corresponding PLRendererOpenGLCg.plugin" file. This Cg shader language plugin DLL itself is 'directly linked' to "cg.dll" and "cgGL.dll", so don't forget to deliver them as well.

Usually, the "PLCompositing.dll" plugin and it's corresponding PLCompositing.plugin" file is used as well for scene rendering and realtime compositing.

Finally to the physics components. Because we use in your situation physics completely through the scene system, the resulting executable is not 'directly dependent' from "PLPhysics.dll". The physics component is backend-based and within our situation Newton Game Dynamics implemented within the "PLPhysicsNewton.dll" plugin is used for physics. This DLL itself is 'directly linked' to "newton.dll". Because "PLPhysicsNewton.dll" is a PixelLight plugin, you also need to put "PLPhysicsNewton.plugin" into the same directory the plugin is in.

Now you have everything together and your application should be able to run on the customer system. Beside your executables there are now some other files as well... this may sound quite complicated, but this is the price of a highly modular system. But the gain is huge! You can create quite simple applications using for example just "PLCore.dll", so you just need to provide "PLCore.dll". You can 'just put in' new plugins into your application directly to add new features, changing a used backend and so on.


Standard data files

From the "Runtime\Data\"-directory you need for this situation the following files:

  • "Standard.zip"

Put them into a "Data"-Subdirectory. (you may not need them for every project, but if you don't know whether or not you need them, add them for sure)


Local files

  • Do not publish "<our application name>.log", it contains personal information about our system (hardware configuration, user name and so on)


Portable application

If you followed the instructions above and your application doesn't mess around with the OS registry (what we do NOT recommend for 'final applications', for the PixelLight SDK we only did it to make the developers life more comfortable!) - your application is already 'portable' and can for example directly be started from an USB-stick. To speed up your 'portable application' you have the following options:

  • Use 'executable packer' third party tools like UPX for shrinking exe- and dll-files while keeping them correctly executable
  • Prefer generating resources like textures 'automatially on runtime' instead of loading them
  • Pack resources into a zip file PixelLight can read from
  • Have a look at the next point... :D


"All within a single exe that can directly start without the need to unpack or even install it"

If you want to deploy your application in the way mentioned in the title of this point you have to use third party tools.

The first working tool I found was 'MoleBox' - unfortunately not free and I haven't found a free alternative that worked for me. If you want to search for such tools within the internet, use for example 'runtime exe packer' as keywords. (I mention that because when I wanted to do this the first time, I had no glue what keywords I had to use *g*)

Although this way of application deployment is quite comfortable for the end user, you need to keep in mind that there 'may be' legal problems with certain third party libraries your're using. We strongly recommend to check the licence texts of the third party libraries your're using whether or not it's allowed to 'manipulate the binaries'. (because it IS a manipulation!)


Installer

For the PixelLight SDK itself we're using 'NSIS' as installer.

Other languages
 • Русский • Deutsch • Français • Español • Italiano • 日本語 • Polski • Česky • Nederlands • 中文
Retrieved from "http://developer.pixellight.org/wiki/index.php/Application_deployment"
Personal tools