In the previous articles in this series, we looked at FDCC changes (part 1) and GUI enhancements (part 2) in PowerBuilder 11.5. In this article, we'll be looking at the enhancements that were added to PowerBuilder 11.5 that are specifically related to .NET targets. The one thing we won't be covering in this regard is the .NET security enhancements that were covered in a previous PBDJ article: "Applying Code Access Security in PowerBuilder .NET Applications" by Maggie Lv.

Strong Named Assemblies
The .NET framework allows the author to sign an assembly so that it has a "strong name." Such signing provides a number of benefits including:

• Verification of the integrity of the assembly. The .NET runtime will ensure that the assembly being loaded has not been modified.
• Versioning. You can have several different versions of the assembly installed and each application will use the one that it's configured to work with.
• Name uniqueness. Since a private key is used in generating the strong name, you don't have to worry about other authors creating assemblies that have the same strong name as yours.
• Interoperability with other strong-names assemblies. To preserve the benefits of strong-named assemblies, the .NET runtime won't allow a strong-named assembly to reference an assembly that's not strong-named. If you want to be able to use your assembly from another strong-named assembly, it needs to be strong-named as well.

The ability to strong-name an assembly is important enough that I provided a blog entry on it a while back to provide a workaround for the initial PB 11 release. That's no longer necessary now, since one of the new features of 11.5 is the ability to strong-name an assembly.

The strong naming is handled through a new "Sign" tab on a .NET target project (see Figure 1).

The first checkbox simply determines whether the assembly is signed or not. Until that checkbox is checked, the other options on the tab remain disabled. Once it's checked, the SLE and buttons below it become enabled. You can use them to either:

• Hit the browse button to select an existing strong-name key (SNK) file generated by the .NET SDK Strong Name Key tool (sn.exe),
• Hit the new button and have a SNK file generated for you
• Use the browse button to select a Personal Information Exchange File (PFX) file for a code-signing certificate.

Either of the first two options will result in a self-signed assembly. If a user is prompted to determine whether they trust the assembly, the dialog will indicate that the publisher is unknown. The third option results in a signed assembly where the publisher (you) will be indicated as verified. For more information on obtaining a code-signing certificate for assembly signing, see resources such as this blog.

If the assembly is going to be signed with a code-signing certificate, it's not unusual for the private certificate to be held under a rather strict lock and key. That is, the average developer may be responsible for creating an assembly that needs to be signed using the certificate, but isn't allowed to have access to the actual certificate. That's where the "delay sign only" option comes in. If this option is selected, the assembly is marked for signing and the actual signing is done later by the person who actually has access to the private key.

Finally, there's the Allow Partially Trusted Caller Attribute option. The issue here is that some applications (particularly Smart Client applications) run under a Partial Trust environment. If an assembly has not been marked with the Allow Partially Trusted Caller Attribute, applications running under such conditions will be unable to use the assembly. Quite simply, setting the attribute allows applications running under partial trust to use the assembly. You should really only check this when you know you'll have applications running under partial trust that need to use the assembly. For more information on Partial Trust and the Allow Partially Trusted Caller Attribute click here.

So we've created our project and added the information to sign the assembly, now how do we know that the result has really been signed? Well, we have a couple of options. One is to use the Microsoft FxCop utility to examine the assembly. See, for example, the results show in Figure 2 for a signed assembly and in Figure 3 for an unsigned assembly. Note that both have an entry for "Strong Name" so that alone isn't enough to determine if the assembly is actually signed. Instead, we look at attributes such as PublicKey in the Flags attribute, a non-null value for the HashValue and a non-null value for the PublicKeyToken value.

Alternatively, there's a method in the .NET Framework available to us to determine if the assembly is signed and, interestingly enough, it's an unmanaged code function (meaning we can call it from a native PB client). Simply declare a local external function as follows:

FUNCTION BOOLEAN StrongNameSignatureVerificationEx ( string filepath, boolean forcevalidation, ref boolean wasverified ) LIBRARY "mscoree.dll"

We then only have to call it with code similar to Listing 1 to determine whether or not an assembly has been signed. (Download Listings 1-3 here.) Note that the example shown will generally only return the first option ("Valid Strong Name") for a signed assembly or the third option ("Validation Called Failed") for an unsigned assembly. See the .NET security blog for more information about the meanings of the combinations for the return code and the WasVerified reference argument.

Shared Objects
PowerBuilder 11.5 introduces support for shared objects in .NET targets. Shared objects themselves aren't new; they've been a part of PowerBuilder since version 6.0 and are used largely to provide for multithreaded capability in the PowerBuilder application. For more information on them, you might refer to some older PBDJ articles, including "PB App Development using Shared Objects" by Tim Nesham.

The issue was that Shared Objects were one of the PowerBuilder features that weren't supported in .NET targets in the original 11.0 release. Now they are supported. There are some caveats in the new features information that comes with 11.5 on shared objects, but they're caveats that apply to shared objects in general (e.g., lack of access to the SQLCA object). There's nothing that indicates a specific limitation to how shared objects work when used in .NET targets.

Language Interoperability
One of the things that can be rather frustrating if you do any .NET conditional compilation blocks in PowerBuilder 11 is that the .NET Framework supports a number of language constructs that don't really have a corollary in PowerScript. The result, at least with the initial release of PowerBuilder 11, was that there were simply some classes that required a bit of extra work to access and others that were entirely unreachable from PowerBuilder.

PowerBuilder 11.5 addresses two of the major areas where this was an issue. The first is that primitive datatypes (Int32, String, Boolean) have methods in .NET, whereas their equivalent in PowerScript don't (or at least didn't in the initial PB 11 release). Now PowerScript datatypes referenced in .NET conditional code blocks now implement the same methods as the .NET datatype that they are mapped to. For example, see Listing 2, which is from a WinForm target where rb_dotnet is one of a set of radio buttons used to determine whether the response of the call on the .NET object type or the PowerScript object type is shown. When the code is run, both method references on the simple datatypes work.

Similarly, support has been added for calling methods on .NET enumerations.

Another issue with the initial .NET conditional code (though a bit minor) is how static methods on classes are handled. With the initial PB11 release, you couldn't use an instance of a class to invoke a static method on it. Instead you'd need to fully qualify a static reference to it. For example, if we were already using one or more String classes, and then wanted to use the Concat static method, we couldn't use one of our existing String objects. Instead, we'd code something like:

result = System.String.Concat ( arguments )

With PB 11.5, if we have an existing String object instantiated, we can call the static method on it as if it was a non-static method:

result = someStringvar.Concat ( arguments )

Listing 3 shows an example of using the static Concat method on a String variable.

One interesting thing about the example shown is the way that the second String variable (endstr) is constructed. Originally I simply created it the same way as I did the first variable (startstr). Apparently PowerBuilder has a problem with two variables of the same type in a script being constructed with the same argument types in a conditional code block. That is, although the variables have different names, PowerBuilder ends up with a conflict between them. Using an alternate constructor for the second variable resolved the conflict.

That's all for part three. Stay tuned for our final look at new PB 11.5 feature next month.