none
Can't run cloud services locally after installing Azure SDK 1.3

    Question

  • I installed the 1.3 version of the SDK after having previously been using version 1.2. Now whenever I try to run in the dev fabric I get the error...

    Windows Azure Tools for Microsoft Visual Studio

    The was an error attaching the debugger to the IIS worker process for URL 'http://127.0.0.1:5102/' for role instance 'deployment(436).WindowsAzureProject3.WebRole1.0'. Unable to start debugging on the web server. Could not start ASP.NET debugging. More information may be available by starting the project without debugging.

    If I run the project without debugging then I just get a webpage that says 

    Service Unavailable

    HTTP Error 503. The service is unavailable.

    This happens even after creating a new Windows Azure Project with a single ASP.NET web role. This exact same thing happens on two of my machines; one is running Windows 7 and the other is running Windows Server 2008 SP2.

    I noticed that the problem goes away when I set the web role's target framework to .NET Framework 3.5, but if I leave it as .NET Framework 4.0 (the default) then I get the errors.  

    How can I get things working in the development fabric with .NET 4.0?

    Friday, December 03, 2010 12:50 AM

Answers

  • sdbolts, check c:\windows\microsoft.net\framework64 (for 64-bit, or maybe \framework if 32-bit).  If there's more than one directory that starts with "v4.0", it could be a leftover from pre-RTM .NET 4 bits.  (Did you install any betas?)  Renaming those other versions should keep them from causing this problem.

    However, I'm told that if this is the problem, ASP.NET sites (.NET 4) shouldn't work under IIS at all, not just when you launch them via the Windows Azure Simulation Environment.

    Saturday, December 04, 2010 12:18 AM
  • Rinat, does the app work if you delete the <Sites> element in ServiceDefinition.csdef?  (That will get you back to using Hosted Web Core instead of full IIS.)

    If I can get code from you that reproduces the issue, I'm sure we can figure this out.

    Sunday, December 05, 2010 11:36 AM

All replies

  • Same story here as well.

    http://abdullin.com/storage/uploads/2010/12/2010-12-03_140958.jpg

    In my case, after starting without debugger I don't even see the 503 error. Lokad.CQRS code that was working perfectly for 6 months now fails to retrieve settings from the service configuration. 

    Some more details are here: http://abdullin.com/journal/2010/12/3/dont-upgrade-to-windows-azure-sdk-13-yet.html

    General advice is to avoid upgrading to Azure SDK 1.3 till Microsoft releases a patch.


    http://abdullin.com
    Friday, December 03, 2010 9:55 AM
  • sdbolts, to make sure I understand, are you saying that after installing SDK 1.3, if you simply do File/New Project/Windows Azure Application and add an empty ASP.NET web role, you get that error when you try to run?
    Friday, December 03, 2010 6:07 PM
  • I installed the 1.3 version of the SDK after having previously been using version 1.2. Now whenever I try to run in the dev fabric I get the error...

    Windows Azure Tools for Microsoft Visual Studio

    The was an error attaching the debugger to the IIS worker process for URL 'http://127.0.0.1:5102/' for role instance 'deployment(436).WindowsAzureProject3.WebRole1.0'. Unable to start debugging on the web server. Could not start ASP.NET debugging. More information may be available by starting the project without debugging.

    If I run the project without debugging then I just get a webpage that says 

    Service Unavailable

    HTTP Error 503. The service is unavailable.

    This happens even after creating a new Windows Azure Project with a single ASP.NET web role. This exact same thing happens on two of my machines; one is running Windows 7 and the other is running Windows Server 2008 SP2.

    I noticed that the problem goes away when I set the web role's target framework to .NET Framework 3.5, but if I leave it as .NET Framework 4.0 (the default) then I get the errors.  

    How can I get things working in the development fabric with .NET 4.0?


    Same problem here.
    Friday, December 03, 2010 6:35 PM
  • SMarx, That is correct. This error happens with a pristine new application with an empty web role.
    Friday, December 03, 2010 6:48 PM
  • Just a quick idea. I encounter this on 64bit Win 7. Do you have the same?
    http://abdullin.com
    Friday, December 03, 2010 6:51 PM
  • Yes, both of my machines that I have encountered this on are 64 bit. Good catch.

    Friday, December 03, 2010 6:56 PM
  • That's a potential lead for Azure team to investigate (i.e. if emulator somehow can have 32/64 disconnect with the available IIS App pools), or could be coincidence. 

    Do you have a fusion log to check for assembly loading failures?


    http://abdullin.com
    Friday, December 03, 2010 7:07 PM
  • Yes, but my laptop is 64-bit too, and everything has been working properly for me. :)

    Friday, December 03, 2010 7:08 PM
  • I'm really excited for all the new features, but can't wait for a sdk 1.3 patch!
    Friday, December 03, 2010 7:18 PM
  • Have you tried forcing Hosted Web Core mode in 1.3 by removing Sites section from Service config?
    http://abdullin.com
    Friday, December 03, 2010 7:19 PM
  • For everyone having this problem, are you able to deploy ASP.NET apps to IIS locally?  I'm wondering if IIS is missing some critical configuration.

    You might check http://msdn.microsoft.com/en-us/library/dd573369.aspx and see if anything obvious is missing from your IIS setup.

    Friday, December 03, 2010 7:27 PM
  • Yes, deployed to IIS (ASP.NET MVC and ASP.NET Forms applications).
    http://abdullin.com
    Friday, December 03, 2010 7:37 PM
  • No issues running ASP.NET apps locally under IIS. And Windows Azure applications worked locally as well just prior to installing version 1.3 of the Azure SDK.

    One additional note is that I do have both VS 2010 Ultimate and VS Team System 2008 Development Edition on both machines that have this problem.

    Friday, December 03, 2010 7:37 PM
  • Same story. VS 2008 and VS 2010.

    Additional note. When 1.3 was installed to VS 2010, I think VS2008 still kept the 1.2 version of the tools (it was not removed by the upgrade)


    http://abdullin.com
    Friday, December 03, 2010 7:41 PM
  • SDK 1.3 doesn't support VS 2010... I think in fact the VS 20008 tooling will not work if you've installed SDK 1.3.  (I seem to recall a warning about that when I was installing.)

    Friday, December 03, 2010 9:08 PM
  • If you Ctrl+F5 (run without debugging), can you see the app under inetmgr?  If so, does anything there look suspicious?

    I'm speaking with the SDK team to try to find some other troubleshooting steps...

    Friday, December 03, 2010 9:09 PM
  • Steve,

    I have made some interesting discoveries based on your suggestion.

    I went into inetmgr and saw the app running in its own application pool that was dynamically created and had a name like a GUID. I noticed that the .NET Framework Version was listed as "v4.0" whereas my other .NET 4 application pools had their .NET Framework Version listed as "v4.0.30319".  In inetmgr I then modified the site to use a different application pool and then refreshed the web page and the application worked. 

    Finally, I went into the applicationHost.config file and found the entry for the application pool that was created for the app and changed the managedRuntimeVersion attribute from "v4.0" to "v4.0.30319" like so:

                <add name="6f36da5e-0ccb-4b52-a6a5-ac3a7d477b94" autoStart="true" managedRuntimeVersion="v4.0.30319" managedPipelineMode="Integrated">
                    <processModel identityType="NetworkService" />
     
    After doing this I went back into inetmgr and changed the application back to the original application pool and refreshed the browser and the application continued to work.

    Now if only I could find a way to get the correct managedRuntimeVersion be set when the application pool is generated.

    P.S. Samantha Billinger from Montana says hi.

    Friday, December 03, 2010 11:50 PM
  • Samantha! :)

    Okay, passing this along; I suspect this will help.  For others who had similar issues, do you see the same thing?

    Friday, December 03, 2010 11:57 PM
  • sdbolts, check c:\windows\microsoft.net\framework64 (for 64-bit, or maybe \framework if 32-bit).  If there's more than one directory that starts with "v4.0", it could be a leftover from pre-RTM .NET 4 bits.  (Did you install any betas?)  Renaming those other versions should keep them from causing this problem.

    However, I'm told that if this is the problem, ASP.NET sites (.NET 4) shouldn't work under IIS at all, not just when you launch them via the Windows Azure Simulation Environment.

    Saturday, December 04, 2010 12:18 AM
  • You are correct that sites don't work at all under the misconfigured application pool regardless off how they are launched. Assigning a regular ASP.NET sit to the application pool that was generated by the azure application results in the same error.

    Yes, I do have 2 different versions of the framework that start with "v4.0". I have v4.0.30319 along with v4.0.21205 (and even a folder named Old_v4.0.21006). I renamed the v4.0.21205 to Old_v4.0.21205 and it worked!

    Thank you so much Steve!

    Saturday, December 04, 2010 12:39 AM
  • sdbolts, glad you were able to get this working.  You did all the hard work in finding the issue, thanks. :)

    For everyone else, can you try this (removing/renaming old pre-release .NET 4 bits) and see if you still have an issue?  Otherwise I'm assuming this issue is resolved for everyone.

    Saturday, December 04, 2010 12:45 AM
  • Thank you for the updates and ideas!

    I have only a single version of .NET 4.0.30139 and my sites run under the IIS ASP.NET 4.0 properly (with 1.3 or after reverting to 1.2).

    Hum, if nothing changes, then probably after the January I'll need to reinstall 1.3 and invest a day or two to figure out the root of problem in my case (given what I've learned from emails and this thread).


    http://abdullin.com
    Saturday, December 04, 2010 8:52 AM
  • Update. Some of my readers were reporting some luck with Azure 1.3.

    So I've given a try to invest some more time to install it again and upgrading solution chain to that. Still no luck on my machine.

    Running IIS properly creates web site in the manager. No debuggers get attached. That web site does not retrieve cloud environment settings (same code used to work pre1.3)

    Visual Studio is half-frozen after that. I.e.: impossible to exit or navigate Solution explorer (as if modal window was active). "Run (F5)" is disabled as if VS is still starting project. The only way to do anything is to kill the process.

    After modifying settings retrieval code SEH: Operation failed shows it's head in the HttpAppStart:

    [SEHException (0x80004005): External component has thrown an exception.]
      RdGetApplicationConfigurationSetting(UInt16* , UInt16** ) +0
      RoleEnvironmentGetConfigurationSettingValueW(UInt16* pszName, UInt16* pszDest, UInt64 cchDest, UInt64* pcchRequiredDestSize) +67
      Microsoft.WindowsAzure.ServiceRuntime.Internal.InteropRoleManager.GetConfigurationSetting(String name, String& ret) +117
      Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetConfigurationSettingValue(String configurationSettingName) +231
      Lokad.Cqrs.CloudSettingsProvider.GetString(String key) in :0
      Salescast.UI.GlobalSetup..cctor() in D:\Lokad.Salescast\Solution\Source\Salescast.Web\Core\GlobalSetup.cs:31
    
    [TypeInitializationException: The type initializer for 'Salescast.UI.GlobalSetup' threw an exception.]
      Salescast.UI.GlobalSetup.InitIfNeeded() in D:\Lokad.Salescast\Solution\Source\Salescast.Web\Core\GlobalSetup.cs:51
    
    [HttpException (0x80004005): The type initializer for 'Salescast.UI.GlobalSetup' threw an exception.]
      System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app) +3988565
      System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +191
      System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +325
      System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +407
      System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +375
    
    [HttpException (0x80004005): The type initializer for 'Salescast.UI.GlobalSetup' threw an exception.]
      System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +11529072
      System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +141
      System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +4784373

    This brings us all the way back to the original thought that for some reason web app is not able to communicate with the cloud environment after the separation of these two in 1.3.

    Rolling the environment back to 1.2 once more. 1.3 turns out a bit too expensive right now.


    http://abdullin.com
    Sunday, December 05, 2010 9:53 AM
  • Rinat, does the app work if you delete the <Sites> element in ServiceDefinition.csdef?  (That will get you back to using Hosted Web Core instead of full IIS.)

    If I can get code from you that reproduces the issue, I'm sure we can figure this out.

    Sunday, December 05, 2010 11:36 AM
  • Indeed, dropping <Sites> did work for the local deployment. I've updated my blog post with the latest status, highlighting Sites workaround.

    I'll try to create project replicating the problem and email it, when time allows.

    For now I'll stay with 1.2.


    http://abdullin.com
    Sunday, December 05, 2010 12:54 PM
  • Hi,

     

    Is there a more structured solution to this problem? I am facing the same issue. I wasn't able to publish our solution as it was waiting for hours and I was forced to install SDK 1.3 to figure out what will change and now I am having the same issue.

     

    When I drop <Sites> from the web.config, it works but I would prefer to have a better solution.

     

    Regards,

    Tuesday, December 07, 2010 10:51 PM
  • Murat, what's the exact problem you're having?  (This symptom, of the debugger being unable to connect, doesn't by itself indicate the problem.)

    When you run, I assume you get the error message about the debugger being unable to connect?  If you run without debugging, what happens?  Have you checked to see if you have pre-released .NET 4 bits on your machine?  When you run without debugging, can you see your application with inetmgr, and does anything there seem wrong?

    If you can share it, feel free to send me your solution at Steve.Marx@microsoft.com, and I'd be happy to take a look.

    Wednesday, December 08, 2010 12:25 AM
  • Hi Steve,

    To be honest, this looks more like a general IIS 7 issue. I created a new asp.net web application and on Web tab of the project properties, I picked "Use Local IIS Web server" option. And if I try to debug the application, I get the error "Unable to start debugging on the web server. The remote debugging components are not registered or running on the web server".

     

    If I try to run without debugging, it works. I uninstalled and installed IIS with all its components and installed the latest .net 4 bits. I don't have any other .net 4 version on the box yet. 

    So As I said, I guess this is more of a IIS and .Net 4 issue.

    Wednesday, December 08, 2010 12:34 AM
  • Interesting.  Glad to know it's not specific to Windows Azure, but I don't have any guesses for you as to what the underlying issue might be.  If you do figure it out, let us know here, since other Windows Azure users might be bitten by the same thing.
    Wednesday, December 08, 2010 12:42 AM
  • Steve,

    I think I am hitting either the same or a similar problem to Rinat's above. In my case it appears to be related to the use of CloudStorageAccount.FromConfigurationSetting. Having read your blog post on the subject yesterday I tried the Thumbnails sample, adding in a Global.asax and inserting the code to execute CloudStorageAccount.SetConfigurationPublisher from the Application_Start as you suggested in the blog. However, when the handler code gets executed RoleEnvironment.GetConfigurationSettingValue throws an exception that looks the same as that indicated by Rinat above ie

      StackTrace "   at RdGetApplicationConfigurationSetting(UInt16* , UInt16** )\r\n   at RoleEnvironmentGetConfigurationSettingValueW(UInt16* pszName, UInt16* pszDest, UInt32 cchDest, UInt32* pcchRequiredDestSize)\r\n   at Microsoft.WindowsAzure.ServiceRuntime.Internal.InteropRoleManager.GetConfigurationSetting(String name, String& ret)\r\n   at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetConfigurationSettingValue(String configurationSettingName)\r\n   at Thumbnails_WebRole.Global.<Application_Start>b__0(String configName, Func`2 configSetter)...

    If you could talk us through how to get the Thumbnails sample to run locally when using the 1.3 SDK and tools it may be a useful start point for resolving the problems we are having.

    Thanks,

    Gael Wilson.

    Thursday, December 09, 2010 1:33 PM
  • Since my previous post I have discovered what was causing the exceptions I was seeing. Some time ago I had configured IIS to use 32-bit worker processes by default. After changing it back to 64-bit I was able to get the Thumbnails sample running.

    Hope this is useful. By the way the command I ran to reset IIS was

    %windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.enable32BitAppOnWin64:false

    Thursday, December 09, 2010 3:32 PM
  • I`m much less productive, development wise, since I upgraded to SDK 1.3.

    Here`s what I`m working with.

    Windows 7 64bits

    Visual Studio 2010 Premium

    ASP.NET MVC 3 RC (Razor)

    .Net v4.0.30319

     

    What help, getting better stability:

    - Using Hosted Web Core instead of Full IIS

    - Shutting down the Compute et Storage Emulator, before each time you run your app (before F5)

    Thursday, December 09, 2010 5:34 PM
  • Azure514, can I ask what shutting down the storage emulator is helping with?  (What gives you trouble if you don't do that?  And was it different in SDK 1.2?)
    Thursday, December 09, 2010 6:15 PM
  • I don't think the storage Emulator has something to do, I just click Exit so it Shutdowns both.

    Since SDK 1.3, if I don`t Shutdown the Compute Emulator each time I start my app, I don`t go further than Application_Start  in Global.asax (most of the time).

    That helps a lot, but still not as stable as SDK 1.2, for me that was from far the most stable version.

    Thursday, December 09, 2010 7:43 PM
  • Rinat, does the app work if you delete the <Sites> element in ServiceDefinition.csdef?  (That will get you back to using Hosted Web Core instead of full IIS.)

    If I can get code from you that reproduces the issue, I'm sure we can figure this out.


    This worked for me also, I had a project that could debug in 1.2 as soon as I upgraded to 1.3 it stopped working until I removed the sites element.

    Sunday, January 02, 2011 2:32 AM
  • Not sure how many of you this will work for, but after trying all manner of complicated fixes for this (including most of the options reccomened on this thread), the following simple solution got everything working for me.

    Get a command prompt in administrator mode, navigate to C:\Windows\Microsoft .NET\FrameWork64\v4.xxx and run aspnet_regiis -r. This will reregister the libraries which, for some reason, randomly gets hosed after installing v1.3 of the SDK.

     

    That fixed everything for me.  Hope it does the same for at least some of you.

    • Proposed as answer by suciua Monday, October 31, 2011 5:27 PM
    Sunday, January 30, 2011 7:46 AM
  • Everything has been quiet on this thread for the last few weeks. I have the same problem. I have tried every solution. I can easily duplicate the problem and it fails every time.

    Is there anyone out there from Microsoft looking into this problem?

    In my case I created an Azure cloud project and attached a MVC2 web role.

    Debug works fine

    I added another MVC2 application and modified my Service Definition to use <Sites>

    Changed both MVC2's to IIS

    Clicked Debug button and the message appears. 

     

    It took me less than five minutes to duplicate this. I hope it's being looked at and hope for a solution in SDK 1.4 ...

     

    Gordon

    Saturday, February 26, 2011 2:40 PM
  • I was able to fix this issue on my machine by hiding (renaming) a bunch of old versions of the V4 framework.  I hid all the previous version directories c:\windows\Microsoft.Net\Framework\V4.0.xxxxx except the most recent one: v4.0.30319.  So the post marked as the answer woeked for me.

    (I had a lot of old V4 versions that I had on this machine because as part of a Microsoft team working on Expression, we were taking new VS2010 and .NET 4 builds every couple of weeks for a while)

    - Rick

     

     

    Sunday, February 27, 2011 4:28 AM
  • Checked out the .NET 4 frameworks a few times now.  All I have is this one: v4.0.30319  and some older 2, 3 and 3.5. I have also tried a repair of the v4.0.30319


    Nothing working for me as yet :-(

     

    Gordon

    Sunday, February 27, 2011 10:53 AM
  • I've got the same issues here. I built a webapp and released it to a staging environment, it worked perfectly. When I changed the webapp and upgraded the solution, it didn't work anymore on azure, I got an internal server error 500.

    Trying to debug the application locally with azure, showed me that it couldn't be debugged anymore?

    The webapp itself works fine.

    Tried to do a aspnet_regiis.exe -r but no luck, also only have one .NET Framework 4.0 folder. Rebooted the machine, no luck.

    Any idea's?

    Kind regards


    it's all very nice when it works
    Monday, February 28, 2011 3:11 PM
  • I spent another FIVE minutes with a fresh install. Hopefully someone at Microsoft can also spend just five minutes to check this out. Here I will show you how I can make it work and how I can make it fail. Total time spent testing it out was less than 10 minutes. Results were 100% repeatable:

     

    Works:
    
    <Sites>
    <Site name="Xx" physicalDirectory="..\Xx.WebUx"> <Bindings> <Binding name="Endpoint1" endpointName="Endpoint1" /> </Bindings> 
    </Site> 
    </Sites>
    
    Fails with can't debug message: 
    
    <Sites> 
    <Site name="Xx" physicalDirectory="..\Xx.WebUx"> <Bindings> <Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="www.xx.com" /> </Bindings> 
    </Site> 
    </Sites>
    
    Works:
    
    <Sites>
    <Site name="Xx" physicalDirectory="..\Xx.WebUx"> <Bindings> <Binding name="Endpoint1" endpointName="Endpoint1" /> </Bindings> 
    </Site> 
    </Sites>
    
    Fails with can't debug message: 
    
    <Sites> 
    <Site name="Xx" physicalDirectory="..\Xx.WebUx"> <Bindings> <Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="www.xx.com" /> </Bindings> 
    </Site> 
    </Sites>

     

    Adding hostheader makes it fail every time for me.

    Tuesday, March 01, 2011 4:35 AM
  • Hi Gordon,

    If you specify a host header for your endpoint, you need need to make sure that the DNS name is resolvable because Visual Studio will try to attach to the site at that endpoint. If this is the problem, the error message will typically say something like "There was an error attaching the debugger to the IIS worker process for URL 'www.xx.com'.

    If you are using a fake name just for testing, you can add an entry in your hosts file. That should take care of the issue. 

     

    Tuesday, March 01, 2011 2:15 PM
  • Hi,

    Tried this, but unfortunatly it didn't work. As I read this a lot of people have problems publishing multiple sites to one deployment. I connected to the remote machine and opened IIS. Maybe you can try and change things here? Although I have no idea how to configure this when you are running more then one isntance.


    it's all very nice when it works
    Wednesday, April 27, 2011 11:46 AM