The most important step in these instructions is:

On the Settings tab (of the publish wizard), make sure Enable Organizational Authentication is NOT selected. Click Publish.

That got rid of my Authorization problem, as checking it (which it was by default for this project) caused the web.config to have the ida:Audience setting messed up.

Hopefully this article saves you some time if you run into this.  Onto the next Azure AD challenge...

Luckily it's very easy to format the output using the PowerShell Format cmdlets.  Simply adding 

| Format-Table -AutoSize

to the end of the command will fix the formatting:

That's it, hope it helps.

And, you probably also know, that this setting does nothing in the deployed app...

Well, the good news is, the settings "wants to" work, it's just getting trumped by a competing force.  I won't get into the details, I will just show how it can be fixed.

Ready?  It's pretty involved....

Open the web.config file in the Server project.  Find and remove this chunk and save the file:

I have logged a bug for this and it should be fixed in a future release.

Login to the Azure Management Portal, either create a new or navigate to an existing Web Site.  Go to the Configure tab scroll to the bottom and create "Applications" for all your CBAs.

Once you have entered the values, hit Save and you will be set with Applications.  Navigate to "Dashboard" and click "Download the publish profile"

Now open your CBA in Visual Studio.  The app is published as you would normally publish a provider-hosted CBA, with a few exceptions:

The application must use the IIS path of the publish wizard where you will import the publish settings file you exported in the previous step.

On the "Publish Settings" page add the application name.

On the "SharePoint Client ID" page, the URL needs to be completely changed to the full URL of the web application that was defined in the Azure Portal.

That is it for what is different.  Deploying the SharePoint app package isn't any different than a "normal" CBA deployment. 

So the key takeaways are:

• Create Application directories in the Azure Portal for each of your apps
• Use the IIS path of the publish wizard instead of the Azure path
• Update the appropriate URLs in the publish wizard to include the app name

Prerequisite:  Make sure that you are viewing “File name extensions” through Windows Explorer (I’m logging a bug against Windows, for crying out loud there are a billion file extensions today).

Hit Windows Key + D to show the desktop.

Right-click on the desktop and choose to create a new text document

Rename the file to something that ends with the file extension UDL (this is the important part)

After which, it should look like this:

Double-click the file, which should open this window:

There you go, you have this window which should be familiar.  Enter the Server name, choose NT Integrated security if your server is using Windows logins or fill in the user name and password if it’s using SQL auth and optionally select a database then hit Test Connection at the bottom.

Last week I started working on an idea that I have for a Mobile Service/Mobile App.  I am working with the newly introduced .NET Backend for Azure Mobile Services.  I started implementing the service and a Windows Phone client app for it and ran into a roadblock with debugging.  Here are the configurations I could debug:

• The locally running Mobile Service via browser (i.e. what launches when you F5 the project)
• My connected Windows Phone device (i.e. my phone is plugged in and when I F5 the app launches on the phone) hitting the published Mobile Service in Azure

Here’s what I couldn’t do:

• Have my phone hit the locally running Mobile Service client.

When I tried to do this here’s what I got:

Microsoft.WindowsAzure.MobileServices.MobileServiceInvalidOperationException: The request could not be completed.  (Unauthorized)

Now I will admit that when I started implementing my service, I didn’t read far enough on the Get started with data in Mobile Services topic to get to the section titled “Test the Windows Phone app with the service hosted locally” to find out that I needed to update my applicationhost.config file and create a firewall rule so that the phone app could hit my IIS Express, but the Unauthorized error I was getting after I fixed that up.  Scratching my head a bit about this error I remembered earlier in my experience that I got prompted for credentials when I tried to hit my Azure-published mobile service directly through the browser.  I found out that if you enter your application key as the password on this prompt, you will pass the authentication.  So that got me wondering about if I needed to add the Mobile Service’s application key when I new’d up my MobileServiceClient from the phone app.  I tried that, which by itself didn’t work.  After I thought “well that’s not going to work because my locally deployed service doesn’t know anything about that key, it’s an Azure setting.  And besides, the service works fine when I hit it through the browser that launches from VS when I F5”.

Well, I was more or less on the right track.  After much web searching I finally came across a forum post with the answer:

You need to specify the application key of the service in the Web.config file:

<add key="MS_ApplicationKey" value="Overriden by portal settings" />

If you run the service within Visual Studio, you don't need these values, and every request will pass. When you deploy the service on Azure, these values are overriden with the correct values. But, if you deploy the Mobile Service on your local IIS, you need to manually set them, and be sure that they match the values you enter in the client.

After changing the MS_ApplicationKey value in the web.config and also updating my phone client app to specify the application key in the MobileServiceClient constructor, I was able to hit the service from the phone!

Huge thanks to @marcominerva for posting the answer in the forum post.  I will definitely be logging a bug to get the boilerplate code generated for a Mobile Service to include the application key in both places that I needed to add it.

To start, here’s a brief summary of the issues I ran into:

• There was no entry in the “Add” context menu for “TypeScript File” when right-clicking on the HTMLClient project (i.e. the .jsproj)
• There was no entry for “TypeScript File” in the “Add New Item” dialog
• When I added a new JavaScript file and renamed it to end with a .ts extension, I couldn’t get the .ts file to compile and generate the corresponding .js file (I tried a variety of different things here that I won’t get into)

I did find an open bug that was something along the lines of “TypeScript should work with JavaScript projects (.jsproj)” so hopefully these will all be addressed in the near future.

Here is what I needed to do to get things to work:

Close VS

Find the .jsproj file in the HTML sub-project’s folder and open it with Notepad

Insert the bolded entries just below the first PropertyGroup node near the top of the file:

<PropertyGroup Condition=" '$(Configuration)' != 'Release' ">
  < UseDesignTimeFeatures>true</UseDesignTimeFeatures>
< /PropertyGroup>
<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
  < TypeScriptTarget>ES5</TypeScriptTarget>
  < TypeScriptRemoveComments>false</TypeScriptRemoveComments>
  < TypeScriptSourceMap>true</TypeScriptSourceMap>
  < TypeScriptModuleKind>AMD</TypeScriptModuleKind>
< /PropertyGroup>
< PropertyGroup Condition="'$(Configuration)' == 'Release'">
  < TypeScriptTarget>ES5</TypeScriptTarget>
  < TypeScriptRemoveComments>true</TypeScriptRemoveComments>
  < TypeScriptSourceMap>false</TypeScriptSourceMap>
  < TypeScriptModuleKind>AMD</TypeScriptModuleKind>
< /PropertyGroup>
< Import Project="C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\TypeScript\Microsoft.TypeScript.targets" />
< Import Project="C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\TypeScript\Microsoft.TypeScript.jsproj.targets" />
<PropertyGroup Label="Globals">

I stole this snippet from a new TypeScript project that I had created and after some spelunking online found various sources that said that these are the meaningful parts regarding JavaScript generation (I changed the Import nodes to use absolute paths instead of environment variables because it didn’t work with the environment variables on some machines).  Note that you need to remove all the leading spaces in front most of the elements (LiveWriter insists on adding these during the publish process, sorry).

Open your LightSwitch project in VS and choose to add a new JavaScript file to the HTMLClient project

Change the name of the file to end with .ts instead of .js

Paste this code into the file that was just created (this is taken from Michael’s blog post)

class FormatName {
    _firstname: string;
    _lastname: string;
    _age: number;
    constructor(
        firstname: string,
        lastname: string,
        age: number
        ) {
        this._firstname = firstname;
        this._lastname = lastname;
        this._age = age;
    }
    ReturnName() {
        var formatedName =
            this._lastname.toUpperCase()
            + ", " +
            this._firstname.toLowerCase()
            + " {" + this._age.toString() + "}";
        
         return formatedName
       }
}

Then save the file.  Now what should have happened is that a .js file was generated and added to the .jsproj.  The .js file is created, but it isn’t added to the project

So, we need to manually add this to the project by performing Add >> Existing Item and selecting the .js file from the browse window that opens

Now the .js file will be copied out to the Scripts folder when you do a build.  Finally, you will need to add an entry in the HTMLClient project’s default.htm to include this new file

<script type="text/javascript" src="Scripts/Generated/generatedAssets.js"></script>
<script src="scripts/formatname.js"></script>
<script type="text/javascript">

After all this, we now have generated JavaScript that we can call from the JavaScript files that are generated when you “Add Code” to a screen.  Here’s an example (again taken from Michael’s blog).  This example is for the “postRender” code for a List (notice the lines using FormatName and ReturnName).

myapp.BrowsePeople.rows_render = function (element, contentItem) {
    // Write code here.
    var itemTemplate = $("<div></div>");
    var FirstName = contentItem.data["FirstName"];
    var LastName = contentItem.data["LastName"];
    var Age = contentItem.data["Age"];
    var objFomatName = new FormatName(FirstName, LastName, Age);
    var FinalName = $("<h1>" + objFomatName.ReturnName() + "</h1>");
    FinalName.appendTo($(itemTemplate));
    itemTemplate.appendTo($(element));
};

So that is something, not much, but something.  We got some good feedback on the forums about ways we could improve the experience for supporting TypeScript from a LightSwitch project.  Hopefully we can deliver on some improvements in the future.

A sample project for the sample described here can be found at https://code.msdn.microsoft.com/Using-TypeScript-with-c418131a

Error    1    Web deployment task failed. (Modifying application pool properties is not supported by this server environment.
  Learn more at: https://go.microsoft.com/fwlink/?LinkId=221672#ERROR_NOT_SUPPORTED.)    C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets

This is being caused by a recent change to Azure Web Sites infrastructure that no longer allows certain properties to be changed through Web Deploy.  LightSwitch publish attempts to change the .NET Framework version of the application pool to v4.0 and the pipeline to Integrated.  The above error occurs even if the web site’s application pool was already configured with these values (i.e. we wouldn’t actually be changing anything).  We are investigating if this particular case can be addressed through the Azure Web Sites infrastructure.  In the meantime, this issue can be worked around by doing the following:

In the Server Explorer, expand Windows Azure >> Web Sites (you may need to enter your Azure credentials at this point).  Right-click on the Azure Web Site that you are attempting to publish to and select “View Settings”

Find the “Application Settings” section at the bottom of the designer that opens and click the “Add” button

Set the “Key” to WEBSITE_WEBDEPLOY_USE_SCM and the “Value to false

Click on the “Save” button at the top of the designer

Wait for this to complete, then use the LightSwitch publish wizard and re-publish.  The app should deploy properly now.  I will update this post when I know more about when this workaround will no longer be needed.

In response to this I have been messing around with things this afternoon and I think I have come up with a set of steps to get users out of this mess.  The way that I can repro getting into this situation is if I have published my project successfully to Azure (at some point) and then I remove the Azure Management Certificate from my Personal Certificate Store:

And have removed the subscription from the list of subscriptions that VS is keeping track of:

In this case, if I launch the Publish Wizard we will see that there is no Subscription entry that matches what we are tracking in the lsxproj and lsxproj.user and we create one, this one still won’t work, however, because we still don’t have the backing certificate (here’s what this entry looks like)

Now there are likely other ways to get into the situation, but this is how I got into it.  Here is how I can get out:

1. In "Server Explorer", right-click on "Windows Azure" and select Manage Subscriptions

2. In the "Manage Windows Azure Subscriptions" window, use the Delete button to remove all stored subscriptions.  Then Close the window.

3. In the Server Explorer, Right-click on "Windows Azure" and this time select Import Subscriptions

4. First, Download subscription file, (you may need to enter your Azure credentials at this time).  Browse to the location that you saved the file, then hit Import

Now attempt to launch the LightSwitch publish wizard again.  What should have happened is that a new Subscription Entry was created (for VS) and the certificate was re-imported into the Personal Certificate Store.

This worked for me, I hope it works for you as well.

If you are like me, you will end up having a lot of windows open at a certain point of your project development and end up “declaring window bankruptcy” and doing something like right-clicking on a document tab and choosing Close All But This or Close All Documents:

If you do this and you want to get back to the “Start with data” screen, you simply need to go View >> Home Page

…and you will get back to it.  I realize Tables can be added and Data Sources attached by right-clicking on Data Sources under the Server project in the Solution Explorer….

…but sometimes, there’s no place like home.