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)                                                                

For ASP.NET developers who are used to name their configuration files “web.config” , working with configuration files of Windows forms application in VS.NET is a little bit tricky. Let’s assume that you have an application called “TestConig” which generates the executable TestConig.exe. If you ever decide to add a config file to this app using visual studio ,there are couple of things to remember:

1) Add an new item to your project and name it App.config which is basically nothing more than an XML file.
2)Build your project and look in the build output directory. The binRelease or binDebug directory for C# projects

Surprisingly you’ll see that there is a file called TestConig.exe.config and App.config is not what the configuration file ends up getting called, this is just what it’s called inside a Visual Studio .NET project.

I guess the question is that why VS.NET behaves like that? and the answer is simple:

TestConig.exe.config file is a copy of the App.Config file.VS.NET copies it so that you don’t need to maintain a separate debug and release version of this file. And they use the name TestConig.exe.config because that’s the magic name they’ve chosen for this behavior

Deployment: In deployment you need to make sure that the App.config file is renamed TestConig.exe.config or just simply pick up TestConig.exe.config from debug or release folder.

1) string ProcessIdentity = WindowsIdentity.GetCurrent().Name;

• It has nothing to do with ASP.NET. In fact this is the lowest level of windows security programming that you can do. It basically tells you who is this thread running as?
  
• No matter which authentication mechanism you use in your ASP.NET applications (Windows Integrated,Forms,Basic,Digest and etc), whether you impersonate or you use anonymous access, at the end of the day they all resolve in a windows account. The above statement returns the name of that account.
  
• The windows account which is returned is a process identity (App pool identity, Machine identity, etc) OR impersonated user (if impersonation is used) OR anonymous access identity (if anonymous access is enabled). Bear in mind that the security context which is the result of enabling the anonymous access is ONLY used when your web parts interact with local or network resources and SharePoint is still using Process Identity to call content or configurations database, regardless of whether web application is set to use Form or Windows Integrated Authentication.

2) string ASPNetUser = Context.User.Identity.Name;
This is an ASP.NET technique to get the owner of the HTTP context. Based on authentication type, impersonation settings it might be different from one environment to another one.

3) string WssUser = SPContext.Current.Web.CurrentUser.Name;
AS mentioned din my previous blog post , this is a new class in SharePoint 2007 to extract the WSS user which gives u a more friendly name than the ASP.NET user.