If you've asked a question, please remember to mark the best answer as 'accepted' by clicking the check mark next to your preferred answer. It looks like the checkmark to the left, and is right under the vote section. You'll gain some reputation and it helps us surface the best content.
1

On attempting to install the TI DIgital DomeWorks driver I get the following error:

alt text

This is with ASCOM 5.5 installed:

alt text

flag

2 Answers

1

Technical Innovations is aware of this problem and is working on an upgrade to the Digital DomeWorks driver that will not only work with ASCOM Platform 5.5 (and future versions) but will also add some attractive new features.

The original TI DDW driver was ground breaking because it was the first ever ASCOM driver to use the (then) new Microsoft .NET technologies. The code targets Microsoft .NET Framework 1.1, which in turn relies upon the Common Language Runtime (CLR) version 1.0. When the framework was updated to 2.0, that also included a new CLR version 2.0. Unfortunately, CLR 1.0 and CLR 2.0 are unable to co-exist in the same process.

The TI DDW driver is an in-process ASCOM driver, so in its current form it can only work with other applications and libraries that also use CLR 1.0. ASCOM 5.5, of course, uses .NET 2.0 and CLR 2.0, therefore the DDW driver is incompatible with Platform 5.5.

The updated version of the DDW driver is likely to target .NET 3.5 and CLR 2.0 and use the ASCOM PLatform 5.5 components. It is also likely to be converted to an out-of-process driver, further shielding it from this compatibility issue and from 64/32 bit issues. This compatibility problem is unlikely to re-occur because later versions of the CLR (2.0 and the imminent 4.0) are able to co-exist within the same process.

To follow progress of the new driver (or indeed to request new features or report problems) please visit http://teamserver.tigranetworks.co.uk:8010

link|flag
0

This appears to be because the Digitial Domeworks driver is targetting Framework 1.1 and not Framework 2.0 or later. The system is looking in \Windows\Assembly\GAC for the Platform 5.5 code, which is actually installed in \Windows\Assembly\GAC_MSIL.

These locations are not acknowledged by Microsoft as the framework and detailed GAC implementation are held to be private to Microsoft and subject to change at any time without notice.

If the Digital Domeworks driver is recompiled under Framework 2, I think it will work OK as the Framework search code will automatically look in the location where 5.5 is actually installed.

link|flag
I wonder if you could clarify something, Peter. I'm running this TI dome driver in the Ascom 5.5 environment without any problems. BUT, it was installed before I updated to 5.5. So, is this an installer problem with the TI dome driver, or is the dome driver working correctly because it's still using assemblies from an earlier Ascom installation? Thanks. Bruce – Bruce Waddington Feb 27 at 2:54
Not being the author of the driver, and not wanting to become the support focus for same.. even though the sources are available I'd rather not recompile and release it. Could this person uninstall Platform 5.5, install the driver, then re-install Platform 5.5? – Bob Denny♦ Feb 28 at 20:40
I've tried this and tested it as far as the setup screen which appears to work fine under 5.5. When I try to connect however my test application locks up and never returns. I'm not sure if this is normal behaviour when no dome is present, but I would have expected a comms timeout to occur. – Peter Simpson♦ Feb 28 at 21:15
There are comm problems in that driver... I fear I'm running things in circles here - I could try this stuff too, so I apologize for my previous question and the resulting work you did on it. I'm going to go away and do my best to help this customer rather than dumping it over the wall here. – Bob Denny♦ Feb 28 at 23:49
@Bob Denny - the order of installation will not fix the problem. The DDW driver does not reference ASCOM.Utilities as it was written years before it. Platform 5.5 is performing this redirection internally and that redirection will occur regardless of the installation order. Unfortunately, this is a compatibility problem between CLR 1.0 and CLR 2.0 - see my answer below for full details. This issue is likely to affect other drivers that targeted .NET 1.1, although I don't think there are that many (if any). This is a great reason to always target the highest available framework version! – Tim Long♦ Mar 13 at 12:26

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.