I'm building a SharePoint webpart that I'm trying to add to the DisplayForm.aspx page of a custom list in SharePoint. This webpart will be using the SharePoint object model to retrieve fields from my list items.
I've accomplished the addition of the webpart by adding an <AllUsersWebPart> block in the <Form> block for the DispForm and I'm able to load that webpart just fine. I'd like the webpart to call LoadControl and load an .ascx file containing my control's layout and the associated code behind.
All of this is deployed via a WSP into SharePoint. As such, I'd like all configuration to occur from my manifest.xml file. This has proven difficult for the following reasons.
I would prefer to deploy the webpart assembly to the web application's BIN. Starting down this approach, I've defined NamedPermissionSet in my manifest.xml as described by Cory Roth as follows:
<PermissionSet class="NamedPermissionSet" version="1" Description="Permission set for my webpart">
<IPermission class="AspNetHostingPermission" version="1" Level="Minimal" />
<IPermission class="SecurityPermission" version="1" Flags="Execution,ControlPrincipal,ControlAppDomain,ControlDomainPolicy,ControlEvidence,ControlThread" />
<IPermission class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" version="1" ObjectModel="True" />
<IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Read="UserName" />
<IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Read="$AppDir$" Write="$AppDir$" Append="$AppDir$" PathDiscovery="$AppDir$" />
</PermissionSet>
I then discovered that the above is not sufficient for calling LoadControl which really needs something closer to Full permission. Instead, I get a "Cannot find file: /path/to/my/control".
I can hack a fix here (and it works) by setting Unrestricted="true" in the wss_custom_wss_minimaltrust.config file in %HIVE%\TEMPLATE\CONFIG but this is not a solution I want to maintain nor am I convinced my production administrators would be pleased with the approach.
Fine: I'll deploy the webpart assembly to the GAC. That moves me further along, but it's not a complete fix. With my assembly in the GAC, SharePoint calls into my assembly (which is working because I can attach my debugger to the IIS process and it breaks before my LoadControl call as expected) and appears to to successfully find my control file and load it. However, it throws and exception and dies reporting "Could not load type 'WebPart.MyControlCodeBahindType'". The type exists in the same assembly in the GAC which SharePoint has already successfully called into just to load the webpart that calls LoadControl. .
Why might something that's in the GAC not be able to load? Remember: this all works if I elevate permissions in the above hack so I feel that's sufficient to demonstrate that the web part assembly does contain the class that my .ascx is looking for.
Is there a work around that I can adopt in my WSP that will allow me to set Unrestricted="true" as described in my hack above (or similar?)?