ecowin pro 6 – The knack

This is a repost of an old-blog article. This still applies to App-V 5.0, and as far as I remember – this content is not published anywhere else.

Since about 2009 and when I first replied to a thread regarding a “common” issue with sequencing a specific software named Ecowin Pro 6, a more or less active pursuit of finding a resolution has been ongoing.

Back in November 2009 Tim Mangan was over having a training session with us and I brought up the issue. Just about the same time the App-v 4.6 RC2 client was released to public and I posted the thread as a bug and got a response. Unfortunately the only response anyone gave was; Yes, its a problem.

Currently a bit jetlagged and trying to convert back normal hours (US v SE). I decided to stay up (landed about 7am and wanted nothing else than to sleep) to revert back the clock to normal – what better task than the above unsolved mystery?

After about 3 hours of various failed attempts and loads of reading among various articles that hopefully would give a hint – something came up. A guy named Jochen had described a solution to making SidebySide local (meaning placing them in the same folder as the application). As the error was similar and related to SxS (see below) a trial has to be made to see if this could possible be the solution. Below is a note from what the Application log showed when attempting to start Ecowin Pro as an app-v package.

Log Name:      Application
Source:        SideBySide
Level:         Error
Keywords:      Classic
Description:
Activation context generation failed for “Q:\ecowin.002\VFS\CSIDL_PROGRAM_FILES\EcoWin\EcoWin.exe”. Dependent Assembly Vinga.vscom90u,processorArchitecture=”X86“,publicKeyToken=”e520fe831c9439c8“,type=”Win32“,version=”1.0.0.55” could not be found. Please use sxstrace.exe for detailed diagnosis.

Jochens approach was to place the needed DLL-file and two manifests referencing it within the same folder as the application.
As I am not a programmer and specifically not the programmer any recompiling was not in question. From my understanding the manifest first created told the executable that it needed an assembly and the second manifest defined where to locate the DLL.

So, first manifest to tell Ecowin where it should get its above Vinga.vscom90u (named ecowin.exe.manifest)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity type="<strong>win32</strong>" name="<strong>Vinga.vscom90u</strong>" version="<strong>1.0.0.55</strong>" processorArchitecture="<strong>x86</strong>"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>

The second manifest telling Ecowin where VScom90u.dll was (named Vinga.vscom90u.manifest)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<noInheritable />
<assemblyIdentity type="<strong>win32</strong>" name="<strong>Vinga.vscom90u</strong>" publicKeyToken="<strong>e520fe831c9439c8</strong>" version="<strong>1.0.0.55</strong>" processorArchitecture="<strong>x86</strong>" />
<file name="<strong>vscom90u.dll</strong>" />
</assembly>

The version, name, type, processorArchitecture, publicKeyToken are all picked up from the original error message. Cross-referencing those with what is captured within the package the following file was located – the folder named contains the file, the version, the processer architecture and that seems to fit pretty good (and the file name seems to ring a bell..)

That file was now copied from its original folder to the same folder as the manifests and the Ecowin.exe

Wrapping up my project and deploying it to the client gave me some hope as a splash-screen showed up – only to reveal the next error message;

For some reason the following registry key came to mind;

<lost screenshot>

Apparently the software notes what operating system it was installed on – just altering the above to (601) gave a new error message;

Extracting the detailed message the following shows

06/28/10 15:36:38 Class not registered [VSCoCreateInstance(progid=EWDBINET2.MtickSeriesListInet2,clsid={EB702F7B-DF8E-4E4D-AE7D-BCC0E48E7105},iid={00000000-0000-0000-C000-000000000046}),CMTickApp::CheckDefaultDB]

So – something is wrong with the datasource specified. Reviewing a process monitor log a reference can be found

Not really knowing the application – this is where some insightful answers would be needed. The error is very application specific and what relevance it has (or not) could perhaps be guessed from the 136 000 process monitor log seen above or simply asked to an application expert.

If anyone cares to explain the above to me – it would be greatly appreciated. I figured out a workaround using some experience, wild guessing and lots of reading.