在配置使用Membership或其他的Providers的ASP.NET2.0時(shí)一定要設(shè)置applicationName屬性
原文： Always set the "applicationName" property when configuring ASP.NET 2.0 Membership and other Providers
作者：Scott Guthrie
翻譯：范維肖
注釋：對(duì)于個(gè)別名詞保留英文描述或翻譯參考。

場(chǎng)景 ：
在本地開發(fā)一個(gè)asp.net2.0的應(yīng)用程序時(shí)使用了Membership、Roles或Profile特性。你創(chuàng)建了一些新用戶，一切都沒有問題。

然后把這個(gè)程序copy到遠(yuǎn)程服務(wù)器（remote server）上（或者只是移動(dòng)到你本地服務(wù)器上的其他目錄）然后運(yùn)行。由于某種原因，雖然我們能夠連接到membership數(shù)據(jù)庫(kù)，但是當(dāng)?shù)顷懙臅r(shí)候就會(huì)出現(xiàn)錯(cuò)誤了，它并不拋出連接錯(cuò)誤（connection error），而是提示你像類似的錯(cuò)誤：“嘗試登陸失敗，請(qǐng)重試”（Login attempt unsuccessful, please try again）

原因 ：
這種經(jīng)常出現(xiàn)的錯(cuò)誤的原因是因?yàn)閙embership（或者是roles、profile） provider已經(jīng)被加入到了程序的web.config里了。但是applicationName屬性（attribute）并沒有被指定（假設(shè)下面的代碼的粗體部分布存在地話）

< membership >

< providers >

< clear />

< add name ="AspNetSqlMembershipProvider"

type ="System.Web.Security.SqlMembershipProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a"

connectionStringName ="LocalSqlServer"

enablePasswordRetrieval ="false"

enablePasswordReset ="true"

requiresQuestionAndAnswer ="true"

requiresUniqueEmail ="false"

passwordFormat ="Hashed"

maxInvalidPasswordAttempts ="5"

minRequiredPasswordLength ="7"

minRequiredNonalphanumericCharacters ="1"

passwordAttemptWindow ="10"

passwordStrengthRegularExpression =""

applicationName ="/"

/>

</ providers >

</ membership >

如果applicationName屬性沒有被配置的話，當(dāng)往程序的數(shù)據(jù)庫(kù)里添加數(shù)據(jù)的時(shí)候，asp.net會(huì)使用程序在web服務(wù)器里的虛擬目錄路徑（vroot Path）自動(dòng)的計(jì)算applicationName的值。我們打開aspnetdb數(shù)據(jù)庫(kù)，看aspnet_Applications表，就能了解這一行為：

這個(gè)表里為每個(gè)applicationName存儲(chǔ)了一個(gè)具有唯一值（unique）的ApplicationID。因?yàn)樵谖覀兊某绦蚶镒?cè)一個(gè)用戶的時(shí)候并沒有指定一個(gè)applicationName屬性，所以它自動(dòng)的被設(shè)置（計(jì)算）為/website8（早期建立項(xiàng)目時(shí)的名字

如果applicationName屬性沒有被配置的話，當(dāng)往程序的數(shù)據(jù)庫(kù)里添加數(shù)據(jù)的時(shí)候，asp.net會(huì)使用程序在web服務(wù)器里的虛擬目錄路徑（vroot Path）自動(dòng)的計(jì)算applicationName的值。我們打開aspnetdb數(shù)據(jù)庫(kù)，看aspnet_Applications表，就能了解這一行為：

這個(gè)表里為每個(gè)applicationName存儲(chǔ)了一個(gè)具有唯一值（unique）的ApplicationID。因?yàn)樵谖覀兊某绦蚶镒?cè)一個(gè)用戶的時(shí)候并沒有指定一個(gè)applicationName屬性，所以它自動(dòng)的被設(shè)置（計(jì)算）為/website8（早期建立項(xiàng)目時(shí)的名字）

然后，使用membership API創(chuàng)建的用戶會(huì)與ApplicationID相關(guān)聯(lián)，這樣可以找到applicationName（and in turn the applicationName）。【這樣做的目的可以讓我們的多個(gè)應(yīng)用程序和站點(diǎn)使用同一個(gè)數(shù)據(jù)庫(kù)】。打開aspnet_Users表就可以可以看到這些。

如果把這個(gè)程序配置成運(yùn)行在/website8虛擬目錄下那么一切都沒有問題。但是如果它被copy到其他的地方或服務(wù)器上并且更換了虛擬路徑（比如說(shuō)“/app1”或更通常被設(shè)置的“/”）后，當(dāng)Membership APIs被使用時(shí)他們就“看”不到數(shù)據(jù)庫(kù)里已有的用戶了——因?yàn)樗麄儗?huì)使用一個(gè)不同的applicationName去數(shù)據(jù)庫(kù)里尋找用戶，相應(yīng)地過(guò)濾application_Users表中的用戶。這就是為什么會(huì)出現(xiàn)上面錯(cuò)誤的原因。

如何解決這個(gè)問題 ：
最簡(jiǎn)單的辦法是打開ASPNETDB數(shù)據(jù)庫(kù)中的aspnet_Users和aspnet_Application表，去“回想”（figure out,因?yàn)槟菚r(shí)候我們的虛擬目錄叫什么名字我們恐怕已經(jīng)忘了）創(chuàng)建用戶和其他數(shù)據(jù)的時(shí)候的程序名稱（去aspnet_Application表中查找）

然后打開你的web.config文件，添加一個(gè)applicationName屬性到provider聲明的地方并且給他賦值，例如，下面的代碼我們把它設(shè)置為在aspnet_Application表存在的/website8：

< membership >

< providers >

< clear />

< add name ="AspNetSqlMembershipProvider"

type ="System.Web.Security.SqlMembershipProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a"

connectionStringName ="LocalSqlServer"

enablePasswordRetrieval ="false"

enablePasswordReset ="true"

requiresQuestionAndAnswer ="true"

requiresUniqueEmail ="false"

passwordFormat ="Hashed"

maxInvalidPasswordAttempts ="5"

minRequiredPasswordLength ="7"

minRequiredNonalphanumericCharacters ="1"

passwordAttemptWindow ="10"

passwordStrengthRegularExpression =""

applicationName ="/website8"

/>

</ providers >

</ membership >

這樣程序就能正常的工作，無(wú)論我們部署這個(gè)程序到那個(gè)虛擬目錄。

當(dāng)然，我們還要保證Roles、Profile、WebPartPersonalization或其他的我們配置的providers也要被配置了。

這樣我們的程序可以正常工作了。

如果在一開始就避免它：
避免這個(gè)問題的最好的辦法是始終設(shè)置applicationName的值。一個(gè)比較好的默認(rèn)值是使用“/”。