Community Forums
Page 1 of 3 123 LastLast
Results 1 to 5 of 12

Thread: TFS and Automated Build

  1. #1
    Join Date
    Jan 2009
    Location
    Johannesburg, South Africa
    Posts
    38

    TFS and Automated Build

    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

  2. #2
    Join Date
    Feb 2002
    Location
    Alabama
    Posts
    356
    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...953#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.
    Last edited by Shuttledude; 03-04-2013 at 04:09 PM.
    Relax, it's only technology.

  3. #3
    Join Date
    Jul 2003
    Location
    Austin, TX
    Posts
    4,430
    Quote Originally Posted by NeilHayes View Post
    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.
    Christopher Painter
    ISWIX, LLC.
    Visit iswix.com for contact information

  4. #4
    Join Date
    Feb 2002
    Location
    Alabama
    Posts
    356
    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).
    Relax, it's only technology.

  5. #5
    Join Date
    Jul 2003
    Location
    Austin, TX
    Posts
    4,430
    A simple example would look like:

    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
    <PropertyGroup>
    <InstallShieldProductConfiguration>ProductConfiguration1</InstallShieldProductConfiguration>
    <InstallShieldRelease>Release</InstallShieldRelease>
    </PropertyGroup>
    <ItemGroup>
    <InstallShieldProject Include="$(MSBuildProjectDirectory)\$(MSBuildProjectName).ism"/>
    </ItemGroup>
    <Import Project="$(MSBuildExtensionsPath32)\InstallShield\2011\InstallShield.targets"/>
    </Project>

    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:

    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
    <PropertyGroup>
    <InstallShieldProductConfiguration>Default Configuration</InstallShieldProductConfiguration>
    <Configuration>Debug</Configuration>
    <InstallShieldRelease>$(Configuration)</InstallShieldRelease>
    <InstallShieldBuildDependsOn>PreBuild</InstallShieldBuildDependsOn>
    <InstallShieldProductVersion>$(MSIProductVersion)</InstallShieldProductVersion>
    </PropertyGroup>
    <ItemGroup>
    <InstallShieldProject Include="$(MSBuildProjectDirectory)\$(MSBuildProjectName).ism"/>
    <InstallShieldMergeModulePath Include="$(MSBuildProjectDirectory)\MSM"/>
    </ItemGroup>
    <ItemGroup>
    <InstallShieldPropertyOverrides Include="$(MSIProductCode)">
    <Property>ProductCode</Property>
    </InstallShieldPropertyOverrides>
    </ItemGroup>
    <Import Project="$(MSBuildExtensionsPath32)\InstallShield\2011\InstallShield.targets"/>
    <Target Name="PreBuild">
    <Exec Command="attrib -r &quot;$(MSBuildProjectDirectory)\*&quot; /S"/>
    </Target>
    </Project>

    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 )
    Last edited by Christopher Painter; 03-05-2013 at 10:38 AM.
    Christopher Painter
    ISWIX, LLC.
    Visit iswix.com for contact information

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •