Installshield Build Automation

I have seen many solutions for automating my InstallShield build, but I am having issues with each one. I am using InstallShield Professional 2013. Sorry for the lengthy question, but I am clueless on which direction to go to solve my issues.

1) IsCmdBld.exe - I have a script that runs and will build my installer. BUT, when the installer runs, I get an error message that says "The System Administrator has set policies to prevent this installation". I am not sure why this is happening, but I do not get the same error message if I build the installer through the designer. EDIT: Here is my command (%guid% is a Guid I generate to set the Product Code):

for /f %%i in ('"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\uuidgen.exe"') do set guid=%%i

"C:\Program Files (x86)\InstallShield\2013 SP1 SAB\System\ISCmdBld.exe" -p "MyInstaller.ism" -r SingleImage -y "1.0.0.13" -z ProductCode=%guid%

2) InstallShield Automation Interface - I have followed numerous examples and tutorials on this, but all end in the same result. When I call the following code:

     var project = new ISWiAuto20.ISWiProject();

I get this error:

Unable to cast COM object of type 'System.__ComObject' to interface type 
'ISWiAuto20.ISWiProject'. This operation failed because the QueryInterface call 
on the COM component for the interface with IID '{872D23A7-C18D-468C-895D-1CF027E4FBB1}' 
failed due to the following error: Library not registered. 
(Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)).

3) MsBuild.exe - Running MsBuild on my InstallShield project file yields this error:

error NSB4025: The project file could not be loaded. Invalid character in the 
   given encoding. Line 1, position 1

The choice between these approaches (when they all work) largely depends on the build system you are trying to integrate with. If you're using a batch or makefile approach, IsCmdBld.exe is probably the easiest starting point. If you're using Visual Studio and TFS or MSBuild, you'll probably have more luck there, as it will report errors in a way the build system can understand. (Other than that, they're fundamentally similar.) If you need to make tweaks to the project before you build it, the automation layer can either augment or replace the other approaches.

But in your case you say they all don't work. What have you done to diagnose why? Here are the first steps I'd take for each of those symptoms:

• IsCmdBuild built setups yielding an error that the IDE-build ones do not. First identify what the problem really is. Look in a verbose log for more information. Build both ways with the .msi available and compare the results with MsiDiff. Make sure you've tested elevated. Depending on what you find, it may be something to address in the project, the build process, or a bug in InstallShield.
• Automation Interface yields TYPE_E_LIBNOTREGISTERED. First off, if this is the IDE machine, consider repairing the installation. If it's a standalone-build machine, ditto. If it's a standalone-build machine that didn't use the installation, you should, or at least you should ensure the dependencies are present and that the automation interface is registered. Secondly, as Christopher Painter noted, InstallShield is a 32-bit product so it must be invoked from a 32-bit context. If you're calling, say, CScript to run a .vbs file, make sure you're using C:\Windows\SysWow64\CScript.exe.
• MSBuild NSB4025. The comment from stijn is largely correct - you can't call MSBuild on the .ism file (while it can be xml instead of binary, it's not MSBuild-compatible). However you can create a .isproj file that can work correctly. Save the project in Visual Studio, or copy <InstallShield>\Support\0409\MSBuild.xml to (ProjectName).isproj and tweak its contents; call MSBuild on the resulting .isproj file. Odds are strong this will have approximately the same results as IsCmdBuild, as the build portion is largely shared.