Like any standard .NET application, the PowerBuilder .NET application follows the common language runtime rules regarding the permissions needed to do the operation the application aims to do. The code access security (CAS) provided by the .NET Framework is a security mechanism that a real application follows to evaluate whether the operation or code can be trusted or rejected according to where the code originates, who signs the code, and what the code intends to do.

Let me explain the CAS process with an example. Say there's an internal project meeting scheduled at a company and someone wants to attend that meeting. Our rules for the attendees are:

• If you are a full-time employee and usually in the office, you can attend the meeting and access the meeting resources without restriction.
• If you are a full-time employee, but not regularly in the office, your employee login ID and network info will be checked before you can attend the meeting. Some on-site resources in the meeting room like paper won't be available for you.
• If you're a partner or customer, there will be a more restricted check on your identity and less resources available to you regarding the meeting.

CAS, by analogy, aims to reduce the likelihood of the code being misused and make sure it only performs the operations permitted. CAS wasn't supported in PowerBuilder 11 yet. All .NET applications have to be run with full trust permission and in a current computer. You may have experienced the pain of a Windows Form application blowing up when you tried to launch it from a local network path. Mapped to the meeting example, that means only current full-time employees working at the company can attend the meeting. Now in PowerBuilder 11.5, with CAS implemented, a .NET application can be executed from various security zones, such as current computer, local intranet, and Internet, following the permission rules that zone grants.

Taking a Look at the .NET Security Policy and Trust Level
If you've installed the .NET Framework 2.0 SDK, you can find a tool from the control panel Administrator Tools Microsoft .NET Framework 2.0 Configuration. This GUI tool is for system administrators to configure the security policy for the different zones that .NET applications follow at runtime.

Notice in Figure 1 that each code group zone has a corresponding permission set applied to it, and each permission set contains some permissions by default. You can add your own permission set with your intended permissions and then apply to a certain zone. In Figure 1, I created my own permission set "Copy of LocalIntranet" by duplicating the LocalIntranet Permission Set and adding "File IO" permission, then I changed LocalIntranet_Zone's property to use this new permission set (see Figure 2). But be careful about doing this unless you clearly know the permissions since the settings in this tool will affect the runtime code access security of all .NET applications.

You can use the tool caspol.exe provided by the .NET Framework 2.0 to manipulate the security policy setting if you don't have the .NET Framework 2.0 SDK installed on your system. For example, c:\>caspol -list will list the security setting in your current system. You get can detailed information from the reference for the caspol tool.

Applying CAS in a PowerBuilder .NET Windows Form
In PowerBuilder 11.5, CAS is supported in the Windows Form, WebForm, and Web Service projects. In the Windows Form project painter's security tabpage, four kinds of trust levels are available: full trust, local intranet, Internet, and custom (see Figure 3). You may have noticed that these four levels correspond to the code group zones in Figure 1.

The security setting you select will take effect when you run the application from inside the PowerBuilder IDE by clicking the running man icon at the development or debug stage. Notice that except for the full-trust level, permissions in the other three levels can be customized by checking, unchecking, or manually changing the contents by clicking the detail button. This makes it convenient for you to test your code with the permissions you granted. Here a couple of permissions, SecurityPermission and UIPermission, are required to run all Windows Form applications. It's easy to understand since even a very simple program needs these two permissions to execute and draw the GUI components. (Well, unless the application is running in the background without a UI, then UIPermission isn't required.)

All the permissions listed in the project painter are retrieved from the .NET Framework, though PowerBuilder features only match some of the items, while others are there for you to select in case you're using some third-party .NET features through .NET interop. So with CAS supported, PowerBuilder developers will need to determine which kind of permissions are needed to run the code properly. Commonly used permissions are easy to recognize just from their names like FileIOPermission, RegisryPermission, and PrintingPermission, which control the corresponding PowerBuilder features file, registry, and print-related operations.