Reza Alirezaei’s Blog

If you have ever worked with NAnt , you probably know that there is an xsd for .build files that provides intellisense in VS.NET 2003. After you add a task dll ( In my case NAnt.SharePoint.Task.dll) or install a newer version of NAnt , there are some manual steps required to make VS recognizes the new schema. Instead of the manual process, you can get NAnt itself to update/generate its schema for the internal use of VS.NET 2003 by creating a build file and calling the command line as described below:

1) Create UpdateCreateSchema.build file with the following NAnt snippet and save the file in for example c:
antGen folder :

 xml version=”1.0″ encoding=”utf-8″ ?>
<project name=” UpdateCreateSchema“ default=”genschema”>
     might be different in your installation–>

    <property name=”SchemaFile” value=”C:Program FilesMicrosoft Visual Studio .NET 2003Common7PackagesschemasxmlNAnt.xsd”/>
    <target name=”genschema”>
        <nantschema output=”${SchemaFile}” target-ns=”http://nant.sf.net/schemas/nant.xsd”/>
    target>
project>   

2) Assuming Nant has been properly added to Path variable, open a command prompt and change directory to c:
antGen . Call the following command line:

 nant file: UpdateCreateSchema.build

3) Now that you have deployed the latest version of NAnt.xsd file to the C:Program FilesMicrosoft Visual Studio .NET 2003Common7Packagesschemasxml folder , you must go through all of your build files in your project and

a.Make VS.NET recognize your .build file as an XML file (If already done, skip this step then ): 

In “Solution Explorer”, right-click a .build file and choose “Open With”. In the “Open With” dialog, select “HTML/XML Editor” and click the “Set as Default” button. Enable intellisense for each .build file.

b.When file is opened by the “HTML/XML Editor” , in the properties window , set the targetSchema to the newly updated/generated Nant.xsd

4) Boom. You’ll get intellisense. Enjoy!

Mark Kruger has compiled a good collection of links to all kinds of resources for the new 2007 Microsoft Office System. http://www.sharepointblogs.com/mkruger/archive/2006/05/25/7570.aspx

This post applies to SharePoint or any ASP.NET applications whose authentication mechanism is NTLM and impersonation is enabled. SharePoint,by default,uses impersonation which results in an impersonated token, which is not primary token on the SPS Server.When HTTP request leaves machine boundaries, the impersonated token becomes the root of all evil.Let’s have a deeper look by running the code below in your web part/web part page or generally speaking in any http context:

1. HttpWebRequest userReq = (HttpWebRequest)WebRequest.Create(“http://mysite/sharedDoc/test.xml“);
2. userReq.AllowAutoRedirect=false;
3. userReq.Credentials = System.Net.CredentialCache.DefaultCredentials;
4. HttpWebResponse serverResponse = (HttpWebResponse) userReq.GetResponse();

It works fine on your development enviroment (if everything is on the same server),but as soon as you go live on production where IIS and SQL Server are located in two differnet machines , you will get : The remote server returned an error: (401) Unauthorized

Use the code below instead and everything just works fine!!!!

1. HttpWebRequest userReq = (HttpWebRequest)WebRequest.Create(fullLink);
2. userReq.AllowAutoRedirect=false;
3. userReq.Credentials = new System.Net.NetworkCredential(“Bob”,”pass@word”,”Domain“);
4. HttpWebResponse serverResponse = (HttpWebResponse) userReq.GetResponse();

Here is the brief explanation of what’s happening when you receive the error for the first snippet.                                              
I ) Bob authenticates with web server via browser using NTLM ,so no password is sent over the wire and only a windows security token will be created
II) IIS creates a windows security token for poor Bob.This token is an impersonation token  and not a primary token (because impersonation is enabled). It has also no network credentials and cannot be delegated to any remote servers (because NTLM is used)                                 
III)ASP.NET code accesses DefaultCredentials to use in WebRequest. DefaultCredentials are based on impersonation token,but DefaultCredentials contains an impersonated token and not the primary one,  so it cannot hop to SharePoint Content Database (where the document and document library is stored) to create the web request.                    

Main reason that the second  snippet works is the fact that you are re-creating the windows security context and providing the password. To solve issues of this type you have couple of solutions :      

            
Solution 1)As mentioned above use direct creation of the security context (store credentials in a safe palce)                               

Solution 2)Use Kerberos along with Delegation of both Bob’s credential and the machine which hosts SPS (IIS Server).These setting must be done in AD , so refer to this excellent article : http://support.microsoft.com/kb/810572/                                   

Solution3)Use Basic Authentication to send users credential in plaintext  (Make sure you secure the transportation layer though using  HTTPS,etc)