We have a fairly complex system we're developing involving a few different applications (MVC, http-based WCF, TCP-based WCF, ADFS, and some generic Worker Roles), all deployed to Azure. For local debugging, we need these to run in the local Dev fabric as well as IIS. I've accomplished pretty much everything I need to and it all works, with the exception of one thing: I can't predict what IP address various things will bind to in the Dev Fabric. Sometimes it's 127.0.0.1, sometimes it's 127.0.0.3, and sometimes it's 127.0.0.4 (and maybe some others?). For my config file transforms and ADFS relying-party trusts, I need to know what these IPs will be in advance.
How do I manage/control (or at least predict) these IP addresses specifically for my web site? (WCF is all good) If I can actually get everything deployed to my dev fabric with the proper IPs being referenced, then everything works! However, it's very cumbersome to do and takes several tweaks to web.config and app.config transformation files every single time I need to (not to mention reconfiguring the ADFS server every time it changes), so this isn't a sustainable situation by any means!
We had a similar challenge with an ASP.NET MVC solution that uses a second web role running a WIF STS for Claims-Based Authentication. The web.config of the MVC application needed to know the non-load balancer IP address of the STS when running in the local emulator.
In addition, we have custom code building URL routes that only sees the internal IP address (127.255.0.X) assigned by the emulator. These routes would cause problems when passed back through the load balancer. We also shutdown the Default Web Site in IIS to guarantee the port remapping done by the emulator.
With the Azure 1.8 SDK, we observed the local emulator would consistently assign the 127.255.0.X addresses when the application was started from the command line and all other deployments in the dev fabric were removed.
We built a PowerShell script to startup the Web Roles from the command line once the solution was packaged inside VS2010. We have a build configuration and web transformation called AzureLocal we use to package for the local emulator.
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
Your applications sounds to have more moving parts than our STS and MVC combination, but if you can script the startup outside Visual Studio then you can get predictable address assignment.
Related
I have an Azure service containing a web role. Both configured to run on IIS Server locally. I would like to build/deploy and start the web role in a specific URL in Visual Studio. It always ends up in addresses using 127.0.0.1 even I specify what project URL is in the project configuration. Is there any way to change this something like dev.xxx.com?
You're running through the local emulator I assume. As such, the URL project settings won't apply. Just like if you deploy it to the cloud, you'll need some type of DNS forwarder or alias.
I've created a Silverlight application that uses a service. The service is defined in the web project in that solution. The silverlight application references it and uses it.
Everything works locally on my dev machine when I run the application in Visual Studio.
I note that the url im given from VS is: http://localhost:50453/Default.htm
But when I deploy this (by filesystem copy deploy option) the web page starts and it looks okey except that it seems to have a problem using the service.
In the Silverlight application, if I look at the reference settings the url to the service is: http://localhost:50453/SilverlightService.svc and thats probably whats wrong, as the server that Im deploying to does not have a clue whats on port 50453.
So Im trying to change this port to 80 on my dev machine but Im out of luck. My web project does not have any property where I can change the port. Opened URL and URL is locked at http://localhost:50453 :-/
How can I change the my dev environment to match the production environment with port 80?
For sure you can change the web project's URL in project properties, but this is not a good solution because you'll get the same problems when accessing the SL application from a remote computer.
You need to set the service URL programmatically, like above:
ServiceReference1.Service1Client svc = new ServiceReference1.Service1Client();
Uri serviceUri = new Uri(System.Windows.Browser.HtmlPage.Document.DocumentUri, "Service1.svc");
svc.Endpoint.Address = new System.ServiceModel.EndpointAddress(serviceUri);
This solution uses the same URL that you are using to access the Silverlight Application.
When I create a new "WCF Service Application" in Visual Studio and right-click Service1.svc, I can choose "View in Browser". A web browser appears showing http://localhost:50311/Service1.svc, which says
Service1 Service
You have created a service.
To test this service, you will need to create a client and use it to call the service. You can do this using the svcutil.exe tool from the command line with the following syntax:
svcutil.exe http://localhost:50311/Service1.svc?wsdl
...
The service somehow seems tied to Visual Studio itself, since the web page becomes inaccessible if I close the solution. What's going on? I don't have a web server installed, and I didn't (knowingly) start the service. What is the source of the displayed web page, and why is it on port 50311? Can the page be customized?
What you're seeing is the development web server that starts when you run a debugger instance of a project that requires a web server. (WCF, ASP.NET).
The port 50311 is determined by your project settings (most likely random, but you can specify).
The page for a .svc file is not meant to be customized. Since the service is waiting for a caller, that default page simply tells you that it's running properly.
Keep in mind that WCF offers several binding options that use various protocols (HTTP, TCP). Depending on the protocol that you choose, you will have to host in either IIS, a Windows Service or elsewhere. By default, new services will adopt a binding that works in IIS.
Check out Introduction to Building Windows Communication Foundation Services
This question has probably less to do with actual programming and more to do with environment setup.
I'm developing an application for a Windows CE device, which will use a service hosted in Microsoft Azure. Obviously, this is all under development, and the service itself has not yet been uploaded to Azure. So I'm using the emulators provided by MS to deploy the service locally. Also, I don't think uploading the service to Azure just to debug it is a good idea, as that could net us a bill for Azure we don't yet want to pay.
Also, please note, I'm using VS2008 for the Windows CE project and VS2010 for the Azure project (thank you MS for dropping support for mobile devices -_-).
The problem is, the service seems to be accessible only via 127.0.0.1 or localhost, and if I physically connect a Windows CE device or use an emulated one, it becomes a new entity on the network, and cannot access that service any more.
How can I debug my Window CE application and have it see the service, whilst still being able to debug the service itself?
You are correct, the development fabric (the compute emulator that allows you to build an azure application and debug it locally) is only meant for local development. There are some hacks that allow you to get around that, but I wouldn't recommend it.
My recommendation would be to spin up the service in a more traditional hosting environment, at least in these early stages. You can define it as a web app just as you always would have, and get it functioning. Then, when you know its mostly complete, create a cloud service project and do an add existing to bring your web app into the cloud service solution. Once in, its a simple matter to add the web app as a web role.
From there, you can complete testing of the service in both the local and hosted azure environments as needed. This allows you to minimize your development costs while still leveraging the power of the cloud. As an upside, you also have done most of the basic work to ensure your service is compatible with multiple deployment scenarios giving you a greater degree of choice for its final production state.
OK, I don't know if this was intentional, or if I found one of the mentioned hacks, but I saw that IIS hosts the Azure site I created on port 5100, and the binding for this site is *, so it accepts all connections.
Using this I could access the service from my emulator, and I could still debug all Azure related stuff.
We're developing an application that is sensitive to the domain name of the request. The problem we're running into is that we have to use IIS in order to test the application because Cassini will only send "localhost" as the requested domain despite using a different domain in the address bar. While IIS does give us better performance than Cassini, we would still like to be able to hit F5 to run our application from within Visual Studio.
Is there any configuration that can be done to specify the domain name to use in Cassini?
I just released the CassiniDev 3.5.1/4.0.1 beta with a simple test fixture example if you are interested.
It supports arbitrary IP addresses and host names. Should fit your needs quite nicely.
http://cassinidev.codeplex.com