locked
How to Debug/Test a Store app using a non-production Azure Mobile Services endpoint? RRS feed

  • Question

  • I'm trying to test changes to my Store app that utilizes Azure Mobile Services. To test, I've got point my app to a dev AMS endpoint, because the AMS interface has breaking changes. So I can't use the current production endpoint.

    I've set up a Test AMS endpoint and changed the address and key for that endpoint so they match what Azure has:

            // ***** TEST ******
            public static MobileServiceClient MobileService = new MobileServiceClient(
                "https://myapp-test.azure-mobile.net/",
                "myAzureMobileServicesTestkey"
            );

    I've also changed the address for the LiveAuthClient as well to match:

                        //authClient = new LiveAuthClient("https://myapp-prod.azure-mobile.net/");
                        authClient = new LiveAuthClient("https://myapp-test.azure-mobile.net/");

    But when I try running, I get an exception saying the following:

    "The app is not configured correctly to use Live Connect services. To configure your app, please follow the instructions on http://go.microsoft.com/fwlink/?LinkId=220871."

    This exception occurs right here:

    MobileServiceUser loginResult = await App.MobileService.LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount, token);

    How do I debug using a Test AMS endpoint? Do I need to change the identity values in my app's manifest just to hit a different AMS endpoint? If so, doesn't that mean I would have to create a new Store app to get a different app identity? That would seem odd. Am I missing an easier way to test breaking changes without hitting my production Azure Mobile Services endpoint? Thanks.

    Thursday, February 6, 2014 3:12 PM

Answers

All replies

  • Update: I have followed the link given in the error message. I've added a "new" app to the Live Connect Developer Center site, and included a redirect domain to match my Test Azure mobile service URL (i.e. https://myapp-test.azure-mobile.net/).

    This doesn't seem to make a difference, however. I did notice one thing different in the API Settings view on the Live Connect Dev center. My production app listed there shows a Package SID. My test app entry does not. But I don't recall how to associate a package SID with my test app.

    I hope there is another way to do this, as it seems awfully complicated to simply test an app against non-production data source.

    Thursday, February 6, 2014 6:35 PM
  • Hi Tim,

    It seems like you over complicating your testing.  If it is non-production then simply remove the authentication on the tables and you not have to worry about this.  There is a 1:1 association of your app to login for Windows Store apps.  That is why you are running into issues.

    Jeff


    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    • Marked as answer by Tim SF Friday, February 7, 2014 2:37 PM
    Friday, February 7, 2014 1:38 PM
    Moderator
  • Thanks, Jeff. I was over complicating things. I was able to remove authentication from the tables and access data. But this does bring up a question. Is there a way to pass in a fake value as the UserId during testing in this scenario so that I can still run the scripts on my updates/deletes? As it is, the user.userId value is undefined.

    Friday, February 7, 2014 2:35 PM
  • Never mind. I think I'm still over complicating. I'll just modify my CRUD scripts and include the literal userId value in there to during testing.
    Friday, February 7, 2014 2:39 PM
  • Hi Tim,

    UserId comes from the authentication system so not directly, no...  You could come up with some sort of scheme by passing parameters but again, it may be a bit more complicated than you want to implement.  You could hard code this but if you are using userid in your logic, that will not help you much.

    As an alternative you could unit test your logic if your code is logically separated into classes and plug it into your testing app...  Know what I mean?  That way you would have separate identities all in that test environment and you could plug in your code to test functionality before release.

    Jeff


    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Friday, February 7, 2014 2:41 PM
    Moderator
  • Sometimes just talking about it helps... Code Psychiatrist Jeff Here :-)

    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Friday, February 7, 2014 2:42 PM
    Moderator