Author Topic: some basic dotnet questions  (Read 5153 times)

kdmoyers

  • Full Member
  • ***
  • Posts: 227
some basic dotnet questions
« on: July 01, 2013, 09:25:49 am »
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
  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
 
The mind is everything; What you think, you become.

Deana

  • Wilson WindowWare Tech Support
  • Pundit
  • *****
  • Posts: 1183
  • WinBatch® can do it.
    • WinBatch Tech Support Database
Re: some basic dotnet questions
« Reply #1 on: July 01, 2013, 10:09:03 am »
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.


Deana F.
Technical Support
Wilson WindowWare Inc.

kdmoyers

  • Full Member
  • ***
  • Posts: 227
Re: some basic dotnet questions
« Reply #2 on: July 01, 2013, 11:35:06 am »
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!
The mind is everything; What you think, you become.

td

  • Tech Support
  • *****
  • Posts: 2618
    • WinBatch
Re: some basic dotnet questions
« Reply #3 on: July 01, 2013, 01:20:01 pm »
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.
"Success is a lousy teacher. It seduces smart people into thinking they can't lose."
  - Bill Gates


kdmoyers

  • Full Member
  • ***
  • Posts: 227
Re: some basic dotnet questions
« Reply #4 on: July 02, 2013, 06:51:05 am »
Quote
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!

Quote
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
The mind is everything; What you think, you become.

DAG_P6

  • Full Member
  • ***
  • Posts: 184
  • WinBatch rocks, and so does Wilson WindowWare!
    • WizardWrx
Re: some basic dotnet questions
« Reply #5 on: July 03, 2013, 06:32:35 pm »
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.
David A. Gray
You are more important than any technology.

stanl

  • Pundit
  • *****
  • Posts: 796
Re: some basic dotnet questions
« Reply #6 on: July 04, 2013, 03:23:10 am »

kdmoyers

  • Full Member
  • ***
  • Posts: 227
Re: some basic dotnet questions
« Reply #7 on: July 04, 2013, 07:36:08 am »
Cool! thanks guys!
The mind is everything; What you think, you become.

td

  • Tech Support
  • *****
  • Posts: 2618
    • WinBatch
Re: some basic dotnet questions
« Reply #8 on: July 04, 2013, 10:31:51 am »
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. 
"Success is a lousy teacher. It seduces smart people into thinking they can't lose."
  - Bill Gates