TFS and Automated Build

[NeilHayes]

Could someone actually explain to me if this is possible...and if it is how does it work.

First....my build contains 30,000 files, these are ALL under TFS source control and do NOT form part of any visual studio project in any way. The files are not even developed in Visual Studio.

Currently I have an installshield project, where the IDE resides on my laptop. The project is checked into TFS source control.

The project has several prerequisites, Microsoft redistributables which currently sit on my laptop.

The 30,000 files also reside on my laptop, and basically I checkout the Installshield project, navigate to releases and perform a build.....works like a dream and no issues. I have a few powershell scrips to determine that all the files on disk are in the Installshield project and all the files in the installshield project are on disk.

This is not an ideal solution so I want to automate the process, so that perhaps every Friday/Monday an automated build can take place.

I can load the Installshield Standalone build engine on the TFS server as I have licenses available.

I know Christopher Painter mentioned a little about this but not enough for me to go on......

1. Can I do automated builds using TFS?
2. Is it a good idea or should I be using something else?
3. How do I do this?
4. Would files inherit 'read only' permissions from TFS for my build?
5. Should this process actually take place on the TFS server or perhaps a Production machine would be better? (Then how would it access the 30,000 files).

Regards

Neil

[Shuttledude]

1. Can I do automated builds using TFS?

Answer: Yes. I currently have more than 10 automated (scheduled) nightly builds in TFS that produce compiled setup projects.

2. Is it a good idea or should I be using something else?

Answer: You could also use Visual Build Pro to do this as an alternative.

3. How do I do this?

Answer: There is no easy quick way to describe this, but basically you'll need to create a "dummy" Visual Studio solution (*.sln) that contains your InstallShield *.ism as one of its projects. That's because TFS is not designed to directly build *.ism project files. There's more detail in a thread I posted here:
http://community.flexerasoftware.com/showthread.php?203223-Opening-InstallShield-Projects-in-Microsoft-Visual-Studio&p=483953#post483953

4. Would files inherit 'read only' permissions from TFS for my build?

Answer: Yes, and in fact if you do *not* want the files to be set to read-only after they are installed onto the target computer, you must modify the TFS template to remove them before compiling the setup project. But that's another story.

5. Should this process actually take place on the TFS server or perhaps a Production machine would be better? (Then how would it access the 30,000 files).

Answer: Typically you would set up a "build box" for this, which is a separate computer from the TFS server. In the build definition you can specify which build box to use, if you have more than one. The way it accesses the 30,000 files is by specifying their location in the TFS repository on the "Workspace" tab of the build definition. There are many other flags, switches, and path parameters that need to be set in the build definition, and its beyond the scope of this user board to go into that -- you'd need to go to an MSDN website to get the details.

I know this is an incomplete answer, but I hope it will get you started. 😉

[Christopher_Pai]

NeilHayes wrote:

1. Can I do automated builds using TFS?
2. Is it a good idea or should I be using something else?
3. How do I do this?
4. Would files inherit 'read only' permissions from TFS for my build?
5. Should this process actually take place on the TFS server or perhaps a Production machine would be better? (Then how would it access the 30,000 files).

1. Yes
2. Yes; good idea
3. It's a little tricky to learn the in's and out's at first. You have to get the .ISPROJ (MSbuild ) and .SLN (Solution) configuration settings to line up with the Product Config / Release defined in the .ISM. I have some template I use to make it easier.
4. InstallShield infers the Read Only bit in the file table from what's on the file system. I put an MSBuild Exec element in the .ISPROJ to make all the sources writable. ( Not compatible with incremental builds but I don't care for those in general anyways. )
5. On the TFS Build Server not the "Server" (App Tier ). All of the TFS servers should be treated as "Production" because this is crucial developer infrastructure.

6. I don't like InstallShield's pattern of picking up MSM and PRQ files from the installed product directories. To me these should be CM controlled artifacts. So I either check them into source control or I put them in a controlled location (read only file share) and copy them into the build. I wire all of the PRQ file dependences and the PRQ itself to the ISM using relative paths. No "Magic Build Machines" allowed.

We had over 800 build definitions and 100,000 builds a year at my last job. This worked well even at these scales.

[Shuttledude]

Christopher, you said "I put an MSBuild Exec element in the .ISPROJ to make all the sources writable." I would really prefer to do that instead of using a modified TFS template! My XML knowledge is weak, could you show me the code for this, or perhaps attach an *.isproj file and point out which block or element does this? Thanks!

And while I'm at it ... 😄 ... do you know how to use the *.isproj file to specify the build of multiple InstallShield project releases (e.g., TFS build definition invokes MyProduct.sln, which contains MyInstall.ism, that has 2 releases, Release1 and Release2 -- how to get *.isproj to build both releases).

[Christopher_Pai]

A simple example would look like:



ProductConfiguration1
Release







You don't even need the .SLN file or deal with solution configurations. If you have Foo.ism you just name this Foo.proj and then add it to the TFS solutions\projects to build collection.

Here's a slightly more complicated one:



Default Configuration
Debug
$(Configuration)
PreBuild
$(MSIProductVersion)







ProductCode








In this example you need to modify your process template a little bit to get TFS to pass the MSIProductVersion property to MSBUILD. You also need it to generate a GUID and pass it to MSBUILD as the MSIProductCode property. This code will also make all files writable. Finally it points IS to a directory to consume merge modules from.

Personally I use TFSVersion found on CodePlex and create a build definition like SomeBuild_1.0.YYDDD.R and then parse out everything after the _ to pass to MSIProductVersion.

PS- Don't forget that IS needs the 32bit MSBuild Engine ( lot's of COM )

[NeilHayes]

Thank you for your input......I'm going to set up a very small project and see how far I get. If all goes well I'll implement it on all my builds.

Regards

Neil

[operaza]

NeilHayes wrote:
Thank you for your input......I'm going to set up a very small project and see how far I get. If all goes well I'll implement it on all my builds.

Regards

Neil

You can just call your isdev commands from a batch.

Something like this goes in your .isproj file (the one you select as project to build in TFS)







Something like this goes in your batch file:
ISCmdBld.exe -p "%InstallersProjectsPath%\YourInstallshielProject.ism" -r "YourRelease" -c COMP -a "YourProductConfiguration"

You can also just call a vbscript from the batch and handle all the installshield part in a vbscript file, or whatever you like

Indeed, you can use the build service just like a windows scheduling service to schedule whatever you want, you don't need an installshield project or visual studio solution, just use the Exec Command

You can create a Build definition for each "Build Target" and schedule them on demand or apply the same batch approach using tfsbuild start to trigger whatever group of Build definitions (or targets) you want automatically

[Christopher_Pai]

Are you seriously proposing using MSBuild to call a batch file to call a VBScript to call an EXE when all of this can be done natively in MSBuild?

[operaza]

Christopher Painter wrote:
Are you seriously proposing using MSBuild to call a batch file to call a VBScript to call an EXE when all of this can be done natively in MSBuild?

Yes using msbuild to call a script, it gives me much more flexibility specially when dealing with automation tasks. And all the major build tasks are separated in build definitions that anybody can trigger from teamviewer, or group in a batch using tfsbuild and add to the tree.
All I need to know about msbuild is "Exec Command=" that's it

This is what a build script would look like in a simple batch file that anybody can modify or use as reference to create their own, they can also go to team viewer and trigger anything from there.

rem increments the build number
tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectInstallerProjects IncrementBuildNumber

rem visual studio solutions builds
start tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectVisualStudio VSProject1
start tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectVisualStudio VSProject2
start tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectVisualStudio VSProject3
start tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectVisualStudio VSProject4
start tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectVisualStudio VSProject5
start tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectVisualStudio VSProject6
start tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectVisualStudio VSProject7
tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectVisualStudio VSProject8

rem Installers builds
start tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectInstallerProjects CopyTFSBuilds
start tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectInstallerProjects Installers_WindowsApps_Build_All
tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectInstallerProjects Installers_WebApps_Build_All
tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectInstallerProjects Installers_WindowsServices_Build_All
tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectInstallerProjects Installers_SQLDBMigrations_Build_All
tfsbuild start http://domain:8080/tfs/defaultcollection TeamProjectInstallerProjects Installers_ReportsDeployments_Build_All

[Christopher_Pai]

Speechless.

[marazt]

Christopher Painter wrote:
A simple example would look like:




Default Configuration
Debug
$(Configuration)
PreBuild
$(MSIProductVersion)







ProductCode

Hi,

Related to your post about editing isproj file.

My problem is as follows:
I need to build msi project with merge modules. It is working fine if I set the full path to msm file in InstallShiled Options.
But on build server, msm is in different location. Next, I have multiple solutions. So specify all possible full paths in InstallShiled Options on build server is not good solution for me. I hope that usage of InstallShieldMergeModulePath element will helps, but is seems that this element is ignored and so, msm file is not found (event if I tested it on local machine == remove full path from InstallShiled Options, set it in InstallShieldMergeModulePath).

The solution on build server is builded without knowing that there are specific (isproj) projects. Build platform is set to x86.

What I want to do is to use element InstallShieldMergeModulePath with value of relative path to folder where is msm file for this concrete project, something like ".\..\msmFilder"

Do you know why is element InstallShieldMergeModulePath ignored?




Thanks a lot!

Marek

[operaza]

Christopher Painter wrote:
Speechless.

If wasn't a crazy idea, basically what you can do now with the new tfs vnext builds and release tasks