ASP.NET

The use of ScriptX Server-side with ASP.NET is essentially as described in the section Server-side Printing, however a number of rules must also be followed when using the component within an aspx page:

1. The page must have the attribute aspcompat=true:

   <%@ Page aspcompat=true ... other attributes ... %>
   

2. Due to lazy release of COM objects by the .NET CLR garbage collection, timely release of the components must be forced or orphaned processes can result. It is also required that a specific reference to the printing object is made so that this can be released properly:

   <script language = "vb" runat = "server">
   Sub ScriptXPrint()
       dim secmgr As Object
       dim factory as Object
       Dim printing as Object
       dim i as Integer
   
       Try
           secMgr = CreateObject("MeadCo.SecMgr")
   
           ' Modify:: Change the following to use the license GUID and
           ' revision supplied to you.
           '
           secMgr.Apply("","{<YOUR LICENSE GUID>}",<YOUR LICENSE REVISION>)
   
           Try
               ' Create the ScriptX object
               factory = CreateObject("ScriptX.Factory")
               ' Get the printing object - this allows for more efficient access
               ' and also enables timely release of the objects
               printing = factory.printing
   
               ' perform some printing
               printing.header = "ScriptX Printing - Printing at the Server"
               printing.footer = "Printed at the server"
               printing.printHTML("http://localhost/default.htm") ' Change this URL to an appropriate page on your server.
           Catch e as Exception
               Response.Write("Print failed: " + e.Message)
           End Try
   
       Catch e As Exception
           Response.Write("Unable to apply licence: " + e.Message + "<br/>")
       End Try
   
       if NOT secMgr is nothing then
           i = System.Runtime.InteropServices.Marshal.ReleaseComObject(secMgr)
               while i>0
                   i = System.Runtime.InteropServices.Marshal.ReleaseComObject(secMgr)
               end while
       end if
   
       if NOT factory is nothing then
           ' Closedown the ScriptX object - *required*
           factory.ShutDown()
   
           ' Now ask .NET to release the objects. There should be only one reference
           ' on each object, but we loop until there are no references just in case.
           i = System.Runtime.InteropServices.Marshal.ReleaseComObject(printing)
           while i>0
               i = System.Runtime.InteropServices.Marshal.ReleaseComObject(printing)
           end while
           i = System.Runtime.InteropServices.Marshal.ReleaseComObject(factory)
           while i>0
               i = System.Runtime.InteropServices.Marshal.ReleaseComObject(factory)
           end while
       end if
       factory = nothing
   End Sub
   </script>
   

The principles of working with ScriptX Server-side and ASP.NET are as expected, independent of the language in use, however the detail of the coding of ScriptX Server-side with ASP.NET varies by language.

The ScriptX Server Side Test and Validation kit is available to licensees to illustrate different techniques (including Classic ASP) and to test and validate the installation. The use of this kit is highly recommended - the kit installs a website with suitable validations and tests in each language.

Required Configuration

After installing the kit, first update the web.config file with your license details and then use Internet Services Manager and modify the installed application:

1. For IIS 5/5.1, set Application Protection to Low (IIS Process), or

2. For IIS 6 and later (Windows Server 2003/2008) set the application pool identity to "Local system" (typically, the SYSTEM account is allowed to launch/access DCOM components but this should be verified or the tests will confuse!).

All appropriate tests should then be run, i.e. all the tests implemented in the language that interests you. These initial tests ensure that the ScriptX components can be accessed and used with the current interactive user (which is known to work because validate.js can be used from the command line by the interative user). A server must not be configured in this way for production since it is both insecure and will fail if the server is rebooted (resulting in no interative account). If these tests are followed, then the steps outlined in the Configuration section must also be followed, in summary:

• To successfully use ScriptX Printing with ASP.NET, the MeadCo TriPrint Server object should be configured to run under a named account as described for ASP deployment, and the IIS application configured as medium or high protection (or an appropriate application pool used).
• In addition, for IIS 5/5.1, the Windows Account "ASPNET" account may need to be added to the list of accounts with default DCOM launch and access rights (if the account does not already have these rights).

 

::> Configuration