It looks like we've gotten TPAHTS fully and successfully installed now, at least in our sandbox and test environments. However, while the sandbox installation was (mostly) straightforward, the test installation was really difficult, finally requiring a lot of (invaluable) help from Tessitura support.
What remains a mystery is how the two environments wound up being so different. The issue boiled down to the fact that while ASP.NET 3.5 was installed on both systems, the installation itself was somehow radically different. In our development environment it was installed in the manner and with the libraries that Tessitura expected: namely in C:\Program Files\Microsoft.NET\, and with the file C:\Program Files\Microsoft.NET\Primary Interop Assemblies\adodb.dll, which was the source of our errors. In our test environment (which mirrors our live environment) ASP.NET is installed in C:\WINDOWS\Microsoft.NET, and lacked a "Primary Interop Assemblies" directory.
We're not sure how the installations would wind up so different. Presumably these frameworks were installed using the same Windows Update procedure. We observed that one commonality between the servers being referenced at Tessitura and our dev environment was that they had SQL Server installed on them, while our test and live web servers do not, but do not have anything beyond that.
Our solution to get this running was to create the folder path expected by the "working" .Net installs, containing only the referenced DLL, which we then registered using the appropriate command line tool.
Has anyone else run across this issue, or understand why .NET installations might be so different?
Hi Gawain,
good day.
You can do one of these two things.
1, Copy the adodb.dll into the folder where your ETicketServerServiceLive.exe are.
2, Or install the adodb.dll to GAC.
Current adodb.dll file version is 7.10.3077.0.
GAC version is 7.03300.0.
GAC folder is \windows\assembly.
I think the problem has nothing to do with the .Net upgrade.
the problem came from when the project built up, adodb.dll was forgoten to be included in the output folder.
since it is not in the folder, you have to add them in.
and there are two ways to add them in. they are listed above.
GAC info:
http://msdn.microsoft.com/en-us/library/dkkx7f79(VS.71).aspx
http://msdn.microsoft.com/en-us/library/yf1d93sz(VS.71).aspx
http://msdn.microsoft.com/en-us/library/ex0ss12c(VS.71).aspx
have fun.
Ben
Thanks Ben, that was the solution, and we actually wound up going through just those steps with Tessitura Support last week.
Has anyone else had this issue? My current guess is that this library is installed with Visual Studio, which I had in my development environment (and which, naturally, all the support engineers we talked to at Tessitura had on their systems), but which we do not have on our Test or Live web servers. I think many people may have it installed as a result of having Sql Server installed, which seems to typically included a limited version of Visual Studio. But I would have thought a lot of people would have kept their web server free of extraneous services and software, and therefore would have also tripped this.
I was having this exact same issue in our test environment while testing v9 of print at home. Thank goodness for this thread and Ben's resolution, it was exactly what was needed.