none
Two Apps Suddenly Are Unable to Load Data RRS feed

  • Question

  • Hello,

    This problem may or may not be from LightSwitch.  I have two apps on Azure websites, with Azure DBs.  One has been working great since deployment, about 10 months ago.  The other has been working well since Nov.  As of today, both are unable to run their queries or load data. 

    Nothing has changed on our end and I am getting so many different error codes, but the gist is that they are unable to connect.

    I've checked both databases and they are working.

    I've noticed one error message that says the URI http://site.azurewebsites.net//ApplicationData.svc/etc is not valid because it is not based on http://site.azurewebsites.net/ApplicationData.svc/

    Does anyone else have a production app this has happened to?  Or know how to get those URIs matching again? Any help would be greatly appreciated!

    Thanks,

    C

    Thursday, January 29, 2015 1:53 AM

Answers

  • While we are still investigating the issue, can you please try this possible workaround:

    • Go to Kudu Console for your site
    • Go in the site folder (i.e. D:\home\site)
    • Run 'touch applicationhost.xdt' to create an empty file
    • Hit the edit button for that file and paste the following contents into it
    • Restart the site

    Here is the content of applicationhost.xdt:

    <?xml version="1.0"?>
    <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
      <system.webServer>
        <rewrite>
          <allowedServerVariables>
            <add name="UNENCODED_URL" xdt:Transform="InsertIfMissing" />
          </allowedServerVariables>
    
          <rules>
            <rule name="FixSvcPath" xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing">
              <match url="^.*svc/" />
              <conditions>
                <add input="{UNENCODED_URL}" pattern="/(/.+)" />
              </conditions>
              <serverVariables>
                <set name="UNENCODED_URL" value="{C:1}" />
              </serverVariables>
              <action type="None" />
            </rule>
          </rules>
        </rewrite>    
      </system.webServer>
    </configuration>

    Once the real fix gets deployed later, you can safely delete this file.

    • Edited by David Ebbo Sunday, February 1, 2015 1:26 PM
    • Proposed as answer by novascape Sunday, February 1, 2015 8:56 PM
    • Marked as answer by Angie Xu Monday, February 9, 2015 1:41 AM
    Sunday, February 1, 2015 2:21 AM
  • Tom,

    The fix for Mark was applied to one specific cluster. It may be possible to apply it to yours as well if we have your site name.

    However, after further tweaks, I think you'll find that the workaround I gave above will completely fix your site. Search for applicationhost.xdt in this thread. It will take you 5 minutes to do this, while the cluster patch is a bigger process, so please do try this first.

    Note that the complete real fix is still upcoming and will be global.

    David

    • Proposed as answer by MajorT Sunday, February 1, 2015 2:26 PM
    • Marked as answer by Angie Xu Monday, February 9, 2015 1:41 AM
    Sunday, February 1, 2015 1:41 PM

All replies

  • I don't have a fix but I'm getting the same problem. This is my first deployment to Azure and I thought it was me. It runs like a champ on my local machine. The problem is obviously related to the extra slash in the url.  I tried upgrading to the latest datajs and that didn't make any difference. 
    Thursday, January 29, 2015 2:50 AM
  • Hi, thanks.  If I can get an answer, I'll be sure to let you know.
    Thursday, January 29, 2015 3:28 AM
  • Still about to lose my mind...

    As a test I created a new Lightswitch app with VS2013 and the latest updates. Added one table. Created a browse screen. Published to Azure websites. Login fine. Get a 400 bad request when the screen comes up. So I enabled tracing and it essentially can't get the metadata from the service (400). 

    If I try to hit the service directly from the menu bar I get:

    <?xml version="1.0" encoding="utf-16"?><ExceptionInfo><Message>The URI 'https://testhtmlclient.azurewebsites.net//columboData.svc/' is not valid because it is not based on 'https://testhtmlclient.azurewebsites.net/columboData.svc/'.</Message></ExceptionInfo>

    I guess the good news is that the error is not due to some external dependency I've added to the app. In the actual app I'm trying desperately to deploy I use MVC for user registration. 

    On the other hand, I don't understand why there isn't a general uproar about this if the simplest possible LS app can't be deployed to Azure. 

    Friday, January 30, 2015 12:22 AM
  • Hey,

    We got our apps running again.  These are the steps we took:

    1. Switch to a different Azure subscription
    2. Create a new website on a new web hosting plan and a new SQL Server
    3. Create a new database (on the new server) and set the scale to Web
    4. In the website change the connection string on the configure tab to match the connection string on the database dashboard: quick glance: Show Connection String
    5. Publish from VS to the new azure website and database

    Right now that's got us running again.

    Hope it helps,

    C

    Friday, January 30, 2015 1:58 PM
  • I am surprised myself as to why there is no uproar. All four of my development sites went down. Not good!

    Moved most important to cloudapp.net and it worked. Time!

    Will try your steps with websites.net.

    Thank you for sharing.


    rggwja


    • Edited by rggwja Friday, January 30, 2015 10:18 PM
    Friday, January 30, 2015 9:11 PM
  • I have just encountered the same problem. My customer is not happy!!!

    I am not sure what to do about this?


    • Edited by Ian E Saturday, January 31, 2015 3:51 AM
    Saturday, January 31, 2015 3:51 AM
  • Hi folks. We've seen several reports of this issue and our engineers are actively and urgently investigating. Sorry for the inconvenience!  We have partially rolled out a service upgrade and we suspect that is responsible.

    As a potential mitigation, you can try redeploying your site to a new region such as Central US and East Asia, which are known to be okay. For all other regions, there is a chance that simply moving your site may place it on a VM which is not affected by this issue.

    Again, really sorry about this. We'll keep this thread posted with any updates.

    UPDATE #1:

    We've now isolated the impacted clusters so it is now possible to mitigate this issue simply moving your website to a new resource group (you can remain in the same region if you like but a new resource group is required). The only region we were not able to isolate is Brazil, so any customers in Brazil will need to migrate to a new region.

    More updates to come as we try to root cause the issue.




    Saturday, January 31, 2015 6:37 PM
  • Chris:

    Just want to let you know that we are getting this issue also:

    An error occurred while running the command.
    Error details: The URI 'http://XXXX.azurewebsites.net//ApplicationData.svc/PLLineItems()?$filter=Client/Id eq 1159' is not valid because it is not based on 'http://XXXX.azurewebsites.net/ApplicationData.svc/'

    This is in the South Central US region.

    Mark

    Saturday, January 31, 2015 7:01 PM
  • Hi,

    we also experienced this issue in West Europe with one of our production Websites. I just moved to North Europe and the issue is gone for now.

    Andrei

    Saturday, January 31, 2015 7:20 PM
  • Hi,

    All my sites in Brazil South suddenly stopped with the same problem.

    Saturday, January 31, 2015 7:38 PM
  • Thanks Mark, Andrei and AngeloOS for the updates. This confirms what we're seeing on our end too. I've updated my previous post with more information on how to work around this issue (for those still impacted).

    AngeloOS, unfortunately at the moment we will need you to move your site to a new region as Brazil South is the one region where we were not able to isolate the issue. Again, so sorry for the inconvenience! We are actively working on this.

    Saturday, January 31, 2015 7:46 PM
  • Hello Chris,

    All my Lightswitch applications are on azurewebsites West-Europe, and all have the same issue. I created another resource group, but it does not allow me to move my websites to this new resource group.

    As far as I know, to move websites to new resource group, I have to go to "Websites" in the "Browse" section of the new portal, and then I have to select "Change web hosting plan", but It does not allow me to choose the new resource group from the list. Could you please let me know how I should move websites to new resource group?

    Thanks,

    Keysen

    Sunday, February 1, 2015 1:52 AM
  • While we are still investigating the issue, can you please try this possible workaround:

    • Go to Kudu Console for your site
    • Go in the site folder (i.e. D:\home\site)
    • Run 'touch applicationhost.xdt' to create an empty file
    • Hit the edit button for that file and paste the following contents into it
    • Restart the site

    Here is the content of applicationhost.xdt:

    <?xml version="1.0"?>
    <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
      <system.webServer>
        <rewrite>
          <allowedServerVariables>
            <add name="UNENCODED_URL" xdt:Transform="InsertIfMissing" />
          </allowedServerVariables>
    
          <rules>
            <rule name="FixSvcPath" xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing">
              <match url="^.*svc/" />
              <conditions>
                <add input="{UNENCODED_URL}" pattern="/(/.+)" />
              </conditions>
              <serverVariables>
                <set name="UNENCODED_URL" value="{C:1}" />
              </serverVariables>
              <action type="None" />
            </rule>
          </rules>
        </rewrite>    
      </system.webServer>
    </configuration>

    Once the real fix gets deployed later, you can safely delete this file.

    • Edited by David Ebbo Sunday, February 1, 2015 1:26 PM
    • Proposed as answer by novascape Sunday, February 1, 2015 8:56 PM
    • Marked as answer by Angie Xu Monday, February 9, 2015 1:41 AM
    Sunday, February 1, 2015 2:21 AM
  • Hi

    Same here. I have a production site that's down with angry users shouting at me!

    All I did last night was publish a small change and since then I cannot recover.

    1. Published to staging.

    2. Swapped staging and production.

    3. Test fails with (a) HTML client screen opens then gives "Request failed with status '400' and status 'Bad Request', (b) LS client loads the screen then shows a series of errors starting with 'Exception has been thrown by the target of an invocation'.

    4. Swapped staging and production to recover - now when I try to login I get no screen and errors saying my .config file is wrong (can't remember exactly what came up.

    5. Start to really sweat/panic - wife joins in the yelling with complaints pouring in - telling me I've stuffed up.

    6. Try publishing from my backup - same issue.

    7. After much experimentation I go to my final resource - may last backup at www.getcloudcellar.com was 6 days ago and the next will run in <24 hours.

    8. I try to restore just the files (not the database). Same issue.

    9. In desperation to pacify customers (and wife) with sweat pouring at this stage - I hit the restore files and database - blowing away a weeks worth of customer data.

    10. Now I'm really stuffed - backup doesn't help. So I'm sitting with an out of date database that my customers will scream at me when they (hopefully) get back online and a system that doesn't work.

    Note to self: Some days just don't get out of bed.

    Please assist ASAP. This is going to break my business (and probably my marriage in the process).

    Thanks, Mark.


    Mark

    Sunday, February 1, 2015 2:41 AM
  • Hi

    Glad you are up but my site is in full production.

    I can't just blow everything away and start from scratch.

    Do you have a suggested path of action for a production site that's down?

    Thanks, Mark.


    Mark

    Sunday, February 1, 2015 2:44 AM
  • Mark, please see my previous reply and give that a try.
    Sunday, February 1, 2015 2:46 AM
  • Hi

    My HTML and SL apps were developed using LightSwitch and I'm no technical guru.

    So when you suggest "We've now isolated the impacted clusters so it is now possible to mitigate this issue simply moving your website to a new resource group (you can remain in the same region if you like but a new resource group is required)."

    Can you please provide instructions on how a non-DB Admin can do this.

    Thanks, Mark.


    Mark

    Sunday, February 1, 2015 2:50 AM
  • Not following you, as you're quoting someone else's reply.
    Sunday, February 1, 2015 2:51 AM
  • Hi David

    I registered and followed links to get to the screen shown below.

    Am I on the correct page? I don't see a 'site folder'.

    Thanks for assisting. It's a bit unnerving having a bunch of people yelling at me while I'm trying to get them back online :-/

    Thanks, Mark.


    Mark

    Sunday, February 1, 2015 3:13 AM
  • Click 'Debug console' at the top and choose CMD. Then click on the site folder, etc...
    Sunday, February 1, 2015 3:14 AM
  • Mark, if the steps are not clear, I can try to do it for you.
    Sunday, February 1, 2015 3:23 AM
  • Hi David

    I greatly appreciate your assistance but I'm stuck at the next action (see screen-shot below).

    I granted full permission to 'everyone' to my D drive but I still get the error. Not sure why it picked my D drive - that's just an empty SD card.

    Thanks again, Mark.


    Mark

    Sunday, February 1, 2015 3:25 AM
  • Hi David

    That would be Fantastic!

    Just let me know how I should send my credentials and anything else you need. Obviously I wouldn't post that openly on this forum so maybe I could email you what you need. Is that Ok?

    Thanks, Mark.


    Mark

    Sunday, February 1, 2015 3:29 AM
  • This is not your local D: drive but the one on the site. Just follow the instructions above. Go into the 'site' folder before doing the touch.
    Sunday, February 1, 2015 3:30 AM
  • Hi Dave

    Ok. Went to the Site folder and that worked so I'll carry on with your instruction and try to pay closer attention ;-)

    D:\home>
    D:\home\site>touch applicationhost.xd
    D:\home\site>

    I'll update this topic as I progress.

    Thanks, Mark.


    Mark

    Sunday, February 1, 2015 3:37 AM
  • Oh, in the meantime I finished the steps! Can you see if the site is good now?
    Sunday, February 1, 2015 3:40 AM
  • Hi David

    When I went to edit the file it already contained exactly what you gave above.

    Am I correct in assuming you've already gone ahead and done the work for me? Or is it just coincidental?

    I'll wait to hear back from you just in case I stuff up what you're doing.

    Thanks, Mark.


    Mark

    Sunday, February 1, 2015 3:46 AM
  • Right, I had done that. It should be all set now, at least for ApplicationData.svc. Please test if the site is working correctly now.
    Sunday, February 1, 2015 3:50 AM
  • Hi David

    The site still seems to be down.

    The top screen-shot is of the opening SL client screen and below that the HTML client.

    Thanks, Mark,


    Mark

    Sunday, February 1, 2015 3:57 AM
  • Hi David

    See bellow my attempt to verify that ApplicationData.svc is the correct file.

    How can I confirm this? Thanks, Mark.


    Mark

    Sunday, February 1, 2015 4:07 AM
  • Yes, it's the correct file, and you also have another svc (Microsoft.LightSwitch.SecurityData.svc), that I added to the xdt file. I verified that without the xdt, these APIs are broken with the exact error that started this thread, while with it the APIs are working fine. So as far as this specific issue goes, it appears to be addressed by the workaround.

    That being said, it's possible that there are additional issues at stake. What specific URLs are not working? I don't mean at the UI level, but the underlying requests that are causing the UI to fail.

    Sunday, February 1, 2015 4:16 AM
  • Hi David

    I made best efforts to try to identify the URLs but honestly I'm just shooting in the dark. I just don't have the knowledge to know where to start looking.

    Please give me some pointers and I'll try to find what you need.

    I'm also quite happy to send you my entire project and credentials if that's the quickest way to sort this out.

    Thanks again. I'm really sweating it out at this end.

    Best, Mark.


    Mark

    Sunday, February 1, 2015 4:27 AM
  • Hi Mark,

    Are there developers that can help out with the investigation?

    This thread was specifically about users getting errors that look like "http://site.azurewebsites.net//ApplicationData.svc/etc is not valid because it is not based on http://site.azurewebsites.net/ApplicationData.svc/". Are these in fact the errors that you were getting earlier?

    The workaround only targets this issue, and as far as I can tell it no longer occurs on your site.

    It is hard to investigate other issues without more knowledge about the code.

    As a test, can you try deploying the same bit in some other region, to see if that fixes it? I don't mean for production, but just as a test to compare behavior.

    Sunday, February 1, 2015 4:38 AM
  • Hi David

    I hope you intend to stay with me until the sites up or if you hand-off to someone else when you need to.

    As I mentioned I'm between a rock and a hard place with this issue.

    Customers don't want to know what I'm doing they just want to be back up again.

    I've been buying time as best I can but won't be a able to keep it up much longer. And I haven't even told them that I've blown away a weeks data when I resorted to my www.getcloudcellar.com backup :-/

    Thanks for your assistance. It's greatly appreciated.

    Regards, Mark.


    Mark

    Sunday, February 1, 2015 4:42 AM
  • Hi David

    I don't have a developer that can help.

    Although you may have fixed something, up to now the site that has been up live in production since April last year and nothing in my 'small' recent change could have caused this issue. I've also tried publishing from backup versions that worked 100% to no avail.

    Would moving to another region or publishing from scratch help. But then if I published from scratch I'd have to be able to recover the database or almost a year's data will be lost not to say the time taken to re-establish customers' project data would make it impossible.

    Please give me a path I can take. I assure you that there's nothing that I broke at my end. This just happened 'out of the blue'!

    Thanks, Mark.


    Mark

    Sunday, February 1, 2015 4:51 AM
  • Hi David

    What can you suggest please.

    It seems the 'partial upgrade' has caused my problem. Others also mention the 'error code 400' that I saw originally.

    Should I attempt to republish?

    Please advise. Thanks, Mark.


    Mark

    Sunday, February 1, 2015 5:09 AM
  • Yes, to repeat my previous suggestion in case you missed it: As a test, can you try deploying the same bit in some other region, to see if that fixes it? I don't mean for production, but just as a test to compare behavior.
    Sunday, February 1, 2015 5:10 AM
  • I need to be off soon, but I've asked others to help out.

    Note that the general fix to address the issue that caused the error that started this thread is actively being worked on, though the exact deployment time is still not known.

    Apologies for the downtime. We always try to avoid this kind of situations, but unfortunately in some rare cases a new deployment causes an unexpected issue.

    David

    Sunday, February 1, 2015 5:18 AM
  • Hi David

    Thanks for helping so far.

    I'll stay tuned and update this thread if anything of interest happens at my end.

    Regards, Mark.


    Mark

    Sunday, February 1, 2015 5:23 AM
  • Hi Chris

    You'll notice below that David Ebbo has assisted in trying to get my site up and applied a work-around but it hasn't fixed my issue.

    He's had to leave the office so I'm trying everything I can think of to get my site back up.

    You can read the details in my discussion with him further down in this topic.

    I'm just stabbing in the dark but my HTML client gives this error "Request failed with status code '400' and status text 'Bad Request'" and in the forum I find that someone also experienced the issue at this topic:

    https://social.msdn.microsoft.com/Forums/vstudio/en-US/facf88ab-497a-432d-8c42-1caa0d3cdc0c/lightswitch-html-client-request-failed-with-status-code-400?forum=lightswitch

    A proposed solution on the thread is:
    "In my case after upgrading the project to the March 2004 Lightswitch format and getting this error I had to install this nuget package to make it work on the server:
    https://www.nuget.org/packages/System.IdentityModel.Tokens.Jwt/"

    Should I go down this path or is it a red herring?

    Thanks, Mark.
    PS: My SL client gives this error on loading the first screen:
    "An error occurred while running the screen. Error details: Exception has been thrown by the target of an invocation."


    Mark

    Woo Hoo. I went to Cloud Cellar and recovered files only from my backup and now my HTML client works :-)

    My SL client gets all the way past loading nearly all the initial screen data then comes up with this error:

    "The metadata URI 'http://login.skemaz.net/ApplicationData.svc/$metadata#Chains' references the entity type with name 'LightSwitchApplication.Chain'; however, the name of the expected entity type is 'LightSwitchApplication.ChainsTemp' which is not compatible with the entity type with name 'LightSwitchApplication.Chain'."

    We seem to be getting somewhere.

    Please assist with the above. Thanks, Mark.

    • Edited by ITPSB Sunday, February 1, 2015 5:59 AM
    Sunday, February 1, 2015 5:45 AM
  • Hi Mark,

    Good news: we have applied a fix (different from the workaround above), and I think your site should be completely fixed now.

    Could you please verify and let me know?

    thanks,
    David

    Sunday, February 1, 2015 5:56 AM
  • Hi Dave

    As reported above, my HTML client now works :-)

    My SL client loads Ok but right at the end of loading (or refreshing the screen) I get the following error:

    "The metadata URI 'http://login.skemaz.net/ApplicationData.svc/$metadata#Chains' references the entity type with name 'LightSwitchApplication.Chain'; however, the name of the expected entity type is 'LightSwitchApplication.ChainsTemp' which is not compatible with the entity type with name 'LightSwitchApplication.Chain'."

    Here's a screen-shot:


    Mark

    Sunday, February 1, 2015 6:12 AM
  • Hi

    FYI. I do indeed have two tables one named "Chain" and another named "ChainsTemp" (LightSwitch "pluralises" names automatically).

    The ChainsTemp table is used for importing .csv data that I populate into the Chain table.

    So although both tables are in the Model View, only the Chain table is visible. The ChainTemp table is only visible when the user imports data.

    Hope that helps.

    Many many thanks, Mark.


    Mark

    Sunday, February 1, 2015 6:17 AM
  • Hi David

    I noticed that you created a test Skemaz account.

    Many thanks for checking out my site so thoroughly.

    You should be able to replicate my final issue with the LS client by going to the "Designer" app in Skemaz (the "Auditor" app is the HTML client).

    When the Designer app loads and detects that you are a new user, you are given the option to create test data. Please do this and when the data has loaded you should see the error that I mentioned above.

    Once again many thanks for saving my bacon!

    Best regards, Mark.


    Mark

    Sunday, February 1, 2015 7:16 AM
  • Hi David,

    we are still facing the same problem with our website on production(!?), and we are not sure what to do now? Is the fix applied only to Mark's environment or is it a general fix?

    Thanks,

    Tom

    Sunday, February 1, 2015 8:49 AM
  • Tom,

    The fix for Mark was applied to one specific cluster. It may be possible to apply it to yours as well if we have your site name.

    However, after further tweaks, I think you'll find that the workaround I gave above will completely fix your site. Search for applicationhost.xdt in this thread. It will take you 5 minutes to do this, while the cluster patch is a bigger process, so please do try this first.

    Note that the complete real fix is still upcoming and will be global.

    David

    • Proposed as answer by MajorT Sunday, February 1, 2015 2:26 PM
    • Marked as answer by Angie Xu Monday, February 9, 2015 1:41 AM
    Sunday, February 1, 2015 1:41 PM
  • Mark,

    I think I know what the problem was with that last error. The xdt file had a small issue, which I since corrected above. But in any case, since your cluster was fixed, you no longer need the xdt (I removed it). I was able to add and save data in your site without errors.

    David

    Sunday, February 1, 2015 1:43 PM
  • Hi David,

    thank you for the response, the workarround worked for me.

    Tom

    Sunday, February 1, 2015 2:28 PM
  • The temporary correction suggested by David worked also for me, even with web sites hosted in Brazil.

    David, so this file can be removed from Web sites hosted in Brazil will be informed in this thread?

    Victor Perez

    Sunday, February 1, 2015 7:32 PM
  • Same issue here just discovered with a production website running in Western Europe.

    The suggested fix above fixed it for us too, but I convinced the business owners late last year to move the application from a private VM to Azure for greater stability and this is not a good look unfortunately.

    Thanks for posting the work-around though and please post back to this thread when the MS patch has been applied and we can remove the *.xdt file.


    Regards, Xander. My Blog

    Sunday, February 1, 2015 8:34 PM
  • Glad the workaround is getting everyone's sites back up.

    In spite of that, we understand that this has caused some real downtime for some of you, and it was a failure on our part. Basically, we had a test hole relating to Lightswitch apps, causing us to miss a regression in our latest deployment. We will of of course add better coverage for this scenario going forward.

    David

    Sunday, February 1, 2015 9:07 PM
  • Hi David,

    We've had the same issue, however the workaround has worked, getting our production sites back up and running.  A bit of a heart starter for a Monday morning!

    Will you let us know when the patch rolls out and we can remove the temporary file?

    Cheers,

    David A.

    Monday, February 2, 2015 12:07 AM
  • Hi David

    Many thanks indeed.

    My site is up and running.

    All the best, Mark.


    Mark

    Monday, February 2, 2015 2:40 AM
  • If I may make a recommendation. Purchase the $39 developer support package or whatever support package is available to you.

    If the problem is Microsoft's, you can ask for a refund.

    When I ran into the problem on Friday afternoon, I purchased a support package at midnight and MS support had me back up and running by noon the next day.

    In my case, they moved my customers subscription to a server that had not had the update that caused the issue with LightSwitch applied .

    I can tell you that support is fantastic! The people I worked with were very professional and the problem was escalated and resolved in a timely fashion. My only regret was not going the support route earlier.




    • Edited by Ian E Monday, February 2, 2015 5:58 AM
    Monday, February 2, 2015 5:54 AM
  • Hi David

    I tested earlier and the final issue where the below error appeared seemed to have been resolved.

    Logging in later I see it's back.

    Please assist.

    Thanks again, Mark.

    "The metadata URI 'http://login.skemaz.net/ApplicationData.svc/$metadata#Chains' references the entity type with name 'LightSwitchApplication.Chain'; however, the name of the expected entity type is 'LightSwitchApplication.ChainsTemp' which is not compatible with the entity type with name 'LightSwitchApplication.Chain'."


    Mark

    Monday, February 2, 2015 7:25 AM
  • Hi David

    I tried again. And now the last fix is working again.

    I'll update this thread if it crops up again.

    Thanks again, Mark.


    Mark

    Monday, February 2, 2015 7:51 AM
  • Hi David

    Ok, so the problem has gone and come back a few times.

    At the moment it's come back again.

    Please assist.

    Thanks, Mark.


    Mark

    Monday, February 2, 2015 10:07 AM
  • Mark, I looked on your site and the bad xdt file had come back (bad because it was an earlier version with an issue). Do you know what caused it to come back? Note that your cluster has been fixed, so in your case, you do not need any xdt file. I just deleted it.
    Monday, February 2, 2015 2:53 PM
  • Glad the fix is working for everyone. To answer your question: yes, I will notify you on this thread when the issue has been fully addressed, at which point you can remove the xdt file.
    Monday, February 2, 2015 2:57 PM
  • I am relieved I found this thread, I have had a terrible day trying to get to the bottom of this Lightswitch/Azure DB problem. I too have been getting the '400 Bad Request' error and also the 'uri is not valid because it is not based on....'. The randomness of the error has been giving me headaches - I swapped routers, browsers, rescaling db's, websites, allsorts. I was about to begin rebuilding my whole LS project as I thought it had corrupted.

    Anyhow, I have applied the xdt file, so will see how this goes. My business hinges on this project.... what a day.

    Monday, February 2, 2015 6:52 PM
  • Hi David

    I just checked and the error has gone again.

    The only thing that may have possibly restored the file is my publishing to staging and switching staging and production. But that's just a guess and may be completely wrong.

    During the course of today (West Australia time) I'll switch a couple of times to experiment with the above possible idea but if I'm off at a tangent please let me know and I won't waste time on it.

    Thanks again for all your assistance without which I would have been seriously up the creek without a paddle.

    Best regards, Mark.


    Mark

    Tuesday, February 3, 2015 1:32 AM
  • I have the XDT file loaded and all has been well. Until now......

    I have started getting the same 400 Bad Request errors and 'The URI is... not valid because it is not based on ...'

    Tuesday, February 3, 2015 3:46 PM
  • @Graham: that is strange. What is your site name? If you don't want to share it publicly, you can email it to me (david.ebbo (AT) microsoft.com).
    Tuesday, February 3, 2015 6:08 PM
  • It should be a crime that you have to pay to get support for something that Microsoft screwed up.  Even with the prospect of a refund. 
    Tuesday, February 3, 2015 8:39 PM
  • @KeystoneAdam: you don't have to pay for support, as you can see from this thread.
    Tuesday, February 3, 2015 8:44 PM
  • Hi KeystoneAdam

    No one likes it when the proverbial brown stuff hits the fan but its what the supplier does after the event that's critical.

    All too often they go into denial mode, cover-up mode, become defensive or even try to blame the victim.

    In this case (BTW I didn't need to pay a dime), I have to give the MS team 10 out of 10 and 2 for neatness.

    The one-on-one attention that I received from David Ebbo was exceptional!

    I don't know what hours he had to work to keep us all up to date with the fix status plus individually patching up mine and other web sites, but I'd suggest he pulled a long one.

    Sure it was a huge stuff-up but I for one am impressed with their excellent response to my dire situation.

    I won't be looking for any refund - in fact I've received my money's worth and am delighted by their response.

    In closing, we all stuff-up at some point and it's easy to throw stones at the big guy (in Australia we call it the 'tall poppy' syndrome where people love to cut others down to their level).

    Bottom line is that they performed an excellent recovery job from a pretty dismal position.

    Regards, Mark.


    Mark

    Wednesday, February 4, 2015 4:13 AM
  • I am having the same issue (400 error and initial post). I did the work around to no avail.

    Scott

    Wednesday, February 4, 2015 6:10 AM
  • Scott, perhaps a silly and obvious question, but did you restart the website after you created the *.xdt file?

    Regards, Xander. My Blog

    Wednesday, February 4, 2015 6:12 AM
  • um, duh, no.  But this morning when I checked it, it was working?  Did the global fix go out or did my site just restart on it's own?

    Wednesday, February 4, 2015 3:42 PM
  • @Mark: thanks for the good words. Glad I was able to help!

    @Scott: the deployment is making its way through the various regions, so it's entirely possible that it reached you. It's not quite complete globally but will be later today. I'll follow up when it's done.

    Wednesday, February 4, 2015 4:07 PM
  • The real fix is now globally deployed, so you can remove the xdt file at your convenience. After doing this, make sure to restart your site to actually make the xdt non-effective.

    It was actually all deployed a day or two ago, but I forgot to follow up here.

    Anyway, apologies for having this issue in Azure Websites in the first place. We've learned from it and have improved our test coverage.

    David


    • Edited by David Ebbo Friday, February 6, 2015 5:01 PM typo
    Friday, February 6, 2015 2:06 PM
  • I'm assuming you meant to say "is now globally deployed"?
    Friday, February 6, 2015 4:10 PM
  • Ah yes, indeed. Corrected, thanks!
    Friday, February 6, 2015 5:01 PM