Powershell - CLR [for discussion]

[stanl]

This relates directly to the recent thread on creating emails through EWS using the WB CLR.  When the CLR first became available in WB [circa 2013] - I immediately pushed for integrating it with Powershell and working with Deana there are 1 or 2 scripts in the Tech Database.

The point was never to make PS and alternative to WB, but to see how an easily constructed [or downloaded] PS script could be converted to the CLR. The biggest issue for me (and not faulting the documentation) is to distinguish when and how to use the WB CLR methods.

So, specific to the above referenced thread:

1 or more base assemblies are referenced:

Code (WINBATCH) Select Expand


ObjectClrOption('appbase', cDLL)  ;path and filename of web services dll
ObjectClrOption('useany', 'Microsoft.Exchange.WebServices')   ;then why is this needed???



Then 1 or more specific references are made to an individual class [this I understand the best]

Code (WINBATCH) Select Expand


ObjectClrNew('Microsoft.Exchange.WebServices.Data.ExchangeService')


and there is code to obtain a data type [not part of the PS script I posted]

Code (WINBATCH) Select Expand


ObjectClrType('Microsoft.Exchange.WebServices.Data.ExchangeVersion', nVersion )



If you followed the thread, Tony assiduously worked to bring the script to workable. I tested and tweaked.

So, this post is not for Tony to produce more docs/explanations but to find out how many users on this forum have an interest in the CLR and it's capabilities/limitations.

[td]

I will answer the comment 'then why is this needed?'

WinBatch follows the underlying CLR's interfaces more closely by using separate steps because it is more focused on creating Applications.  Powershell and WinBatch CLR hosting are implemented using completely different technologies so thinking they should work in similar ways is not really valid.  Also Keep in mind that the only time the "appbase" option is needed is when you are loading a non-GAC assembly and it can only be use once per script.  This does mean that all non-GAC assemblies must be in the same directory for a given script but this goes back to the idea of being focused on Applications as defined by MSFT.   

WinBatch CLR hosting must follow the OOP concepts of member overloads differentiated by method signatures and strong typing rules.   That it is does is a kind of amazing given that WIL is a procedural language that is negatively typed.   

To use WIL CLR hosting the concepts of method signatures and strong typing, which aren't all that hard to grasp, do need to be understood.   The other important thing to do is READ THE METHOD DOCUMENTATION before you use it for the first time. The last part can be summed up by the phrase, "do as I say not as I did."     

[....IFICantBYTE]

Stan, I have an interest in the WIL CLR hosting (or at least I did) ... I used it to do a few tricks in scripts in my old job (but now I'm currently unemployed :( and not really using WinBatch at the moment)

[JTaylor]

I use this as well.  Currently, I mostly compile code in Memory so I can call the methods I have defined.

Jim

[stanl]

Stan, I have an interest in the WIL CLR hosting (or at least I did) ... I used it to do a few tricks in scripts in my old job (but now I'm currently unemployed :( and not really using WinBatch at the moment)

Bummer. To be honest, I have had to sneak WB into my last 2 jobs.  That stupid Owl didn't cut it.  You have contributed soooo. much to this site.