Re: [ASCOM] Re: ASCOM Platform 5.0 Beta 3
> Trying to install Platform 5.0 Beta 3 on several Vista machines I getI love this throwback to the 70's... "error 2869 - Please use Google to figure
> 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?
out what it really means" :-( Well, after some Google-ing:
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...
PS: As always "it shouldn't be this hard"...
- 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
> _because_ it can provide a late bindable interface. <G> But just
> CAN provide one doesn't mean it should be the only way or even the
> 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
> 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
> interop. This seems contradictory to your statement above: "Late
> 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
> > 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
> 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
> have to install .Net in XP. Vista includes .Net, but just like MFC,
> 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
> fooled into thinking that a ".Net only" solution is always the best
> > 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
> 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
> > 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.