COM/OLE .NET 5.0

[JTaylor]

I am acting as a middleman here so apologies if this doesn't make sense...I make use of the COM capabilities of an application that has worked fine for 12-15 years now.   The latest version doesn't work though.  The developer is unsure of why it is failing as well.  All his tests with things like VBS work fine.   WinBatch fails on attempting to create the object.   Below is his latest message on the topic.   Does this provide enough info for a useful response? 

"What I’m not sure is if this is due to changes in how .NET 5.0 is implementing COM/OLE.  I know for certain, it’s not supporting COM/OLE 1.0 – but I’m not sure what the implications are for that.  "

Thanks.

Jim

[td]

Sorry but can't offer any additional advice without a lot more information. I do know that the OLE version is not significant in the context of WinBatch and you can't use .NET 5 classes with WinBatch. WinBatch CLR hosting only supports the .Net framework which is part of the Windows OS.

[td]

 Also, COM Automation is a set of COM interfaces that are standardized by MSFT. CCW's (COM Callable Wrapper) are the MSFT implemented functionality that allows .Net managed assemblies to be accessible to COM clients. If MSFT has implemented something in their CCW's that breaks the COM standard that is on them and there is not much we can do about it as their documentation does not provide any information about alternative COM client interfaces. In fact, their documentation suggests quite the opposite.

[edit] Removed some of the awkward sentence structure in the above so that it is at least somewhat sensical.

[JTaylor]

Okay.  Thanks.

Jim

[stanl]

Jim;


Am I wrong is assuming you have a WB script that sets a CLR AppBase to call properties/methods from a dll or similar?

[JTaylor]

I use CreateObject() but have been so focused on that I hadn't thought about going that route.  Not sure if it would work in this situation but it very well might.   This is someone else's project so not sure how they have it all configured.   Thanks for the idea.  I will pursue that thought as well.

Jim

[stanl]

This is where I'm confused. If using CreateObject() shouldn't have anything to do with .NET... but I got sidetracked by Tony's reply about WB and 5.0 .Net classes.....  so thought it was a .Net issue using a COM Object.


Simplest determination I can think of [off-hand]... just try Add-Type in simple Powershell script to see if .dll can be manipulated in .NET

[ChuckC]

Make certain you know what PowerShell you are running before doing so.

Specifically, if you are looking to test a .NET v4.x assembly, you must being running Windows PowerShell [v5.1], otherwise known as the "Desktop" edition of PowerShell, with "powershell.exe" as the executable.  This one is based on .NET Framework.

If you execute "pwsh.exe", you are running PowerShell v6.x/v7.x, which is based on .NET Core, with .NET v5.x being the next release of .NET Core following v3.x.  This edition of PowerShell is also known as the "Core" edition, and cannot use .NET Framework assemblies.

[JTaylor]

Yeah...the issue seems to revolve around change implemented in .NET 5.


Jim

[td]

If you are using only COM Automation, then .Net framework verse .Net 5 shouldn't matter unless the .Net 5 implementation of your application no long supports CCW's for some reason.

[stanl]

If you are using only COM Automation, then .Net framework verse .Net 5 shouldn't matter unless the .Net 5 implementation of your application no long supports CCW's for some reason.

Thanks Tony;


could swing this thread so far off-topic... .net 5 / powershell.   I would expect we go back to basics with WB code for CreateObject() and the resultant error.

[td]

If you have access to a system with the suspect application installed on it, you could use the WIL TypeView to verify the COM Automation object's existence. Generally, COM wrapped .Net objects have type libraries. Look for the exe or one of its DLLs listed on the "Type Libary List" tab.  If you find one listed, click the "View Selected Type Library" button. Scroll down the left-hand tree to the "Classes" leaf and expand it. Expand each class and look for "Programmatic Identifier:" listed in the class description. If the ProgID exists then the class likely supports COM Automation and you should be able to create an instance of the class by placing the ProgID in the drop-down control and selecting "Get Members". If that works then the class supports COM Automation and is usable in WinBatch as a COM Automation object. If not then "Houston we have a problem."

[stanl]

Right... but only Jim's PC would have that knowledge. 

[JTaylor]

They are listed but I get the "Unable to find a Type Library" and then "The Type Viewer has encountered a systen error.  Please contact..."    (typo there if you want to fix it).

MarcEdit is the application, if interested in downloading.    If you are open to corresponding with the developer I can give him your info.   Me as the middle-man probably won't be very productive.

Some scripting languages still work but some, like WinBatch, doesn't.   Powershell 7x works but 5 doesn't (seems like that is known thing.)   VBScript and PERL works.  Probably others.

Jim

If you have access to a system with the suspect application installed on it, you could use the WIL TypeView to verify the COM Automation object's existence. Generally, COM wrapped .Net objects have type libraries. Look for the exe or one of its DLLs listed on the "Type Libary List" tab.  If you find one listed, click the "View Selected Type Library" button. Scroll down the left-hand tree to the "Classes" leaf and expand it. Expand each class and look for "Programmatic Identifier:" listed in the class description. If the ProgID exists then the class likely supports COM Automation and you should be able to create an instance of the class by placing the ProgID in the drop-down control and selecting "Get Members". If that works then the class support COM Automation and is usable in WinBatch as a COM Automation object. If not then "Houston we have a problem."

[stanl]

Wow. Interesting. So for Powershell works with Core, not Framework. If it works with VbScript be curious if using

Code: Winbatch

oS = CreateObject("MSScriptControl.ScriptControl")
oS.Language = "VBScript"
 

is worth the effort. 

[JTaylor]

Might be.   C# works so using the in-memory compiler works as well and I have already started down that familiar path but curious if that might be easier???   Not sure how easy passing text back and forth would be.   Can't recall having used this control much, if at all.   Will take a look.

Appreciate the suggestion.


Jim

[stanl]

Might be.   C# works so using the in-memory compiler works as well and I have already started down that familiar path but curious if that might be easier???   Not sure how easy passing text back and forth would be.   Can't recall having used this control much, if at all.   Will take a look.

Appreciate the suggestion.


Jim

Here is a sample with return value [dated 2018].

Code: Winbatch

#DefineFunction Datediff(d1,d2,interval)
retval=""
oS = CreateObject("MSScriptControl.ScriptControl")
oS.Language = "VBScript"
oS.AllowUI = @FALSE
retval=oS.Eval(: 'DateDiff("%interval%", "%d1%", "%d2%",7,3)')
;oS.Eval(: 'SetLocale(%l%)')
oS = 0
Return(retval)
#EndFunction




d1="1/1/2018"
d2="9/30/2018"
interval="ww"




Message("Weeks from ":d1:" to ":d2,Datediff(d1,d2,interval))


Exit
 

[td]

They are listed but I get the "Unable to find a Type Library" and then "The Type Viewer has encountered a systen error.  Please contact..."    (typo there if you want to fix it).

MarcEdit is the application, if interested in downloading.    If you are open to corresponding with the developer I can give him your info.   Me as the middle-man probably won't be very productive.

Some scripting languages still work but some, like WinBatch, doesn't.   Powershell 7x works but 5 doesn't (seems like that is known thing.)   VBScript and PERL works.  Probably others.

Working with VB Script doesn't indicate much. Much like Powershell it ships as part of the OS and could have any number of unpublished modifications specific to the version of the OS. The WIL Type View is just doing its job when it reports a system error (except for the Typo of course.)  Since this is not a common problem, WinBatch COM Automation is written to the standards, and it works with hundreds of other COM Automation servers including on Windows 11, the cause will have to remain a question mark for now.
 
[edit] Thinking about it some more, the Type Viewer error may explain part of the issue. Unlike other COM Automation clients, WinBatch relies on a type library to convert parameters and return values to and from WIL internal variable types. This means that if a COM object's type library interface has a bug WinBatch will encounter it but other clients will not.

[stanl]

At least this thread introduced me to .mrk file type.  The MarcEdit seems like a pretty complete package and has its own scripting wizard. I'm still a little dense on how WB figures in... (1) trying to read .mrk files? (2) trying to automate the Wizard? (3) working with XML/Json metadata? (4) other?


You mentioned that inline compiled C# is workable. Sounds interesting. 

[td]

Should add that the COM Automation issue will be looked into to verify the cause as time premits.

[JTaylor]

Appreciate it.  Thanks.

Jim

Should add that the COM Automation issue will be looked into to verify the cause as time premits.

[JTaylor]

Yes.  MarcEdit has been around a long time and is used by 1,000's (10s of thousands?) of libraries.    I distribute an [WinBatch] application used by a number of libraries that facilitates collection development and purchasing.   Part of what interfacing the two via COM accomplishes is that a library can obtain, create and/or modify MARC records (the standard for library data) to include the copy and order information for new books.   Info that my application retrieves.   This allows them to add records to their library system and populate purchase orders using the "standard" for such things.  A HUGE time saver for libraries.  This also allowed me to skip the "reinvent the wheel" step in my application.

Jim

At least this thread introduced me to .mrk file type.  The MarcEdit seems like a pretty complete package and has its own scripting wizard. I'm still a little dense on how WB figures in... (1) trying to read .mrk files? (2) trying to automate the Wizard? (3) working with XML/Json metadata? (4) other?


You mentioned that inline compiled C# is workable. Sounds interesting.

[JTaylor]

Also, I am sure you have read this but for what it is worth...

              https://github.com/dotnet/core-setup/blob/master/Documentation/design-docs/COM-activation.md


jim

[td]

It is interesting but not strictly applicable in this case as it is dealing with a different kind of COM usage with .Net.