Loading ...
Sorry, an error occurred while loading the content.

Re: [ASCOM] Re: ASCOM Platform 5.0 Beta 3

Expand Messages
  • Bob Denny
    ... I love this throwback to the 70 s... error 2869 - Please use Google to figure out what it really means :-( Well, after some Google-ing:
    Message 1 of 41 , Jan 2, 2008
    • 0 Attachment
      > Trying to install Platform 5.0 Beta 3 on several Vista machines I get
      > the following error:
      > "The installer has encountered an unexpected error installing this
      > package. This may indicate a problem with this package. The error
      > code is 2869"
      > installation was on machines with no previous versions of ASCOM
      > installed. Any suggestions as to what the problem could be?

      I love this throwback to the 70's... "error 2869 - Please use Google to figure
      out what it really means" :-( Well, after some Google-ing:


      Look familiar?

      Meanwhile, the workaround is to turn off User Account Control, do the
      installation, then turn it back on. Check out the "things going on".

      Turns out I just spent the day "solving" another problem with the Platform
      installer, and I am up to speed. And that article appears to have a good
      solution. We'll see...

      -- Bob

      PS: As always "it shouldn't be this hard"...
    • tsatham
      Hello Ray, I absolutely agree with all points you mention , and I don t believe the ASCOM cross-platform in any way and tying ASCOM to .NET is not the best
      Message 41 of 41 , Feb 5, 2008
      • 0 Attachment
        Hello Ray,

        I absolutely agree with all points you mention , and I don't believe
        the ASCOM cross-platform in any way and tying ASCOM to .NET is not the
        best solution .


        --- In ASCOM-Talk@yahoogroups.com, "Ray Gralak" <rgr@...> wrote:
        > > Late binding is simply not necessary in the .NET world. For
        > > compatibility, late binding is provided by COM Interop, so drivers
        > > written in .NET still work from scripting hosts such as WSH. I've done
        > > it; it works.
        > I think you're missing the point... the _only_ reason a .Net driver
        works is
        > _because_ it can provide a late bindable interface. <G> But just
        because it
        > CAN provide one doesn't mean it should be the only way or even the
        best way
        > to write a driver. I think there are better, more efficient ways.
        > > Your statement "there is no benefit to using .Net for late binding" is
        > > correct but rendered obsolete by the fact that there is no
        > > NEED for late binding.
        > Yes there is a NEED. From a client application perspective there are
        > applications built that use late binding. And late binding is not just
        > needed, it is required. Even if the ASCOM platform was written in
        .Net it
        > still, behind the scenes needs to connect to drivers via Late binding.
        > > Scripting languages and non-dotNET languages get late binding
        > > from COM Interop. I think we are essentially saying the same thing but
        > > from very different perspectives.
        > I am not sure we are. :-)
        > > If you're thinking that late binding is needed for backward
        > > compatibility, that's not correct, because COM Interop provides that
        > > too.
        > This statement makes no sense to me. The .Net interface has to be late
        > bindable. To be late bindable the .Net framework builds the internal COM
        > interop. It's not "COM interop" building itself. .Net creates and
        *uses* COM
        > interop. This seems contradictory to your statement above: "Late
        binding is
        > simply not necessary in the .NET world"!
        > > In platform 5 we have tools to wrap late-bound drivers in an
        > > interface. At some level, new stuff still has to work with older
        > > drivers, but just as we hide device specific details in
        > > drivers, so the exact binding mechanism can and should be hidden
        by the
        > > platform and the toolkit of wrapper classes it provides. You just
        > need those PIAs
        > > to do any of that.
        > .Net is just a framework, like MFC. One could build ASCOM with ONLY
        PIAs (oh
        > yea, that's already been the case! :-)
        > > The argument that COM is "built in" and .NET isn't is specious. A year
        > LOL! WinXP, the latest operating system from Microsoft that *works* with
        > most ASCOM applications, has COM is embedded in the O/S. So does
        Vista. You
        > have to install .Net in XP. Vista includes .Net, but just like MFC,
        it is
        > just another framework. And BTW, the .Net framework uses COM interop
        > the covers quite substantially in areas. And MFC still is a supported
        > framework (with quite a number of enhancements coming).
        > .Net, like MFC, certainly abstracts away a lot of O/S detail but do
        not be
        > fooled into thinking that a ".Net only" solution is always the best
        > solution...
        > http://msdn2.microsoft.com/en-us/library/ms953313.aspx
        > > ago that would have held water but not now. At some point COM
        > > was a new
        > > technology (1993) and wasn't part of Windows for eight years (1985).
        > > Although the .NET framework was initially a separate install, it is
        > > certainly "built in" to Windows Vista and is now just as much
        > > a part of
        > > Windows as COM is. Microsoft is so totally committed to .NET
        > > that you'd
        > > better believe it is a first class operating system component.
        > But not quite as first class as COM it seems because you have to
        elect to
        > install the .Net framework on XP, even today.
        > Here's a couple points to put things in perspective:
        > * COM could (and does) run without .Net installed
        > * .Net would have some functional holes if COM interop was not
        > available.
        > > Your cross-platform ideal is interesting. ASCOM has historically been
        > > tied to Windows, however I think the best bet for
        > > cross-platform support
        > > also lies with the .NET Framework and it's clones such as the Mono
        > > project, which offer the potential to extend ASCOM to Linux and Apple
        > > hosts. This is a prospect that could really multiply the
        > > penetration of
        > > ASCOM because no-one else is really offering a cross-platform
        > > alternative at the moment. Microsoft is also doing some interesting
        > > stuff such as Silverlight which extends .NET to web
        > > applications across
        > > multiple browsers and OSes. This is another reason to start with .NET
        > > interface definitions - because tying ASCOM to COM will scupper
        > > cross-platform possibilities. [side note: technically COM isn't unique
        > > to Microsoft but in practice it pretty much is.]
        > I don't believe the ASCOM cross-platform "answer" lies in a complex
        > development environment like .Net, which has quite a bit of baggage and
        > probably major cross-platform incompatibilities. I think a lighter
        > approach using C or C++ and open sourcing a telescope/camera/etc.
        > would be much easier to implement portably and bring many more software
        > developers to the table.
        > -Ray
      Your message has been successfully submitted and would be delivered to recipients shortly.