views:

61

answers:

1

I have MOSS server and users authorization is going trough AD.

I want to programmaticaly get some current user information, like e-mail, phome number.

I made the following steps: 1) create dll with [assembly: AllowPartiallyTrustedCallers] 2) i have the class PhoneBookCL that inherits System.Web.UI.WebControls.WebParts.WebPart
and I try to override CreateChildControls() for testing;

using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts; 
using Microsoft.Office.Server;
using Microsoft.Office.Server.UserProfiles;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint.Portal;

public class PhoneBookCL : WebPart
{

        SPUser currentUser = null;
        protected override void CreateChildControls()
        {

            try
            {
                SPWeb web = SPControl.GetContextWeb(Context);
                currentUser = web.CurrentUser;
            }
            catch (Exception exp) { value = exp.Message; }          

        }
}

3) assigned strong name to dll, then add SafeControl to web.config:

4) dll -> to \Bin directory, added this WebPart to SP webparts collection, added the webpart to the new Page.

Refreshing the page going to the exception: unexpected exception.

If I delete

"SPWeb web = SPControl.GetContextWeb(Context);
                currentUser = web.CurrentUser;"

then all works great.

I can create Label and change its Text property and other things. Also I tried to inherit from Microsoft.SharePoint.WebControls.WebPart, which actually inherit UI...WebPart, so the result is the same.

Maybe there is some security issue?

+2  A: 

This problem occurs as you are deploying dll to bin. I assume your web.config has trust level as WSS_minimal . Minimal trust will not permit accessing object model.

Therefore , you have the following options:

  1. Deploy the webpart using a wsp with custom code access security. This is slightly tedious.
  2. Change the trust level in web.config to Full.
  3. Deploy the dll to GAC.

From a best practices perspective, deploying the dll to bin with custom code access security will be the best option. But if you dont have security restrictions, you can look at deploying to GAC to keep things simpler.

Reference : http://msdn.microsoft.com/en-us/library/ee909485%28office.12%29.aspx

Regards, Faiz

Faiz
Thank you!Actually just find myself the answer http://msdn.microsoft.com/en-us/library/dd583158%28office.11%29.aspx.Anyway, you are right!
Artru
Don't have enough reputation to add plus.
Artru