some basic dotnet questions

[kdmoyers]

I have a couple questions about the short code sample below (making a Function out of the recently posted GUID example).

1. Should any objects be dropped to clean up? Not sure if these fancy new dotnet objects need to be dropped.

2. Am I correct that the objectClrOption statement should only be done once per program execution? (and is therefore outside of the function)

Thanks!
-Kirby

Code (winbatch) Select Expand

  objectClrOption( 'use', 'System.Net, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' )

  #definefunction GetGUID()
    ; Construct a guid using any random guid as a constructor parameter.
    strGuid = "{D28AC658-2D3C-4111-B297-1E7D132F2FE4}"
    oGUID = ObjectClrNew('System.Guid',strGuid )
   
    ; Returns a VT_RECORD and WinBatch does not have built in functionality
    ; to handle this variant type directly.
    rGUID = oGUID.NewGuid()  ; Returns a vt_record
   
    ; However, ObjectClrType can turn it into a regular COM/CLR object
    ; with a little help from the FCL.
    strctGuid = ObjectClrType("System.Guid", rGUID)
    sGuid = strctGuid.ToString()   

    return sGuid
  #endfunction
 
for i = 1 to 10
  Message("String Representation of New Guid", GetGUID())
next i


[Deana]

As I understand it. The doNet functions in WinBatch handle the garbage collection on your behalf, so there is no need to explicitly close any handles. The general advice in the dotNet world is to let the CLR garbage collector handle it for you.  However it is a good idea to use any class object's Dispose or Close method when available.  This gives the object a better chance of being collected in a timely fashion. 

As for the ObjectClrOption question. That is a bit more difficult to answer... This function takes three possible options: Version, AppBase and Use.

When using the Version option, be careful while debugging in WinBatch Studio. Once you load a specific version of the CLR, while in debug mode, the CLR stays loaded until you shutdown WinBatch Studio. Any further requests to load a specific version of the CLR are just ignored. 

Maybe Tonyd will chime in with additional information about the effects of multiple calls to the ObjectClrOption function.

[kdmoyers]

Hmm... well I guess you're right about all these objects being automatic GC dotnet.
I did one hundred thousand iterations of the function call and the intcontrol(77)
values for strings, buffers, variables and objects remained steady throughout,
which I guess means no leaks.
Cool!

[td]

The 'appbase' and 'version' options must be set before the CLR is loaded into the WinBatch process.  There are two ways to load the CLR.  You either call 'ObjectClrOption' with the 'use' option or you call 'ObjectClrNew.'  Fairly simple.

Hmm... well I guess you're right about all these objects being automatic GC dotnet.
I did one hundred thousand iterations of the function call and the intcontrol(77)
values for strings, buffers, variables and objects remained steady throughout,
which I guess means no leaks.
Cool!

I assume you will be checking for leaks like a ship's master in a hurricane from now on...  Anyway, treat CLR objects like you would treat COM Automation object.   If you happen to have a long running script that uses a lot of CLR based object, calling any object Dispose or Close methods may help the garbage collector threads do their job a little more effectively.

[kdmoyers]

I assume you will be checking for leaks like a ship's master in a hurricane from now on.

(chuckle) Aye, ye swabbies... once soaked, twice dry!

calling any object Dispose or Close methods may help the garbage collector threads

So, if it had been available, I might have called strctGuid.Close() ,
but apparently that doesn't exist, so I'm OK to just return from
my function and let the GC work on it's own.

OK I think I've got it.  Thanks!
-Kirby

[DAG_P6]

For the most part, the objects that have Close() and Dispose() methods do so because they use unmanaged Win32 resources, such as files and streams. When I do file I/O, usually in a loop that ends when I have read everything that I need from a file, or written everything I have for it, I try to put the whole loop inside a try/catch/finally block, so that the Close() and Dispose() methods are guaranteed to be called. Since WIL doesn't have try/catch/finally, you will probably need something like the routines I use to close and clean up after regular sequential file I/O, using, e. g., FileRead() and FileWrite(). This involves letting the error handler fall into a block that tests for the existence of filehandle variables, and closes any that are open (nonzero). This block is also the destination of a goto at the bottom of the normal execution path.

[stanl]

and for the technical stuff...

http://blogs.telerik.com/justteam/posts/13-04-02/understanding-net-garbage-collection

[kdmoyers]

Cool! thanks guys!

[td]

For the most part, the objects that have Close() and Dispose() methods do so because they use unmanaged Win32 resources, such as files and streams. When I do file I/O, usually in a loop that ends when I have read everything that I need from a file, or written everything I have for it, I try to put the whole loop inside a try/catch/finally block, so that the Close() and Dispose() methods are guaranteed to be called. Since WIL doesn't have try/catch/finally, you will probably need something like the routines I use to close and clean up after regular sequential file I/O, using, e. g., FileRead() and FileWrite(). This involves letting the error handler fall into a block that tests for the existence of filehandle variables, and closes any that are open (nonzero). This block is also the destination of a goto at the bottom of the normal execution path.

WinBath is predominantly a 'native' application that happens to also host the CLR so the CLR is not the sole arbitrator of resource usage.  In fact, the CLR will usually be just a bit player.  That means the ironic preoccupation with resource usage among the dotNet devotees should not necessarily be projected onto WinBatch.  That said, good programming practice would dictate using the above cleanup methods. However, it is also the case that you can often get by without doing so in WinBatch. 

WinBatch's COM Automation support is a good analogy here.   WinBatch allows users to release COM Automation object by simply reassigning the variable holding the references to the object.  In most cases this is not necessary because WinBatch will automatically release the object as part of the script shutdown process.   This works most of the time but there are certain cases were you need to call a 'Close' method on an object or the out of process server will remain in memory after the script terminates.   

As a side note: Stan has pointed out at least one dotNet case using PowerShell where even the above methods are not sufficient and the GC must be forced to destroy objects holding external resources or they remain as processes on the system.