Team Build 2010 and Install Shield 2011 Premier

[AusBuilder]

Hello All

I have spent the better part of a week trying to figure out how the heck you use TFS build to manage you Install Shield Projects.

I don't get how on earth this project is advertised to work with Team Build. Its so hard to get any information on how to make things work.

If MS is pushing install shield and TFS 2010 you think they might play nice together.

Here is just a few of the 1000000 of problems I am encountering trying to use this product.

Why type of installer should I be using for Team build currently I am using Install Script and MSI

How do you manage picking up files when TFS copies files to directories (binaries) at build time and if the agent changes how do you make sure you picking up the right files?

Where do you find out information on Install Shield and TFS 2010 as its all random posts everywhere, is there no documentation on this no support nobody has a clue just smash away and hope for the best?

What the heck is best practice guidance.

Can I get Install shield to talk to the TFS object model at run time to pass in where the source and binaries are? ) can I input custom parameters from the workflow into the install shield? do I need to build more custom activities to do this?

Any help would defiantly be appreciated as this is driving me mad

How are these to products supposed to work together??

Its just frustrating that information on this is very very light or extremely broken down into micro solutions that are very hard to follow.

Thanks
Frustrated to no end

[Shuttledude]

As someone who has recently moved to the TFS environment I definitely understand your pain. Let me answer just one or two questions, there's really so much to learn.

1. You can use an existing InstallScript Msi *or* a Basic Msi project, no problem.

2. To compile an InstallShield project in TFS you can either modify the Default template for build definitions by adding an InvokeProcess action to directly compile the *.ism InstallShield project, but a better way is to simply add the *.ism project to a Visual Studio solution, which will automatically create an *.isproj project file that can be easily and directly invoked by the TFS Build Definition. Here is a description of how to do that:

(a) Create a new Visual Studio 2010 C# Class Library project, say "Deploy.sln".

(b) In Deploy.sln import your existing InstallShield project. To do this, open Solution Explorer (on the Main Menu at the top select View / Solution Explorer), right-click at the top where it says "Solution ...YourSolutionName..." and select Add / Existing Project, then navigate to your *.ism file. This action will add a project node for your InstallShield project to your Visual Studio 2010 solution. It will also create a new *.isproj file in the same directory where your *.ism project is located.

(c) At this time, right-click the new project inside VS2010 and build it. This should actually produce an InstallShield build, just as if you had opened InstallShield itself and compiled it!

(d) In your TFS Build Definition, add the build item(s) for your C# or C++ project(s) that you are building ... begin with a sample HelloWorld app that just produces one file, HelloWorld.exe, and create an InstallShield project for that simple app, HelloWorld.ism. So, in your build definition you'll invoke HelloWorld.sln which produces HelloWorld.exe, then the second item in your build definition is the *.isproj project itself, which produces the install for HelloWorld.

(e) At this point you will be ecstatic, thinking that's all there is to it. Too bad, because at this point you have only produced a build on your local computer. But to get this to build on a TFS build box there are two additional modifications you must make, one easy and one hard:

(f) The easy modification is to change your InstallShield project Path Variables from absolute to relative. Please note that you should make these changes inside Visual Studio 2010 while it's connected to your Team Foundation vault, *not* inside the InstallShield program itself. That way, TFS "knows about" these changes and creates changesets for you to check in, thereby keeping the path changes you make. Avoid the temptation to directly open the *.ism with InstallShield itself. With that in mind, go to Media /Path Variables and RELATIVIZE all the paths -- you cannot use ABSOLUTE paths because TFS produces a different directory structure when it pulls code from the repository! :eek: Relative paths always begin with , like this:

..\..\..\..\..\Binaries\Release\Win32\HelloWorld.exe.

The value of is automatically defined to be the directory where your InstallShield *.ism file is. From that location you just specify the relative path to whatever files you are looking for. This approach works because the value of is the same known value, whether locally on your computer or on the TFS build box. Of course when you compile your HelloWorld.sln Visual Studio project on your local computer (i.e., not on the TFS build box), you don't get a Binaries folder, you get a Release folder. But TFS places the program outputs in a Binaries folder. So, you need to look at the directory structure on your TFS build box in order to know how many levels you need to go up to find the Binaries folder. On your TFS build box the "Builds" folder can be shared with read-only permissions, which avoids the necessity of giving all users remote log-on privileges (a security issue).

(g) The other modification is to remove the read-only flag on the *.ism file before you compile it on the TFS build box, because it just won't compile otherwise. And it's really hard to describe to you how to do that exactly, but generally speaking you must create a new build definition template by making a copy of the Default template (call it "CustomBuildTemplate") and add a step to remove the read-only flag. In the Solution Explorer of Visual Studio 2010 double-click your new CustomBuildTemplate(listed as CustomBuildTemplate.xaml in your BuildProcessTemplates folder). This brings up a visual editor. You must add an InvokeProcess block at a location after the code is pulled, but before it compiles, to remove the read-only flag. To describe exactly where and how is really more than I should put on this board, but there are several MSDN websites that talk about it.

Good luck, I know this process seems 1,000 times more difficult than it should, but you'll get the hang of it. Look at the MSDN websites that talk about TFS2010.