Visual studio 2010 如何指定应用绑定到的IP地址？

我们正在开发一个相当复杂的系统，涉及几个不同的应用程序（MVC、基于http的WCF、基于TCP的WCF、ADF和一些通用的工作者角色），所有这些都部署到Azure。对于本地调试，我们需要在本地开发结构和IIS中运行这些。我已经完成了几乎所有我需要做的事情，并且一切正常，除了一件事：我无法预测各种事情将在Dev结构中绑定到什么IP地址。有时是127.0.0.1，有时是127.0.0.3，有时是127.0.0.4（可能还有其他一些？）。对于我的配置文件转换和ADF依赖方信任，我需要提前知道这些IP是什么

---

我如何管理/控制（或至少预测）这些专门针对我的网站的IP地址？（WCF很好）如果我可以在引用适当的IP的情况下将所有内容部署到我的开发结构中，那么所有内容都可以正常工作！然而，这样做非常麻烦，每次需要对web.config和app.config转换文件进行几次调整（更不用说每次更改时重新配置ADFS服务器），因此这无论如何都不是一种可持续的情况

我们在ASP.NET MVC解决方案中遇到了类似的挑战，该解决方案使用第二个web角色运行WIF STS。MVC应用程序的web.config在本地仿真器中运行时需要知道STS的非负载平衡器IP地址

Import-Module WebAdministration
Stop-WebSite 'Default Web Site'

$env:WindowsAzureEmulatorInstallPath = (Get-ItemProperty -Path "Registry::HKLM\Software\Microsoft\Windows Azure Emulator" -Name InstallPath).InstallPath
$env:ServiceHostingSDKInstallPath = $env:WindowsAzureEmulatorInstallPath + '.NET SDK\2012-10'

$env:Path = $env:WindowsAzureEmulatorInstallPath + 'emulator;' + $env:WindowsAzureEmulatorInstallPath + 'devstore;' + $env:ServiceHostingSDKInstallPath + 'bin;' + $env:Path

csrun /devfabric:start
csrun /devstore:start
csrun /removeAll
csrun /devfabric:clean

csrun Application\Foobar.Extensions.Azure\csx\AzureLocal Application\Foobar.Extensions.Azure\bin\AzureLocal\app.publish\ServiceConfiguration.Local.cscfg

Write-Host "Application Pools to Attach for Debugging"
get-item IIS:\AppPools\*

$ie = New-Object -ComObject InternetExplorer.Application
$ie.Navigate("https://127.255.0.1:444")
$ie.Visible = $true

此外，我们有自定义的代码构建URL路由，它只能看到模拟器分配的内部IP地址（127.255.0.X）。这些路由在通过负载平衡器传回时会导致问题。我们还关闭IIS中的默认网站，以保证仿真器完成端口重新映射

Import-Module WebAdministration
Stop-WebSite 'Default Web Site'

$env:WindowsAzureEmulatorInstallPath = (Get-ItemProperty -Path "Registry::HKLM\Software\Microsoft\Windows Azure Emulator" -Name InstallPath).InstallPath
$env:ServiceHostingSDKInstallPath = $env:WindowsAzureEmulatorInstallPath + '.NET SDK\2012-10'

$env:Path = $env:WindowsAzureEmulatorInstallPath + 'emulator;' + $env:WindowsAzureEmulatorInstallPath + 'devstore;' + $env:ServiceHostingSDKInstallPath + 'bin;' + $env:Path

csrun /devfabric:start
csrun /devstore:start
csrun /removeAll
csrun /devfabric:clean

csrun Application\Foobar.Extensions.Azure\csx\AzureLocal Application\Foobar.Extensions.Azure\bin\AzureLocal\app.publish\ServiceConfiguration.Local.cscfg

Write-Host "Application Pools to Attach for Debugging"
get-item IIS:\AppPools\*

$ie = New-Object -ComObject InternetExplorer.Application
$ie.Navigate("https://127.255.0.1:444")
$ie.Visible = $true

在Azure 1.8 SDK中，我们观察到，当从命令行启动应用程序并删除dev结构中的所有其他部署时，本地仿真器将一致地分配127.255.0.X地址

我们构建了一个PowerShell脚本，一旦解决方案打包到VS2010中，就可以从命令行启动Web角色。我们有一个名为AzureLocal的构建配置和web转换，用于为本地仿真器打包

Import-Module WebAdministration
Stop-WebSite 'Default Web Site'

$env:WindowsAzureEmulatorInstallPath = (Get-ItemProperty -Path "Registry::HKLM\Software\Microsoft\Windows Azure Emulator" -Name InstallPath).InstallPath
$env:ServiceHostingSDKInstallPath = $env:WindowsAzureEmulatorInstallPath + '.NET SDK\2012-10'

$env:Path = $env:WindowsAzureEmulatorInstallPath + 'emulator;' + $env:WindowsAzureEmulatorInstallPath + 'devstore;' + $env:ServiceHostingSDKInstallPath + 'bin;' + $env:Path

csrun /devfabric:start
csrun /devstore:start
csrun /removeAll
csrun /devfabric:clean

csrun Application\Foobar.Extensions.Azure\csx\AzureLocal Application\Foobar.Extensions.Azure\bin\AzureLocal\app.publish\ServiceConfiguration.Local.cscfg

Write-Host "Application Pools to Attach for Debugging"
get-item IIS:\AppPools\*

$ie = New-Object -ComObject InternetExplorer.Application
$ie.Navigate("https://127.255.0.1:444")
$ie.Visible = $true

---

您的应用程序听起来比我们的STS和MVC组合有更多的活动部件，但是如果您可以在Visual Studio之外编写启动脚本，那么您可以获得可预测的地址分配。

您使用的是哪一版本的Azure SDK？我正在使用工具的v1.8版本（2012年10月），并且似乎是我刚刚检查的一个DLL（StorageClient）是v1.7.0.0。如果升级是必要的，那很好-我们可以这样做（而且无论如何都会很快）。仅供参考，我的问题似乎与相同，但这个答案似乎不适用于我。无论我尝试什么端口，127.0.0.1都不会将我带到我的web角色。从现在起，就是我要去的地方。每次更改时都必须如此频繁地重新配置东西（对于每个开发人员来说），这真的很痛苦……好吧，这个问题并不完全相同。似乎他想要特定于实例的IP。我对“负载平衡器”IP很满意。不过，我只需要一些可预测的东西。你试过了吗？你回答我的问题时只给出了很小的一部分：“并且删除了dev结构中的所有其他部署”。这是我们的问题。当其他东西部署到dev结构时，分配的IP地址会不断增加，但在删除所有部署时会重置。这当然不是很理想，但这是我们调试东西的关键部分，在每次编译之间不需要大量的停机时间。每次重新启动/重新启动仿真器的开销都太大，但我们至少可以解决这个问题。真希望我们能处理得更好@Jaxidian我理解您来自何方，因为我们花了大量的尝试和错误，才为多台开发机器找到一个可行的本地配置。