Error using miabuild.exe with MSBuild & Task Scheduler

[kwco]

I am having a slight problem with InstallAware 9 on my Windows Server 2008 build machine.

I run the command line build (miabuild.exe) from an Exec task in an MS Build Script. The installer aware script basically just grabs a few redistributable files from the Visual Studio 9 directory.

Code: Select all


<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <InstallAwareDir>C:\\Program Files\\InstallAware\\InstallAware 9</InstallAwareDir>
        <IAProjectFile>E:\\IA9Test\\BuildTest\\BuildTest.mpr</IAProjectFile>
        <OutDir>E:\\IA9Test\\Output</OutDir>
        <WorkingDir>C:\\Program Files\\Microsoft Visual Studio 9.0</WorkingDir>
    </PropertyGroup>

    <Target Name="BuilIA9">
        <Message Text="Creating Installer"/>
        <RemoveDir Directories="$(OutDir)" ContinueOnError="true"/>
        <MakeDir Directories="$(OutDir)"/>
        <Exec Command="&quot;$(InstallAwareDir)\\miabuild.exe&quot; &quot;$(IAProjectFile)&quot; /r /o=&quot;$(OutDir)&quot;" WorkingDirectory="$(WorkingDir)"/>

    </Target>

</Project>


The build script is called from from a batch file like so:

Code: Select all

SET MY_DIR=E:\\IA9Test
"C:\\WINDOWS\\Microsoft.NET\\Framework\\v3.5\\msbuild.exe" /l:FileLogger,Microsoft.Build.Engine;logfile=IA9Test.log /toolsversion:3.5 %MY_DIR%\\IA9Build.xml"


If i run this batch file from the command line everything works. But if I run it from the Windows 2008 task scheduler I get the following error:

C:\\Program Files\\InstallAware\\InstallAware 9\\miabuild.exe" "E:\\IA9Test\\BuildTest\\BuildTest.mpr" /r /o="E:\\IA9Test\\Output"

InstallAware Command Line Build Utility

EXEC : error : Not implemented
E:\\IA9Test\\IA9Build.xml(19,9): error MSB3073: The command ""C:\\Program Files\\InstallAware\\InstallAware 9\\miabuild.exe" "E:\\IA9Test\\BuildTest\\BuildTest.mpr" /r /o="E:\\IA9Test\\Output"" exited with code 3.

So why does the batch file and build sruipt succeed when run from the command prompt, but not when run from the Windows Server 2008 Scheduled Tasks manager?

Also this woked with InstallAware 8. The problem has occurred only with InstallAware 9.

[ALive]

Hi!

I've encountered the same, but we're using TeamCity and Ant Build

I've written this in the post:
Error running miabuild.exe from automation build tool
http://www.installaware.com/forums/viewtopic.php?t=4649

On version 8 it was fine, but on version 9 it doesn't.

So now it's both of us

[kwco]

I've encountered the same, but we're using TeamCity and Ant Build

Good to know it isn't just me. Hope someone can come up with a fix soon, my daily build is failing every day.

[MichaelNesmith]

You need to specify correct startup folder for miabuild.exe.

[kwco]

You need to specify correct startup folder for miabuild.exe

Is there a new working directory?

Code: Select all

<Exec Command="&quot;$(InstallAwareDir)\\miabuild.exe&quot; &quot;$(IAProjectFile)&quot; /r /o=&quot;$(OutDir)&quot;" WorkingDirectory="$(WorkingDir)"/>


The WorkingDirectory is the startup folder which I set to the folder containing the files for the installer (c:\\Program Files\\Microsoft Visual Stidio 9).

This is the exact same arrangement (in fact the exact same build script) that I used with version 8.

Also this works from the command line when run from within the Directory the xml file is in. The Win2008 task uses this directory as it's "Start In" folder.

From the other thread on this issue it seems the problem is with the fact that Version 9 needs to run as an interactive desktop process (and fails with an unhandled exception when run from the task scheduler), whereas Version 8 did not require this.

[MichaelNesmith]

Yes, that is probably the reason - just enable that setting in your task scheduler.

[kwco]

Yes, that is probably the reason - just enable that setting in your task scheduler.

Any Idea how to do this?

I can't find a setting like that in the Windows 2008 Task Scheduler.

It does not appear as one of the properties of a task, unless the task scheduler uses some obscure name for it.

[MichaelNesmith]

Its in task properties!

[kwco]

In Windows 2008 Server the feature that allows a service to interact with the desktop has been removed (it's the same in Vista as well). You need to set the task to only run when the user is logged on.

This will mean leaving that user account permanently logged into the machine 24x7 so the builds can run.

[dmostert]

Will this be fixed in a future update?

I now have to run my CruiseControl.NET as a console app i.s.o a service.

Thanks,
D.

[kwco]

Will this be fixed in a future update?

From what I understand, after lodging a support incident, this behavior occurs by design.

[danvy]

As an owner of a Studio maintenance, we get the upgrades.
Right now, we can't upgrade to version 9 as it would break our build process using FinalBuilder.
So it's a show stopper for us.

[kwco]

As an owner of a Studio maintenance, we get the upgrades.
Right now, we can't upgrade to version 9 as it would break our build process using FinalBuilder.
So it's a show stopper for us.

At least you can use the previous version. We evaluated Version 8 but bought Version 9. Our automated builds were dead on arrival.

[MichaelNesmith]

Why not just let the build tool receive window messages?

[kwco]

Why not just let the build tool receive window messages?

That is the solution. However, in order to do that, you need to have a user account logged onto the machine if you are running it from the windows task scheduler on Vista or Windows 2008.

It also means that it can't be run in an automated build tool that works as a background process. Instead of running as a service under the system account (or from a task as above) a build tool must run as a console app in a command prompt window to use miabuild.exe.

As other posters on this thread have noted, this makes it very inconvenient to use with automated build tools like Final Builder, Team City, Ant Build or Cruise Control.

Some IT departments won't leave accounts permanently logged on for security reasons and with that policy in place this issue is a show stopper that effectively makes automated builds impossible (at least it does for us). Daily builds that were scheduled for 4am now can't occur until 9 am when I arrive at work, log into the server and manually start them from the command prompt.