WinBatch® Technical Support Forum

All Things WinBatch => WinBatch => Topic started by: JTaylor on August 21, 2021, 05:49:51 am

Title: COM/OLE .NET 5.0
Post by: JTaylor on August 21, 2021, 05:49:51 am
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
Title: Re: COM/OLE .NET 5.0
Post by: td on August 21, 2021, 06:56:48 am
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.
Title: Re: COM/OLE .NET 5.0
Post by: td on August 21, 2021, 09:56:57 am
 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.
Title: Re: COM/OLE .NET 5.0
Post by: JTaylor on August 21, 2021, 10:24:00 am
Okay.  Thanks.

Jim
Title: Re: COM/OLE .NET 5.0
Post by: stanl on August 22, 2021, 03:25:16 am
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?
Title: Re: COM/OLE .NET 5.0
Post by: JTaylor on August 22, 2021, 06:18:18 am
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
Title: Re: COM/OLE .NET 5.0
Post by: stanl on August 22, 2021, 10:40:02 am
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
Title: Re: COM/OLE .NET 5.0
Post by: ChuckC on August 22, 2021, 04:41:14 pm
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.

Title: Re: COM/OLE .NET 5.0
Post by: JTaylor on August 22, 2021, 07:36:54 pm
Yeah...the issue seems to revolve around change implemented in .NET 5.


Jim
Title: Re: COM/OLE .NET 5.0
Post by: td on August 23, 2021, 06:58:41 am
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.
Title: Re: COM/OLE .NET 5.0
Post by: stanl on August 23, 2021, 07:21:44 am
Quote from: td on August 23, 2021, 06:58:41 am
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.
Title: Re: COM/OLE .NET 5.0
Post by: td on August 23, 2021, 07:50:20 am
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."
Title: Re: COM/OLE .NET 5.0
Post by: stanl on August 23, 2021, 10:06:50 am
Right... but only Jim's PC would have that knowledge. 
Title: Re: COM/OLE .NET 5.0
Post by: JTaylor on August 23, 2021, 06:18:59 pm
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


Quote from: td on August 23, 2021, 07:50:20 am
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."
Title: Re: COM/OLE .NET 5.0
Post by: stanl on August 24, 2021, 02:46:03 am
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. 
Title: Re: COM/OLE .NET 5.0
Post by: JTaylor on August 24, 2021, 06:10:25 am
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
Title: Re: COM/OLE .NET 5.0
Post by: stanl on August 24, 2021, 06:31:41 am
Quote from: JTaylor on August 24, 2021, 06:10:25 am
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
 
Title: Re: COM/OLE .NET 5.0
Post by: td on August 24, 2021, 07:59:19 am
Quote from: JTaylor on August 23, 2021, 06:18:59 pm
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.
Title: Re: COM/OLE .NET 5.0
Post by: stanl on August 24, 2021, 08:20:17 am
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. 
Title: Re: COM/OLE .NET 5.0
Post by: td on August 24, 2021, 08:28:09 am
Should add that the COM Automation issue will be looked into to verify the cause as time premits.
Title: Re: COM/OLE .NET 5.0
Post by: JTaylor on August 24, 2021, 08:38:25 am
Appreciate it.  Thanks.

Jim

Quote from: td on August 24, 2021, 08:28:09 am
Should add that the COM Automation issue will be looked into to verify the cause as time premits.
Title: Re: COM/OLE .NET 5.0
Post by: JTaylor on August 24, 2021, 08:48:11 am
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

Quote from: stanl on August 24, 2021, 08:20:17 am
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.
Title: Re: COM/OLE .NET 5.0
Post by: JTaylor on August 24, 2021, 08:51:56 am
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
Title: Re: COM/OLE .NET 5.0
Post by: td on August 24, 2021, 08:43:30 pm
It is interesting but not strictly applicable in this case as it is dealing with a different kind of COM usage with .Net.