Export (0) Print
Expand All

Security Semantics for Applications Written in Visual J#

Visual Studio 2005

In releases before Visual J# 2005, all applications or components written using Visual J# had to be fully trusted to be able to run. In Visual J# 2005, this restriction is relaxed for code that uses the Visual J# library (vjslib.dll). The change in behavior is due to the fact that in Visual J# 2005, the vjslib.dll assembly is marked with the AllowPartiallyTrustedCallersAttribute attribute. Visual J# applications can now execute within the scope of .NET partial trust semantics. Specifically, the following scenarios are now possible:

  • Visual J# applications will now execute properly when run off a network share.

  • Windows Forms controls embedded in a web page may use the Visual J# Class Library.

  • Visual J# code may be executed in an environment where a host application supports the execution of partially trusted code.

Code that uses other libraries, such as com.ms.wfc (vjswfc.dll) and com.ms.wfc.html (vjswfchtml.dll), still require full trust in order to run. If such an application or component runs in a code group that has not been granted the FullTrust named permission set by the security policy, a security exception is thrown. This applies to existing Visual J++ applications using com.ms.com, com.ms.dll, com.ms.lang, com.ms.wfc or com.ms.wfc.html upgraded to Visual J#.

Therefore, consider the following when writing applications using Visual J#:

  • All applications run from the local machine in the MyComputer code group are granted the FullTrust permission set under the default security policy of the .NET Framework. Thus, applications run from the local machine cause no issues.

    Applications run from remote locations (such as a network share) in the Internet or Intranet code groups. As applications run in these code groups are not granted the FullTrust permission set under .NET Framework default security policy, they may fail with a security exception if they use the Visual J++ libraries.

    A potential workaround is to make applications or components run from remote locations fully trusted. In order to be considered fully trusted by the .NET Framework security policy, one of the following must be true:

    • The component or application has been signed with a key pair, and the .NET Framework security policy on the computer has been modified to grant the FullTrust named permission set to all components or applications signed with this key pair.

    • The component or application has been signed with an Authenticode certificate, and the .NET Framework security policy on the computer has been modified to grant the FullTrust named permission set to all components or applications signed with this Authenticode certificate.

    • The .NET Framework security policy on the computer has been modified to grant the FullTrust named permission set to controls downloaded from the Web site (URL) where the component or application is hosted.

Community Additions

ADD
Show:
© 2015 Microsoft