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