OLE Automation

[Jonathan Wood]

Greetings,

I don't know if anyone here is writing applications that implement OLE
Automation but I was hoping to have a bit of a discussion about it.

I'm looking at implementing script support for one of my applications
(written using MFC). There's a fair amount of code for doings this and I
expect it to be pretty straight forward. However, if my program used OLE
Automation for scripting, users could pick their language of choice, which
will surely be more full-featured than any script language I come up with.

But the problem is that Microsoft seems to be phasing out COM. Yes, I
realize there is much support for COM still out there, including Visual
Basic. But for new code, I'd like it to remain viable as long as possible.
Visual Basic is being discontinued. I really don't understand what is
involved in writing a script (COM or otherwise) from .NET languages.

So I'm trying to understand:

1. What kind of support would there be for writing COM scripts for the
foreseeable future?

2. Even if I embraced .NET, what would my automation look like then? (Note
that I have no interest in including a .NET within my application.)

3. What other options do I have (besided implementing my own scripting
language).

Thanks for any comments. I've trying to include the most relevant newsgroups
in this.

 

[stax]

2. Even if I embraced .NET, what would my automation look like then? (Note
that I have no interest in including a .NET within my application.)

You would build a .NET COM server which would use the .NET class library
to compile and invoke the automation client code. It should be noted
that once the assembly is compiled and loaded it cannot be unloaded
unless you are using a seperate AppDomain that can be unloaded.

 

[Mercury]

..Net 2005 will be great. You ill be able to incorporate scripting there at a
drop of the hat.

 

[Jonathan Wood]

Robert,

COM is not phased out at all, and .NET apps, especially when using
VB.NET, are great COM clients.

Well, as I see it, .NET was designed to use something different than COM.
But COM support was added because of the amount of COM interfaces already
out there.

I'm not sure why you say .NET apps are great COM clients. I realize they
have interoperability with COM. But I'm not sure how that makes them a great
COM client.

The same you already know about.

That's really not quite true. Visual Basic is definitely not a language to
be working on for the foreseeable future. (Note that I am not talking about
the very different language, Visual Basic .NET). Microsoft has said they
will stop further development on it.

Thanks.

 

[Jonathan Wood]

You would build a .NET COM server which would use the .NET class library
to compile and invoke the automation client code. It should be noted
that once the assembly is compiled and loaded it cannot be unloaded
unless you are using a seperate AppDomain that can be unloaded.

Err... not sure if I got all that. Are you talking about writing a
go-between module in .NET?

Either way, I'm not looking to write any .NET stuff at this time. It does
not make sense for my needs. So I'm not sure I this would help.

Thanks.

 

[Jonathan Wood]

I'm not sure what this means. How would that help with an application
already written in MFC?

 

[Mercury]

hmmm. Good question. I would consider recompilation of your app with /CLR
switch since you can compile MFC with CLR then add in .net functionality
where and when you want. EG you can add just 1managed class (only 1 would be
a most marginal justification) and in .net implement the scripting support.
Another .net class could expose the Application and other claases expose
other objects in your model interfacing quite seemlessly to your current MFC
code.

The pure C++ /MFC code results in stock binary code which sits in the .exe
alongside the CLR stuff - if you have any. I am not sure when CLR itself
would become a dependancy IE if you had no managed code at all if .net
runtime wouldbe needed at start up.

The one thing not to do is to for unmanaged to call managed in performance
critical loops as there is an overhead to CLR generated by the compiler on
each interface call. OLE already has bigger overheads.

Deploying .net runtime may seem a pain, but soon, very soon it will be on
most PC's as it takes only 1 app to require it. XP comes with it. Very soon?
Take a look at VC2995 /8 and see for yourself how hot it is. People will
want to get onto a supported runtime and start taking advantage of the many
many advantages of VS2005 and all it entails. Quaility of GUI is still to be
commented on.

That's my theory... haven't tried this specific notion, but vc2005 is so
good.

Either that or look at VBA - mind you, last I looked it had *big* overhead
cost.

 

[Tim Brooks]

John,

I'll steer clear of some of the foregoing philosophising and just point out
that there have been some excellent examples in MSDN magazine from Paul
DiLascia recently that might show you the way to leverage .Net languages
from a native MFC app -- obviously would require .Net on the client -- or a
remote server -- but still allow your app to remain native...

Have had a need to try it myself but looking to do so shortly...
Check out.....
http://msdn.microsoft.com/msdnmag/issues/05/04/C/
http://msdn.microsoft.com/msdnmag/issues/05/07/CAtWork/
http://msdn.microsoft.com/msdnmag/issues/05/02/CATWork/ (an interesting Q
about managed extensions)

Got to MSDN and also do a search under Paul's name. He's done a lot on
wrapping .Net from natvie code.

Also, on using other languages between platforms (CLR - Native), look at:
http://msdn.microsoft.com/library/d...v_vjsample/html/vjsamcrosslanguagesamples.asp

Finally, just do a search on MSDN under managed extensions and you'll find a
blizzard of potentional material.....I personally find Paul's stuff to be
some of the most immediately useful.....

Good luck....

 

[Jonathan West]

Hi Jonathan

COM is going to be around for a good while yet. Windows would collapse into
a muddy heap if COM support turned off.

VBA has already been retained in Office for 2 versions since VB.NET was
launched, and Microsoft has publicly announced that it will still be in at
least the next two versions. Since VBA runs on COM, and the end of the
mainstream support period for the next version-but-one of Office will be at
least 10 years hence, I don't think you need worry about the imminent demise
of COM.

The following is on the Vista Developer FAQ page
http://msdn.microsoft.com/windowsvista/support/faq/default.aspx

What is the future of COM, OLE and in-place activation?
All of COM and OLE that you've come to know and love will live on in Windows
Vista, although it won't be extended. COM and OLE aren't "dead," but they
are "done."


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org

 

[Jonathan Wood]

Mercury,

hmmm. Good question. I would consider recompilation of your app with /CLR
switch since you can compile MFC with CLR then add in .net functionality
where and when you want. EG you can add just 1managed class (only 1 would be
a most marginal justification) and in .net implement the scripting support.
Another .net class could expose the Application and other claases expose
other objects in your model interfacing quite seemlessly to your current MFC
code.

Uh, yes, but doesn't that then mean my app relies on tens of MBs of run-time
library that it does not currently require? That would be a major deal
breaker for me.

The pure C++ /MFC code results in stock binary code which sits in the .exe
alongside the CLR stuff - if you have any. I am not sure when CLR itself
would become a dependancy IE if you had no managed code at all if .net
runtime wouldbe needed at start up.

I'm not sure either.

Deploying .net runtime may seem a pain, but soon, very soon it will be on
most PC's as it takes only 1 app to require it. XP comes with it. Very

soon?

Then I may reconsider that option "very soon." <g> I'm not interested in
eliminating folks without the .NET runtimes as potential customers.

XP comes with the .NET runtimes? I believe you're mistaken there.

Either that or look at VBA - mind you, last I looked it had *big* overhead
cost.

Well, I don't know the intracacies of VBA, but standard OLE Automation
seemed pretty straight forward to me. It'd be the ideal solution if I didn't
feel some COM development tools were being phased out.

Thanks.

 

[Jonathan Wood]

Robert,

What makes you feel they are *not*? The COM *interoperability*? This
is an integral part of the .NET framework. Many .NET components
actually rely on COM interop. You're not alone ;-)

Well, I was looking for evidence that it is a good COM client rather than a
lack of evidence that it wasn't. Many of the talking points of .NET have
centered on how some of the issues with COM are no longer issues with .NET.

At any rate, I guess I'll just take your word for it that writing a COM
client with .NET is just dandy. I'm still uneasy that Microsoft is pushing
folks away from COM though. I appreciate your input but would really like to
see additional information on this very topic.

Thanks.

 

[Jonathan Wood]

Tim,

I'll steer clear of some of the foregoing philosophising and just point out
that there have been some excellent examples in MSDN magazine from Paul
DiLascia recently that might show you the way to leverage .Net languages
from a native MFC app -- obviously would require .Net on the client -- or a
remote server -- but still allow your app to remain native...

Thanks, I'll check that out. However, the requirement of .NET on the client
has so far been a deal breaker for me. Sales aren't so good that I want to
eliminate a large number of people as potential customers.

 

[Jonathan Wood]

Thanks for the references Jonathan. You know, I remember the MS engineers
recommending that I add a .NET layer to my MFC apps for automation. I do
find it interesting that they haven't yet done the same.

 

[Mercury]

You said "Thanks, I'll check that out. However, the requirement of .NET on
the client
has so far been a deal breaker for me. Sales aren't so good that I want to
eliminate a large number of people as potential customers."

In a sales situation, this topic should not really come up at all - try Java
if you want a shocker! Once upon a time VB runtimes were regarded as huge.
Crystal Reports run time was disproportionatly huge... but if the
application was worth the retail price, these 'huge' runtimes ceased to have
*any* importance at all.

What are the issue? No support for Win95? Fear of a 'large' download? I can
only guess.

The installation of .net runtime on systems is inevitable IMO. Anyone that
purposefully sets out on a course of declaring they will never have it is
probably the mentality of customer you don't want anyway. I do believe in
minimalism and look for strong justification for every piece of s/w I
install - this is just common sense.

I can understand some hesitancy...A 1.0mb .exe with many times that in
runtime may seem expensive. However memory is cheap, disc space i cheap.
Issue media is either CD / DVD or the net... The runtime only needs to be
installed once.

I do recall a comment from you about using static linking - by far most
dev.are using dynamic and are happy with it.

What are the issues you perceive or are fed back from your prospects?

 

[Jonathan Wood]

Mercury,

You said "Thanks, I'll check that out. However, the requirement of .NET on
the client
has so far been a deal breaker for me. Sales aren't so good that I want to
eliminate a large number of people as potential customers."

In a sales situation, this topic should not really come up at all - try Java
if you want a shocker! Once upon a time VB runtimes were regarded as huge.
Crystal Reports run time was disproportionatly huge... but if the
application was worth the retail price, these 'huge' runtimes ceased to have
*any* importance at all.

I'm not sure I follow. Are you saying that tens of MBs of runtime should not
be an issue at all when considering sales? If so, we'll just have to
disagree. I'd consider this an issue even if customers were not downloading
the software over the Web.

I've distributed thousands of VB programs, and I've dealt with the support
issues of various problems and incompatibilities associated with the
collection of shared support files.

What are the issue? No support for Win95? Fear of a 'large' download? I can
only guess.

1. Large downloads.
2. Increased complexity (which equals increased potential for support
issues).

The installation of .net runtime on systems is inevitable IMO. Anyone that
purposefully sets out on a course of declaring they will never have it is
probably the mentality of customer you don't want anyway. I do believe in
minimalism and look for strong justification for every piece of s/w I
install - this is just common sense.

If it is such common sense, I do not understand the push for me to shift to
..NET. I've sat down with Microsoft engineers and told them my concerns about
distributing .NET runtimes with shareware and other downloads. After all the
hoopla, they simply told me that perhaps .NET doesn't make sense for me at
this time. I must agree with them. If .NET justifies requiring your
customers to install an additional tens of MBs of runtime, then by all
means, use .NET. .NET doesn't come close to justifying this extra overhead
for me.

I do recall a comment from you about using static linking - by far most
dev.are using dynamic and are happy with it.

I'm not out to convince anyone. I'll only say that I use static linking and
*I* am happy with it.

 

[Mercury]

inline...

Mercury,


I'm not sure I follow. Are you saying that tens of MBs of runtime should
not
be an issue at all when considering sales?

Yes. Yes. Yes. RT's (and libs, DLL's) give functionality. If you don't use
an RT or static linking then how do you add a lot of functionality to an app
unless you write every line yourself? That heads down the unprofitable path.

For the types of apps I do (none are shareware at the moment although I am
thinking about the trialware / freeware approach for many of the utilities I
have written) which are predominantly substantial, the overhead of .Net RT
is still 'large', but trivial as it is a once only install for each version.

You seem to ignore that at the moment MFC has a runtime. IMO the OLE
components were the most vulnerable.

If so, we'll just have to disagree.

A while back you were being very insistent on writing in assembler /
optimising code to the n th degree. this follows the same pattern - no
offence but it is a very dated approach.

I'd consider this an issue even if customers were not downloading
the software over the Web.

I know people *do* toss out s/w when they download from the web and find
hidden surprises. I have. EG on my dev.system I won't install Java. I hate
Java apps, their slowness and aged design - but thats me. I have no choice
for Java on the servers for UPS and other support and this really erks me as
it is usully only 1 app on a given server that requires the huge runtime
(the memory footprint).

I think it is really important to say up front if your app needs .Net RT in
a place a peron will read it prior to downloading. This pre-empts p**ing off
prospects.

..Net RT is inappropriate for small (in internal functionality) utilities...
to be downloaded from the net. IE if you use none / v.little of any of the
more sophisticated .Net RT capabilities and the app is small then I agree
with you.

I've distributed thousands of VB programs, and I've dealt with the support
issues of various problems and incompatibilities associated with the
collection of shared support files.

..Net RT avoids most of this as the install location and files are
controlled.

Support issues are v.important... but then I have never really had any with
run-times for systems that I build. Mind you I sell to financial outfits and
impose requirements for security, admin, desktop lockdowns and so on. I use
a conservative methodology (minimalism) that requires very little runtime
support. MFC runtime is stock as is ODBC that doesn't leave much else.

1. Large downloads.
2. Increased complexity (which equals increased potential for support
issues).

I agree that unnecessary complexity must be avoided, but I don't see .Net RT
as a complexity - it is a jutifiable requirement. This is perhaps also
because of the confidence that has grown in it over time.

I see .Net RT as reducing complexity (particularly with VS2005) due to the
very many advanced classes there for use that are "debugged" already (with a
very low incidence of bugs too) - you write less lines of code to do the
same thing = less chance of bugs.

If it is such common sense, I do not understand the push for me to shift
to
.NET.

No push. There are easy ways to do things and expensive ways (time coding
wise).

I (and others) provided a viable solution that uses .Net and is simpler to
implement in .Net (that is what happens to COM in .Net - it becomes so
simple).

I recommend trying the following:

1. Get RC1 of VS2005
2. Build a simple MFC app in VC6.
3. Convert the project (IE open it)in VC8.
4. Compile
5. Convert to CLR.
6. Add a managed class and learn how *easy* it is to integrate.
7. Expose some COM - its easy see Interface.
8. Follow through on the links others have provided.

I've sat down with Microsoft engineers and told them my concerns about
distributing .NET runtimes with shareware and other downloads.

Ok, I know what they are like. I had a drastic conversation with an MS Dev
Product manager in Sydney a while back saying that there was no way I would
convert systems to current VS versions (IE not the coming VS2005) because of
the huge quantity of work involved. In this case MS must have heard what
many many were saying as this issue is *solved* in VC8.

After all the
hoopla, they simply told me that perhaps .NET doesn't make sense for me at
this time. I must agree with them.

I think you had decided that already.

If .NET justifies requiring your
customers to install an additional tens of MBs of runtime, then by all
means, use .NET. .NET doesn't come close to justifying this extra overhead
for me.

It is not .Net justifying anything...
I think you mean If your App justifies .Net RT for web download then it is
not an issue?

I'm not out to convince anyone. I'll only say that I use static linking
and
*I* am happy with it.

Sorry, what I was meaning is that use of RT's is a dynamic loading style of
programming as opposed to static. .Net does the same, so I was trying to
empathise with a parallel. IE static = no RT, non static = RT of some sort.

This is *supposed* to be an eye opener for you. When you pop open the VS2005
/ VC8 box and take a good like there is a diabolical amount of functionality
there to use when programming (ignoring the IDE). There i o much tht you do
have to pause for a while and think about how you / we all program to ensure
that you write less & better code and produce more functionality in less
time.

So, .Net RT should come last in sales (really should) - if the app justifies
its use then use it. If a person looks at an App on your web site and goes
'wow' at the functionlity in 1 app & its shareware "so what it needs .Net
RT". That is my point.

 

[Jonathan Wood]

Mercury,

Yes. Yes. Yes. RT's (and libs, DLL's) give functionality. If you don't use
an RT or static linking then how do you add a lot of functionality to an app
unless you write every line yourself? That heads down the unprofitable

path.

Yes, *IF* the runtimes include functionality that you require. That's an
awful big IF that you don't seem to even be including in your discussion.

You seem to ignore that at the moment MFC has a runtime. IMO the OLE
components were the most vulnerable.


I think you had decided that already.

Are you questioning my account of what they told me?

A while back you were being very insistent on writing in assembler /
optimising code to the n th degree. this follows the same pattern - no
offence but it is a very dated approach.

And no offense, but the .NET runtimes include hand-optimized assembly
language as well. So .NET is pretty dated, eh? Not everyone is under the
opinion that Microsoft is the only company that can use assembler. You know
nothing about the projects I'm working on. You're just pushing .NET to the
point where it's just silly.

 

[Mercury]

Yes, *IF* the runtimes include functionality that you require. That's an

awful big IF that you don't seem to even be including in your discussion.

read my post.

 

[Jonathan West]

Thanks for the references Jonathan. You know, I remember the MS engineers
recommending that I add a .NET layer to my MFC apps for automation. I do
find it interesting that they haven't yet done the same.

Oh, they have - Office 2003 comes with Primary Interop Assemblies -
essentially a .NET wrapper for the COM objects that are accessible to the
outside. But it's still COM underneath.


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org

 

[Willy Denoyette [MVP]]

Oh, they have - Office 2003 comes with Primary Interop Assemblies -
essentially a .NET wrapper for the COM objects that are accessible to the
outside. But it's still COM underneath.


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org

Just a small correction, the Interop Assemblies are not wrapping anything,
they only contain the metadata (.NET extended typelib info) needed by the
COM interop layer in the CLR to create the actual wrappers (RCW and CCW).
The real COM wrappers are CLR created/managed objects, whenever you create
an instance of a type defined in the IA, or whenever you enter the CLR from
native COM, the CLR emits a wrapper object (one per object instance).



Willy.