Another CLR Refresher

[stanl]

Got tasked with moving data from the Sytel Dialer into ECH Microstrategy. Developed a very small, but fantastic WB script to create the files for upload - to an SFTP site. At that point I felt I could use WINSCP: First checked that it worked through Powershell:

Add-Type -Path "C:\winscp\WinSCPnet.dll"

OK.  Then WB

Code (WINBATCH) Select Expand


assemblydir = 'C:\WinSCP'
ObjectClrOption( 'appbase', assemblydir )
ObjectClrOption ( 'use', 'WinSCP, Version=1.0.7.3446, Culture=neutral' )


which errors with unable to load dll.  My first thought is the version=, but then how do I determine that as the dll is not registered as an assembly.  So, stick with Powershell and call it from WB. Finally, hoping to avoid the fingerprint in the WB sample script:

Code (WINBATCH) Select Expand


If IsDefined(Sftp)
   objSessionOptions.SshHostKeyFingerprint = "ssh-rsa 1024 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx" ;REQUIRED by SFTP     ; MODIFY TO FIT YOUR NEEDS
EndIf


I am going to try

$sessionOptions.GiveUpSecurityAndAcceptAnySshHostKey

and if anyone has any experience with how successful that might be I would appreciate comments.

[td]

The following show how to load the assembly:

http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/dotNet/Third~Party~Components/WinScp+SFTP~using~WinSCP~dotNet~.txt

But then...

[JTaylor]

Just right-click on the DLL, Properties and Details.  It shows the File Version there.

Jim

[stanl]

Just right-click on the DLL, Properties and Details.  It shows the File Version there.

Jim

DOIT :o     Need coffee. Thanks Jim.

[stanl]

Well tried both the version and file version of the .dll but just get the attached error. But no problem just sticking with running a .ps1 from WB; generic code and since the .ps1 is text can either load or create from scratch.

[td]

The assembly file version is not necessarily the same thing as the assembly version.  If you look at any of the assemblies stored in the GAC, you will see the difference.  Also, you don't need to use the version information with non-GAC assemblies.  And with the latest version of WinBatch you don't need to use it with any assembly.

Code (winbatch) Select Expand

ObjectClrOption( 'appbase', DirScript() )
ObjectClrOption('use','WinSCPnet')

[td]

And the following works with the the latest WinSCP assembly:

Code (winbatch) Select Expand

ObjectClrOption('use','WinSCPnet, Version=1.3.7.7601, Culture=neutral')

[stanl]

The assembly file version is not necessarily the same thing as the assembly version.  If you look at any of the assemblies stored in the GAC, you will see the difference.  Also, you don't need to use the version information with non-GAC assemblies.  And with the latest version of WinBatch you don't need to use it with any assembly.

Code (winbatch) Select Expand

ObjectClrOption( 'appbase', DirScript() )
ObjectClrOption('use','WinSCPnet')

Yep, ignore the version etc... and works.  Thanks.  I think in this instance I would prefer a pure WB solution over Powershell because I get more visibility over the results.

[JTaylor]

I used the File Version and it works fine for me.

Jim

[stanl]

I used the File Version and it works fine for me.

Jim

This being a company computer where I have limited admin rights, there may be some unknowns because I tried a connection from home in WB studio with version info and it worked. Something to be said about WB's flexibility ;D

[td]

As a general rule I don't use version information when loading assemblies unless I am using functionality that is only available in a specific version.   

[JTaylor]

Understood.  I was just responding to the original question and that I only mentioned using the file version in this case because I knew it worked.  Deana's post was in response to a question I had about using WinSCP, if I remember correctly.

Jim