How to use third part deploy tools to build TS installer, such as "Inno Setup"

[TabZhang]

As the subject, I really don't like TS Deployment Tools, I want use "inno setup" to build my own installer, Is it possible?

[Norbert_B]

The purpose of the TS Deployment Utility is to give users easy configurable access to "what is to be added to the MSI (Microsoft Installer)". As a product of NI, the tool focuses on any files you maintain in your TS workspace/project and NI installation packages like runtime environment for code modules (e.g. LV RTE, NI drivers). 3rd party packages are not that easy to access if possible at all in the TS Deployment Utility.

Using 3rd party installer generation tools is of course possible as these are standalone tools. The challenge you are facing with these however is that you as developer have to conciously know what files and packages are vital for your application. Failing to gather all sources properly will result in incomplete installation packages.

Experience shows that most developer do forget about packages/modules/dynamic components leaving the runtime system to fail badly during execution.

However, if you feel that you are up to keeping track of all dependencies on your own, feel invited to give inno setup a try!

Norbert

[TabZhang]

Hi Norbert,

Actually, I just use teststand and C#, no LabVIEW and no anything else, my main executable and files totally only 1.5MB.

When I deploy it to teststand installer， it become up to 459MB，I think it's not acceptable.

I think there are too many unnecessary files in there，buy I have no way to disable it.

I think there is much space to optimization, TS can use the same way as labview, provide run-time installer, I think most people perfer make the program as portable one just like MS .Net.

[Norbert_B]

Depending on the content, >400MB for an installation package sounds large. However, there are configurations where 400MB sounds much too small.

Can you verify your build script in the TS Deployment Utility about included RunTime Engines (RTE) and drivers?

Also, your screenshots don't tell us how many dependencies your application has. You talk about a single EXE. But what about the seq-files? The DLLs/assemblies you call from there? How about additional files like ReadMe?

Norbert

[TabZhang]

Hi Norbert,

Thanks for your answer and help!

Portable, this does not mean that it is a single file。I want I can control my program with all the necessary file within one folder, Of course， I don't reject the runtime, such as LabVIEW runtime or Dot Net Framework.

In a word, Installation package size is not the most important issue I care about.

I firmly believe that the deplyment of  TS inistaller, there are too many useless files inside.

I like the way of LabVIEW programming and LabVIEW also, which the exe and runtime is separately.

I'm trying to put all the files in the way I want, in one folder, so that I can control it, even I can do it like LabVIEW and Dot Net, Is it possible?

Thanks again!

[TabZhang]

Only add TS runtime, the size will up to 400MB, please see the picture below.

some other is required by TS runtime.

[Norbert_B]

As you can see, due to dependecies, a whole lot of files are added to the installation package. However, not all components will be installed when running the installer. This is true if e.g. .NET framework 4.0 is already on the system when installing the package.

I recommend you to create multiple build scripts. One build script for the RTEs, another for the application itself. This helps to reduce installer/update sizes for applications, but ensures that you have a base installer bringing all necessary stuff to run the application later on.

Norbert

[TabZhang]

Hi Norbert,

Thank you for your patience to answer questions for me！

Good Idea! Build seperate script for RTEs, That's what I wanted to try before, but the TS deployment utility need I specify one workspace file which should including one TestStand Project file. so how can I build one script totally for RTEs only?

One more question: Why do I want to put all the files in one folder, I want to use the relative path rather than the absolute path.I think everyone should think that the relative path is a better choice.What do you think?

[Norbert_B]

---

TabZhang wrote:

Good Idea! Build seperate script for RTEs, That's what I wanted to try before, but the TS deployment utility need I specify one workspace file which should including one TestStand Project file. so how can I build one script totally for RTEs only?

---

You can create multiple build scripts. Store each build script in a separate file. Consider the workspace/project only as a container for the files you want to distribute. Depending on the script "type", you simple select a different set of files.

---

@TabZhang wrote:

One more question: Why do I want to put all the files in one folder, I want to use the relative path rather than the absolute path.I think everyone should think that the relative path is a better choice.What do you think?

---

Relative paths are indeed the recommended way to store dependencies. It is best practise, to store all components of the project relative to the project files in subdirectories. However, in some circumstances, relative paths are difficult or "ugly".

One example: Your sources are in the project folder <project>\...

But there are also sources located on a central location like <libraries>\...

Imagine that <libraries> is not a subfolder for <project>, in worst case, it is located on another drive (or mounted drive). How should a relative path look like in that case for distribution?

In order to keep a clean install base, i recommend you to keep 'universal' stuff on a static, 'universal' location and not trying to bother with relative paths there....

Norbert