共享开发计算机 (rdp) 上的 IIS Express
我有一个我认为可能很常见的问题，在网上搜索它但一无所获。
我们使用共享的开发机器，每个开发人员都通过 RDP 连接并拥有自己的配置文件、桌面等。
我遇到的问题是 IIS Express。由于它是在用户级别配置的（documents/iisexpress/config 内的 applicationhost.config），并且配置的端口必须与 .csproj 文件中声明的端口匹配，因此两个开发人员不可能在同一端口上运行，因为它会给出错误“该端口已被使用”。
因此，为了使其工作，我们必须为每个开发人员手动更改 csproj 和 applicationhost.config 中的端口，但这只是临时修复，因为当我们将更改提交到 SVN 时，csproj 文件会合并，因此我们有每次有人提交/更新时都执行此过程。
我的问题是：是否有一种干净的方法可以在共享开发计算机上将 IIS Express 与 Visual Studio 2010 一起使用？
谢谢。
I have a problem which I thought could be common, searched the web for it but found nothing.
We're using a shared development machine, and every developer connects through RDP and has his own profile, desktop, etc.
The problem I am encountering is with IIS express. Since it is configured at user level (applicationhost.config inside documents/iisexpress/config) and the port configured must match the one declared in the .csproj file, two developers can't possibily run on the same port, as it gives the error "the port is already in use".
So to make it work we have to manually change the port both on the csproj and in the applicationhost.config for every developer, but it's only a temporary fix as when we commit our changes to SVN, the csproj file gets merged, so we have to do this process every time someone commits/updates.
My question is: is there a clean way to use IIS express with Visual Studio 2010 on a shared development machine?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
部分测试的答案。不确定它在多用户工作站上如何工作。它可能会帮助您或这里的其他人快速找到最适合您现有环境的正确解决方案。
看来 Visual Studio 将所有 Web 配置存储在 csproj/vbproj 中，IISExpress 将其配置存储在 %userprofile%\Documents\IISExpress\config\ApplicationHost.Config 中。
通常，我们将csproj文件存储在源代码管理中，但忽略csproj.user文件，以便每个人都可能有一些独特的设置，例如Web配置。
通过取消选中“将服务器设置应用于所有用户”选项，将 Web 设置复制到 csproj.user 中，然后提交到源代码管理。
每个提取源副本的用户都必须配置其 Web 设置，使用其他用户未使用的唯一端口，并取消选中上面的框，以便他们的配置不会传递给其他用户。
执行此操作时，每个配置文件都将拥有自己的 IIS Express ApplicationHost.Config，该配置配置有与其他配置文件不同的端口。每个用户的源副本都将有一个 csproj.user，该用户在其配置文件的 IIS Express 配置中配置了相同的端口。
仅供参考：
我尝试更改 IIS Express 的 ApplicationHost.Config 以使用与 Visual Studio 预期不同的端口，并且 Visual Studio 无法将调试器连接到 IIS Express。
IIS Express 配置的工作原理： http://msdn.microsoft.com/en-我们/library/ms178109.aspx
Partially tested answer. Not sure how it'll work on a multi-user workstation. It might give you, or someone else here, a jumpstart to a proper solution that works best in your existing environment.
It appears that Visual Studio stores all the web configuration in the csproj/vbproj and IISExpress stores its configuration in %userprofile%\Documents\IISExpress\config\ApplicationHost.Config.
Normally, we store the csproj files in source control, but ignore the csproj.user file so that each person may have some unique settings, such as the web configuration.
Copy the web settings into the csproj.user by unchecking the option Apply server settings to all users and then commit to source control.
Each user who pulls a copy of the source will have to configure their web settings, use a unique port that the others users are not using, and uncheck the box above so that their configuration is not passed on to the other users.
Doing this, Each profile will have their own IIS Express ApplicationHost.Config configured with a port that is different from the other profiles. Each user's copy of the source will have a csproj.user that is configured with the same port in their profile's IIS Express configuration.
For reference:
I've tried changing IIS Express's ApplicationHost.Config to use a different port than what Visual Studio expects and Visual Studio is unable to connect the debugger to IIS Express.
How IIS Express's configuration works: http://msdn.microsoft.com/en-us/library/ms178109.aspx
您可以使用的最佳选择是利用内置的导入功能进入 MSBuild。
本质上，您将为每个用户创建一个单独的构建目标。然后，您可以直接从该引用的文件导入该目标。然后，我建议在服务器上（为每个用户）创建此文件，但将其保留在源代码管理之外。
这应该允许每个用户拥有一个自定义的 IIS 端口，而不会与其他用户发生冲突。
The best option you can use is to take advantage of the Import functionality built into MSBuild.
Essentially, you would create a seperate build target for each user. You can then import this target from this referenced file directly. I would then recommend creating this file on the server (for each user), but leaving it outside of source control.
This should allow each user to have a custom IIS port without conflicting with others.
我认为您可以为每个用户创建子域并实施所需的更改并进行测试。通过这种方式，每个用户都可以拥有自己的子域和端口，从而在共享的 IIS Express 上独立工作。
I think you can create subdomains for each user and implement the required changes and do the testing. In this way each user can his own subdomain and port and hence work independently on the shared IIS Express.
您可能不喜欢我的回答，但这是我的想法：
正如您所注意到的，配置与用户配置文件而不是服务器相关联；这是因为 IIS Express 不打算用作共享开发服务器。您应该使用完整的 IIS。
我不认为使用相同的物理盒子进行开发有任何好处或理由。诚然，我不知道您使用许可或工作站资源的场景的所有细节，但让每个人都通过 RDP 进入盒子来使用 Visual Studio 似乎并没有获得太多好处 - 每个人仍然需要许可证，性能会下降速度较慢，并且您不应该在同一个项目实例上工作。
您应该认真考虑整个开发设置：
每个开发人员都应该在其工作站上使用 Visual Studio，并使用 IIS Express 进行调试/测试（在所有计算机上配置相同的端口和设置 - 非常简单）。
从那里，您的开发人员应该将他们的代码检查到源代码管理中，并检查可能出现或可能不会出现的冲突。我不确定 SVN，但 TFS 中提供的 MSBuild 自动化可用于设置部署到常见 IIS 安装的连续构建策略，以便您的合并代码经过测试并可从上述完整 IIS 安装中使用。
任何其他方法都将是一种解决方法/黑客，稍后会咬你屁股。
You probably won't like my answer but here's my thoughts:
As you noticed, the configurations are tied to the user profile and not the server; this is because IIS Express is not intended to be used as a shared development server. You should be using full IIS.
I do not see any benefit or reason to use the same physical box for development. Admittedly, I don't know all the details of your scenario with licensing or workstation resources, but it doesn't seem like you gain much from having everyone RDP into the box to use Visual Studio - each person still needs a license, performance will be slower, and you shouldn't be working on the same project instance.
You should seriously consider your entire setup for development:
Each developer should use Visual Studio on their workstation, and debug/test there using IIS Express (configured with the same ports and settings across all machines - very easy).
From there, your developers should check their code into source control, and examine conflicts that may or may not arise. I'm not sure about SVN but the MSBuild automation available in TFS can be use to setup a continuous build policy that deploys to a common IIS installation so that your merged code is tested and usable from the full IIS installation mentioned above.
Anything else would be a workaround/hack that will bite you in the butt later.