|
<< Click to Display Table of Contents >> Navigation: Programming Mechworks PDM > DBWCommandShell > Programmer's Guide > .NET scripting > .NET scripting specifics |
MechWorks Command Shell [OBSOLETE PAGE]
This content is considered obsolete and it is kept for reference on legacy systems only
New installation must refer to the topic .NET API
Mechworks PDM trusts on a custom engine (named DBWCSSUI) for driving the .NET runtime.
This engine needs some extra coding for managing correctly the assembly references.
In order to run scripts, .NET 2.0 must be installed.
Any given .NET assembly has the following major characteristics:
•file name
•assembly name
•assembly module name
•assembly namespace
The naming convention for the .NET framework was always simple: all three are the "same".
•file name: System.Windows.Forms.dll
•assembly name: System.Windows.Forms
•assembly module name: System.Windows.Forms.dll (the original file name embedded into assembly file header)
•assembly namespace: System.Windows.Forms
Microsoft has broken it's own rule with the way how Visual Studio 2005 generates interops: the file name always has prefix "interop." and does not match any more the assembly namespace. What leads to the situation when it is not possible to reconstruct the file name from the assembly namespace (this is what the DBWCSSUI engine does).
The solution is to use the DBWCSSUI explicit loading directive //css_ref : this resolves the loading problem.
About how to reference the namespace from the code, in C# it is resolved through the using directive; VB equivalent is Import.
Thus if you want to use, for example, System.Windows.Forms your code needs to have Import System.Windows.Forms.
In addition to this, VB compiler has it's unique feature imported namespaces which means that you can nominate namespaces to be used not from code but on the compiler level.
This is the reason why you do not have to have Import System.Windows.Forms in the code if you are inside of the VB project: nice feature but inconsistent and creates some confusion.
DBWCSSUI does not pass any extra compiler directives thus you must have Import <namespace> in code if you want to use a particular namespace.
As a final note, renaming of the assembly file is not a very good idea in general as it creates mismatch between Assembly file and module name. Some applications may refuse to load such assemblies.
VB.NET keeps the code files separated from the form files, so a "merge" action is needed for putting all the code into one script file: just insert all methods from the form module into class of the form designer file.
As an example, the installed template file for new VB scripts is a result of merge a "VB form" and a "VB form designer" files.
DBWorks 2007 provides a Default Environment for using the DBWCSSUI engine. The new folder BIN\DBWCSSUI contains all what is needed for creating and running .NET scripts with DBW2007. The standard DBWScrpt.LIB has been ported as a Class Library in the assembly MW.DLL.
CacheBaseDir: The root directory for caching the local script compilation results.
DownloadBaseDir: The root directory for downloading (caching) all remote scripts.
CodeProviderDll: Location of the VB compiler assembly. This value is passed at run time to the CS-Script engine through it's configuration file.
DebugMode: Boolean flag, which indicates that the script should be compiled with debug information included.
SimpleRemoteCaching: Boolean flag, which indicates when the remote script dependency files (assemblies and importable scripts) have to be analysed for changes.
•True: Files are analysed only if the primary remote script file is changed. This is the quickest algorithm as it does not require reading the remote script every time it is executed.
•False: Files are analysed every time the primary remote script file is executed.
This setting is used to optimise the runtime performance of remote scripts. The following settings are related to the actions to be performed before or after opening script(s) in VS
VSBaseDir: Root directory where all temporary C# and VB projects are generated.
VSCleanResx: Boolean flag, which indicates that any automatically generated .resx files (for temporary VS project) should be deleted on after closing the IDE.
VSUpdateIncludesOnClose: Boolean flag, which indicates that new //css_imp should be automatically injected to the script file after closing the IDE. The injection is usually triggered by adding .cs/.vb file to the project by developer. New directives are marked with "//auto-generated" comment.
VSUpdateRefsOnClose: Boolean flag, which indicates that new //css_ref should be automatically injected to the script file after closing the IDE. The injection is usually triggered by adding assembly references to the the project by developer. New directives are marked with "//auto-generated" comment.
For each "standard" script ( *.LST or *.SPT ), DBWorks 2007 looks if a .NET version exists in the same directory.
The .NET version has the naming convention:
•<original script name>.VB for a VB.NET script
•<original script name>.CS for a C# script
So, for example, if you like to create a C# version of the OnOK.LST, you must name it as OnOK.LST.CS, and DBW2007 will automatically invoke it instead of the originary OnOK.LST
The following is an example of OnOK.LST.CS:
//css_reference MW.DLL;
using System;
using System.Drawing;
using System.Windows.Forms;
public class DBWDotNet
{
static public string Main(
string ApplicationName,
string ModuleName,
string ConnectionDSN,
string ConnectionUID,
string ConnectionPWD,
string ConnectionDBMSName,
string ConnectionORACLE_SERVER,
string ConnectionORACLE_SCHEMA_OWNER,
string ConnectionBomDSN,
string IsInBatchOperation,
string CurrentDocumentBatchOperationIndex,
string BatchOperationDocumentsCounter
){
MW.DBWLib.Initialize(ApplicationName,ModuleName,ConnectionDSN,ConnectionUID,ConnectionPWD,ConnectionDBMSName,ConnectionORACLE_SERVER,ConnectionORACLE_SCHEMA_OWNER,ConnectionBomDSN,IsInBatchOperation,CurrentDocumentBatchOperationIndex,BatchOperationDocumentsCounter);
String fileName;
fileName = MW.DBWLib.DBWInput("FILE_NAME");
MessageBox.Show("FileName=" + fileName);
MW.DBWLib.DBWOutput("@OKDATA","1",MW.DBWLib.ForWriting);
String description;
description = "Created By OnOK.LST.CS";
MW.DBWLib.DBWOutput("DESCRIPTION",description,MW.DBWLib.ForAppending);
MW.DBWLib.Terminate();
return "";
}
}
Looking at the above script, you can see the following features:
1.the header must contain the //css_reference MW.DLL directive, for using the DBW standard script library
2.the main class must be named DBWDotNet
3.the entry point must be named Main and declared as the above sample; the self-explaining parameters are passed from DBWorks to the script at run time
4.each call to the DBW standard script library must be prefixed with MW.DBWLib.
5.all the variables must be explicitly declared
6.the very first call to the DBW standard script library must be the MW.DBWLib.Initialize , passing the parameters as shown in the above example; the Initialize calls internally the DBWInit(TRUE)
7.the very last call to the DBW standard script library must be the MW.DBWLib.Terminate()
8.all the methods of the MW.DBWLib class have the same syntax as documented in the standard DBWorks Help file, at the Programming DBWorks chapter
The same example shown above can be written in VB.NET as follows:
'//css_reference MW.DLL;
Imports Mechworks
Imports Microsoft.VisualBasic
Public Class DBWDotNet
Public Shared Function Main(ByVal ApplicationName As String,ByVal ModuleName As String,ByVal ConnectionDSN As String,ByVal ConnectionUID As String,ByVal ConnectionPWD As String,ByVal ConnectionDBMSName As String,ByVal ConnectionORACLE_SERVER As String,ByVal ConnectionORACLE_SCHEMA_OWNER As String,ByVal ConnectionBomDSN As String,ByVal IsInBatchOperation As String,ByVal CurrentDocumentBatchOperationIndex As String,ByVal BatchOperationDocumentsCounter As String) As String
MW.DBWLib.Initialize(ApplicationName,ModuleName,ConnectionDSN,ConnectionUID,ConnectionPWD,ConnectionDBMSName,ConnectionORACLE_SERVER,ConnectionORACLE_SCHEMA_OWNER,ConnectionBomDSN,IsInBatchOperation,CurrentDocumentBatchOperationIndex,BatchOperationDocumentsCounter)
Dim fileName as String
fileName = MW.DBWLib.DBWInput("FILE_NAME")
MsgBox("FileName=" & fileName)
MW.DBWLib.DBWOutput("@OKDATA",1,MW.DBWLib.ForWriting)
if ucase(right(fileName,7))=".SLDPRT" then
Dim id as String
id = left(fileName,len(fileName)-8)
Dim description as String
description = id & " - Created By OnOK.LST.VB"
MW.DBWLib.DBWOutput("DESCRIPTION",description,MW.DBWLib.ForAppending)
end if
MW.DBWLib.Terminate()
return ""
End function
End Class
Looking at the above script, you can see the following features:
1.the header must contain the directive ' //css_reference MW.DLL; ( a single apex, a space, then the //... ) , for using the DBW standard script library
2.apply the same rules described for the .CS script
The UserProcessDocument function, necessary to the DBWWalkTree functionality, it is supported by creating a special module named:
DBWWalkTree_UserProcessDocument.VB
with a template like:
' //css_reference MW.DLL;
' //css_reference MechWorks.Interop.DBWAlone.DLL;
Imports Mechworks
Imports Microsoft.VisualBasic
Public Class DBWDotNetUserLib
Public Shared Function UserProcessDocument( ByVal uniqueId As String ) As String
MsgBox(">>UserProcessDocument<< uniqueId=" & uniqueId)
return "0"
End function
End Class
The function UserProcessDocument is invoked by the MW.DBWLIB.DBWWalkTree for allowing the programmability of the actions on each document being processed.