• SharePoint apps (add-ins) JavaScript disappeared

    At Negotium we recently came across a weird problem.

    Let’s assume you previously built a Provider hosted app for SharePoint.

    Now let’s assume you updated to the latest version of the SDK (April/May update)

    Finally let’s assume your tenant has been updated recently (v16.0.4121.1212 or above)

    It’s likely that you are loading SP.*.js files and MicrosoftAjax.js the way it used to be recommended by Microsoft per say: <HostWebUrl>/_layouts/15/jsfile.js or <AppWebUrl>/_layouts/15/jsfile.js.

    However MicrosoftAjax.js has been deprecated for several years now (replaced by EcmaScript 5 new features and jqueryval)

    One effect of this tenant update is that is deletes MicrosoftAjax.js

    Another thing I noticed is that the lastest sdk update (16.1.3912.1204) brings along SP.*.js files as we can see in the JavaScript folder of the nugget package.

    It seems that Microsoft reviewed it’s strategy and now recommends to embed JS files within your application.

    So I created a sharepoint folder in my scripts folder and added the following bundle

    bundles.Add(new ScriptBundle("~/bundles/sharepoint").Include(



    But one file i sis missing in the nugget package SP.UI.Dialog.js (which allows you to display notification bars and toasts) and that file still depend on MicrosoftAjax.js( because of Type.RegisterNamespace…)

    I really think it’s only a matter of time before we have an update for the nugget package including a new version of SP.UI.Dialog.js, but in the meantime I had to copy MicrosoftAjax.js and SP.UI.Dialog.js from an old tenant (or on prem farm) and add it to my web application.

    Let’s hope this post saves you time and will allow you to update your applications before you hit the problem.

    • 9/6/2015
  • Azure – Bug with azure web sites settings

    Hi everybody,

    For those who didn’t know it already, you can set the “appSettings” settings of your web application from the azure portal.

    This technique has several advantages over the traditional xsl transformation:

    • Only the admin knows the settings, they are not on the source control

    • Rich UI experience

    • Settings can be “slot relative” (checkbox on the right), this allows you to have something like “this setting has this value in staging and that value in production which have to remain with each slot, even if I swap the deployments”

    I recnetly found a bug with that tool. Let’s say we define only appSettings keys in the web.config file because values are going to be set by the configuration service anyway.

    Of course you didn’t forget to set keys/values in the slot settings.

    However, if you explore your files with kudu after deploying ( ) and if you edit the “transformed” web.config you will see that values have not been set.

    To solve this issue only add value=”” in your source web.config.

    Let’s hope that post has spared some of you from wasting your time.

    • 2/6/2015