www.jilldentithconsulting.co.uk

http://www.joncarrstructuraldesign.co.uk

It seems to be down to three things:

1) ODBC drivers and where they live. 32 bit ODBC drivers (a la Sage) are managed with a separate admin console to 64 bit ones, with the x64 console being the default reached from administrative tools. To open x32, got to %system drive%\windows\syswow64\odbcad32.exe. Make sure the x64 one isn’t open already as I’ve found the OS gets confused (and then you do too!). Now I can Link my programs to the correct ODBC driver and a Sage database on this machine.

2) Sage Engine dll and tlb files. Reference paths from the old machine were no longer valid to the SageDataObject140/150 dlls. These, also, now live in syswow64. I used the following commands to register the dlls and tlbs:

c:\Windows\SysWOW64>regsvr32 sg50sdoengine150.dll

c:\Windows\SysWOW64>regsvr32 sg50sdoengine140.dll

c:\Windows\SysWOW64>cd c:\windows

c:\Windows>regtlib c:\windows\syswow64\sdoeng111.tlb
Registration of c:\windows\syswow64\sdoeng111.tlb successful.

c:\Windows>regtlib c:\windows\syswow64\sdoeng150.tlb
Registration of c:\windows\syswow64\sdoeng150.tlb successful.

c:\Windows>regtlib c:\windows\syswow64\sdoeng140.tlb
Registration of c:\windows\syswow64\sdoeng140.tlb successful.

Then added the references in through browsing to the dlls in add references in visual studio, which creates it’s own interop.

3) All now compiled okay but crashed on running. This is because my projects were set to ‘Any CPU’ which in x64 capable environment defaults to x64. This is incompatible with the 32bit com wrapped Sage dlls and generates “COMPlusExceptionCode 532462766″. Set the project to run as 32bit and all is good.

www.doofa-app.com

Creating an Installation
Create a new configuration.xml file (File -> New -> Configuration File)
Add the install node by right clicking ‘config File’ and Add -> Configurations -> Setup configuration
#CABPATH, #TEMPATH, #APPPATH
#CABPATH relates to the location where the embedded CAB is extracted on the target machine, and defaults to #CABPATH/GUID. This folder is deleted after the install has run
#TEMPPATH becomes the temporary folder on the install machine, usually the user’s temporary folder C:\Documents and Settings\[User]\Local Settings\Temp or C:\Users\sams\AppData\Local\Temp on Windows 7.
#APPPATH is the folder from which the bootstrapper is executed, on the build machine.

 
Adding an .msi
Right click and Add -> components -> msi components
Fill in:
• the display name (name of the package),
• id (the package id from Visual Studio/properties page of the .msi file)
• Required – dictates whether this component must be installed or not. (Check box will/won’t be available)
• Selected – whether check box to install is checked
• Package – this is where the installer will look for the .msi after unpacking. Therefore use #CABPATH. This value should match up to the #APPPATH value in the sourcefilepath value of the embedded .msi file.
Then embed the source .msi file. Right click under the msi component node and Add -> Embed -> Embed File. Complete the sourcefilepath as #APPPATH\targetfile where target file is the location of the msi in relation to the configuration file.

Adding a pre-requisite
A pre-requisite is another piece of software that is required to be installed before the main .msi(s).
Add a component command to the install: node. Add -> Components -> Command Component.
Complete:
• Display_Name and Id – these are the name of the component (both the same, eg ,Net 3.5 SP1)
• Required – dictates whether this component must be installed or not. (Check box will/won’t be available)
• Selected – whether check box to install is checked
• Command – when the pre-requisite is an executable file, this is path to the executable and should begin with #CABPATH
Embed the source executable file with Add -> Embed -> Embed File. Set the sourcefilepath as a filepath relative to the configuration file, beginning with #APPPATH\SupportFiles, where the executable is placed in the support files folder. Set the targetfilepath beginning with #TEMPPATH.

 
Install Check
It is possible to check whether components that you are installing are already installed. Add an install check node under the component node to accomplish this. Right click Add -> Check -> check type. You can check for items in the registry, for folders, for files, for product codes etc.

Building the Setup
Once the configuration file is complete, you can build the setup executable. You need the following files in the same folder:
• dotNetInstaller.exe
• InstallerLinker.exe
• CabLib.dll
• InstallerLib.dll
• Configuration.xml (your configuration file)
• Banner.bmp (if required)
• Support files folder and it’s contents
Using a command window, navigate to the above folder, then enter the following command:
installerLinker /Output:setup.exe /Template:dotNetInstaller.exe
/Configuration:configuration.xml /Banner:banner.bmp /Embed+ /Verbose+

where setup.exe is the name of the output file you require and configuration.xml is the name of your configuration file. Verbose will display the progress of the build in the command window (and any errors that occur and embed will embed the embedded files declared in the configuration
Testing the configuration
Run the resulting setup.exe from a command window with the /log parameter and a log of the installation, named dotNetInstallerLog.txt, will be left in the user’s temporary folder
C:\Documents and Settings\[User]\Local Settings\Temp or C:\Users\sams\AppData\Local\Temp on Windows 7.

Turns out to be nothing to do with my code, but something had gone wrong in .Net.

Copying the System.EnterpriseServices.dll from C:\Windows\Microsoft.NET\Framework\v2.0.50727\ in to the GAC at C:\Windows\Assembly sorted it out – I guess this refreshed the version of EnterpriseServices that the program was using.

Note that the …wrapper part was not copied across – this is generated on the copy (you can see the result in C:\WINDOWS\WinSxS\x86_System.EnterpriseServices_b03f5f7f11d 50a3a_2.0.0.0_x-ww_7d5f3790\

MCSSLib.dll
MCSSLibNet.dll
ourclient.Client.PDA1.exe
and
ourcompany.Comms.WinCE.dll

However once the CAB is installed on the device the Comms.WinCE.dll is missing. I still need to find a solution to this.

Also:

Windows Firewall looks like it still manages to block ports when the service is stopped in Win7 (I wonder if this is by design?) I had to open up the port that we use (incoming port, all programs)