IIS 7.5應用程序池使用錯誤的％APPDATA％作為自定義用戶身份

Question

我希望我的MVC3 Web應用程序訪問％APPDATA％（例如，Windows 7上的C:\\Users\\MyUsername\\AppData\\Roaming ），因為我在那里存儲配置文件。 因此，我在IIS中創建了一個具有用戶“MyUsername”標識的應用程序池，通過使用該帳戶登錄創建了該用戶的配置文件，並打開了“加載用戶配置文件”選項（默認情況下仍為true）。 模擬被關閉。

現在我遇到％APPDATA％（在C＃中）的問題：

appdataDir = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)

解析為c:\\windows\\system32\\inetsrv而不是C:\\Users\\MyUsername\\AppData\\Roaming 。

更新：更確切地說，上面的C＃代碼返回一個空字符串，因此Path.GetFullPath(Path.Combine(appdataDir, "MyAppName"))當前路徑添加到我的應用程序名稱，從而生成c:\\windows\\system32\\inetsrv\\MyAppName 。

我知道我之前使用Windows Server 2008 R2上的相同Web應用程序完成了這項工作，現在我在Windows 7上使用相同的主要版本7.5的IIS來解決這個問題。
我使用了與以前相同的過程：創建一個新用戶，以該用戶身份登錄以創建配置文件和APPDATA目錄，然后使用此標識添加應用程序池，最后將Web應用程序添加到此池中。

有任何想法嗎？

Answer 1

打開%WINDIR%\\System32\\inetsrv\\config\\applicationHost.config並查找<applicationPoolDefaults> 。 在<processModel> ，確保您沒有setProfileEnvironment="false" 。 如果這樣做，請將其設置為true。

Answer 2

應用程序池 - 您的應用程序池 - 高級設置......

流程模型 - 加載用戶配置文件設置為True。

它幫助到我。

取自https://blogs.msdn.microsoft.com/vijaysk/2009/03/08/iis-7-tip-3-you-can-now-load-the-user-profile-of-the-application-游泳池身份/

Answer 3

我最近遇到了同樣的問題。 如Amit所述，問題是未加載用戶配置文件。 該設置適用於所有應用程序池，位於applicationHost.config中（通常為C：\\ Windows \\ System32 \\ inetsrv \\ config \\ applicationHost.config）。 如果您按如下所示更新applicationPoolDefaults元素，它將起作用;

<applicationPoolDefaults managedRuntimeVersion="v4.0">
  <processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="true" />
</applicationPoolDefaults>

我們已經嘗試使用IIS 7.5，並毫無問題地將其用於生產。

如果你願意，你可以自動化;

appcmd set config -section:system.applicationHost/applicationPools /applicationPoolDefaults.processModel.setProfileEnvironment:"true" /commit:apphost

或者如果你喜歡powershell

Set-WebConfigurationProperty "/system.applicationHost/applicationPools/applicationPoolDefaults/processModel" -PSPath IIS:\ -Name "setProfileEnvironment" -Value "true"

希望這可以幫助

Answer 4

我遇到了同樣的問題。 你偶然安裝了Visual Studio 11 beta嗎？ 我最近做了，我注意到4.0兼容的.dll如何使用我們的代碼。 我仍然試圖確定追蹤問題，但在此之前我沒有遇到這個問題。

編輯：

在比較GetFolderPath（和相關）的4.0和4.5的反編譯源之后，存在差異。 他們是否是問題的根源......我還不確定。

編輯2：以下是相關更改。 我正在努力嘗試看看我是否得到不同的結果。 [代碼已刪除]

編輯3：

我現在嘗試直接調用SHGetFolderPath，無論如何，這是.NET Framework最終要做的事情。 它返回E_ACCESSDENIED（-2147024891 / 0x80070005）。 我不知道在某些特定情況下我得到了什么改變了，但在其他情況下卻沒有。

編輯4：

由於您獲得了一個空字符串，您可能希望切換代碼以使用SHGetFolderPath，這樣您就可以獲得HResult並至少知道究竟發生了什么。

void Main() {
    Console.WriteLine( GetFolderPath( Environment.SpecialFolder.ApplicationData ) );
}

[System.Runtime.InteropServices.DllImport("shell32.dll")]
static extern int SHGetFolderPath(IntPtr hwndOwner, int nFolder, IntPtr hToken, uint dwFlags, StringBuilder pszPath);

private string GetFolderPath( Environment.SpecialFolder folder ) {
    var path = new StringBuilder( 260 );
    var hresult = SHGetFolderPath( IntPtr.Zero, (int) folder, IntPtr.Zero, 0, path );
    Console.WriteLine( hresult.ToString( "X" ) );

    return ( (object) path ).ToString( );
}

Answer 5

問題出在您的IIS設置上。 答案在這里： Environment.GetFolderPath（Environment.SpecialFolder.ApplicationData）返回String.Empty