UI Automation for Developers

I'm currently working on a Wix 3.0-based installer with about 6 different wizard dialogs. Testing installers is a lot of work, because it is difficult to arrange for only the part of the installer you are interested in to run. I found myself filling out credentials, picking websites, etc. over and over. The QA organzation at my company uses AutoIt3, a free UI automation tool with a VB-like syntax, to do UI automation for Windows GUIs, and I thought I would check it out and see if I could quickly record a macro which would get me all the way through the UI sequence of my installer. Sure enough, it was as easy as this:
  1. Download and install AutoIt3
  2. Make sure to get the full SciTe editor for AutoIt (it is not included in the basic install). This editor includes a tool called AU3Record which will record your mouse and keyboard interactions with a Windows app and generate the AutoIt script to replay those actions. The tool is installed to: c:\Program Files\AutoIt3\SciTE\ScriptWriter\Au3Record.exe
  3. Run Au3Record and record your interaction. Save the resulting script to an .au3 script file, and you can launch it by double clicking.

Comments

Post a Comment

Popular posts from this blog

Web Deployment Projects targeting x64

I am working on an ASP.NET web application which has mixed-mode C++/CLI dependencies that call out to pure unmanaged DLLs. A new requirement is a 64-bit version of the application (it runs fine on Win64 in a IIS 32-bit app pool, but since 32-bit mode is an all-or-nothing proposition, it was decided we need a true 64 bit app.) I ran into a problem getting the Visual Studio Web Deployment Project to compile my app. It seems that aspnet_compiler.exe loads all of the dependencies during compilation, and the 32 bit compiler cannot load the 64 bit images (you get a "bad image format" error.) This is true even on Win64 build machines that have the .NET Framework64 (and therefore the 64-bit aspnet_compiler.exe) After a bit of spelunking through the .wdproj, I found that a relatively simple change to the MSBUILD file shipped with the WD project will allow this to work out. It simply forces MSBUILD to use the 64 bit compiler if the $(Platform) variable is set to "x64" Here is...
Read more

Unintuitive error in msi log when DTF is misconfigured

Took me a little headscratching to figure this one out. I was getting an error from my installer with the following text: MSI (s) (A8:50) [14:27:03:446]: Product: MyProduct -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_ConfigFile_Install_Immediate, entry: CA_ConfigFile_Install_Immediate, library: C:\WINDOWS\Installer\MSI51BF.tmp The problem was not really that a DLL was missing, but that I had a typo in my <CustomAction DllEntry="xxx"> declaration. The typo caused a mismatch between the DllEntry value and the actual name of the .NET method implementing the [CustomAction].
Read more

NServiceBus distributor configuration

Technical notes from figuring out how to deploy NServiceBus in a distributed environment, beyond the simple development setups: 1. In a pub-sub scenario, distributors do not need any configuration specific to the publisher they are distributing for, or the subscribers they are distributing to. The configuration they do need is to mainly to define unique queue names for the queues that the distributor owns: NServiceBus.Distributor.dll.config: <add key="DataInputQueue" value="MyDistributorDataInputQueue" /> <add key="ControlInputQueue" value="MyDistributorControlQueue" /> <add key="ErrorQueue" value="MyEnterpriseErrorQueue@machine" /> <add key="StorageQueue" value="MyDistributorStorageQueue" /> At runtime, the subscriber contacts the distributor, sending it a subscription message that includes the publisher's address and the subscription message type. This makes the distribu...
Read more