AngularJS Unknown provider: $modalProvider

Unknown provider: $modalProvider <- $modal

The obvious answer for the unknown provider error is either the missing dependency when declaring a module as in the case of adding ui-bootstrap or just the incorrect name. After we make sure that the provider name and dependency is included, we may still get the error. We start to think that we had done this exactly the same way in a previous project, and it works OK.  The one thing we need to account for is the breaking changes when upgrading to a new release of the js libraries. 

 Let’s take a look at how we use the $modal provider in one of our modules:

var app = angular.module('app', ['ui.router', 'ngRoute', 'ui.bootstrap']); app.factory("$svcMessage", ['$modal', svcMessage]);

Yes, the code above should work and not raise the provider error, but when we start a new project, this error shows up. Why?

To figure this out, we should take a look at our current versions of ui-bootstrap and see if this provider still exists. Yes, we see that the modal provider now is defined as:

.provider('$uibModal', function() {         var $modalProvider = {             options: {                 animation: true,                 backdrop: true, //can also be false or 'static'                 keyboard: true             },

OK, so during one of the new releases, the provider was renamed. The advice here is that when we start a new project, we should take inventory on the versions of the js libraries and their dependencies. This is especially true when we have created core components for re-usability which may no longer work when upgrading to a new version.

In this case, the modal provider for the latest release of ui-boostrap should be as follows:

var app = angular.module('app', ['ui.router', 'ngRoute', 'ui.bootstrap']);    app.factory("$svcMessage", ['$uibModal', svcMessage]);

One more note, we also need to make sure that the version of ui-bootstrap we are using supports our version of angularjs. If this is not the case, we may get other errors like unknown  $templateProvider which is common when using a recent ui-bootstrap version with an older angularjs version.

As of the time of this writing, the current requirements are as follows:

Angular Requirements UI Bootstrap 1.0 and higher requires Angular 1.4.x or higher and it has been tested with Angular 1.4.8. UI Bootstrap 0.14.3 is the last version that supports Angular 1.3.x. UI Bootstrap 0.12.0 is the last version that supports Angular 1.2.x. For latest changes, visit:  https://github.com/angular-ui/bootstrap

Hope it helps

Unknown provider: $modalProvider <- $modal  The obvious answer for the unknown provider error is either the missing de...

Read Article →

Visual Studio 2015 Apache Cordova Android Build Hangs up

When using Visual Studio 2015 to build an Android Apache Cordova mobile app, the build process does not stop after several minutes and there are no messages on the output window.

This is a sign that the Android SDK Build tools and or other dependencies may not be available on your development machine.  To figure out what is missing from a system, we can enable the MSBuild build output verbosity, or we can run a dependency checker on the Cordova tools.

MSBuild build output verbosity

Visual Studio MSBuild output is usually set in a minimal setting for which the MSBuild events displays are just a few mayor events. In order to view more detail information, we can set the output verbosity to diagnostics. This setting allows Visual Studio to display all the events on the output window which enable us to diagnose problems during the build.

To enable this setting, select the following menu options:

Tools->Options-> Project and Solutions -> MSBuild project build output verbosity drop-down (select Diagnostic). In case we want to build a project using the command line, we can use the following: MSBuild.exe MyProject.proj /t:rebuild /verbosity:diagnostic Reference: https://msdn.microsoft.com/en-us/library/ms164311.aspx

MSBuild Output Verbosity

We can now build the project again and look at more detail information as well as any errors on missing dependencies.

Dependency checker on the Cordova tools

Visual Studio also has the option to run a dependency checker on the Cordova Tools. This option allows us to see what can be missing from a development machine. To access this option, select the following menu options:

Tools->Options->Tools for Apache Cordova and Click on Run Dependency Checker

Dependency Checker

This should identify missing dependencies like SDK Build tools and other Android packages.

Install missing dependencies

The easy way to install/manage all Android related packages is by using the Android SDK manager. This application allows us to install the latest Android SDK packages and can be downloaded from this location:

Android SDK Manager reference: http://developer.android.com/tools/help/sdk-manager.html

Android SDK Manager

The MSBuild output or dependency checker should list the missing components. We can then look for those components and install them using the Android SDK Manager tool. Once the missing components are installed, we can re-start Visual Studio and build the project again.

If all the dependencies are correctly installed, an Android Build for Apache Cordova should now build OK.

When using Visual Studio 2015 to build an Android Apache Cordova mobile app, the build process does not stop after several m...

Read Article →

API OAuth Token Access-Control-Allow-Credentials header is empty

When implementing an Azure API App using MVC Web API with OAuth Bearer Token Authorization, we came across this error:

Response to preflight request doesn't pass access control check: Credentials flag is 'true', but the 'Access-Control-Allow-Credentials' header is ''. It must be 'true' to allow credentials. Origin 'http://domain.com' is therefore not allowed access.

This error is a result of an AJAX request to an Azure API App with Cross-origin resource sharing (CORS) support. We looked at the response headers and noticed that the 'Access-Control-Allow-Credentials header was actually blank which does not allow the browser to continue since it is a security policy. The code that makes the request is shown next:

$.ajax({                 type: 'POST',  async:true,                 url: 'https://someapp.azurewebsites.net/token',                 dataType: "json",                 contentType: 'application/x-www-form-urlencoded; charset=utf-8',                 xhrFields: {                     withCredentials: true                 },                 headers: {                     'Authorization': 'Basic ' + appInfo                                    },                              success: function (result) {                     var token = result.access_token;                     //…                                   },                 error: function (req, status, error) {                     if (typeof(req) != 'undefined') {                         var msg = status || req.responseJSON.error;                         //…                     }                                   }         });

The same code works OK when testing on the test environment (NO Azure). We can see how the headers for cross domain and credentials are included in the response headers. This confirms that outside of Azure, the CORS configuration in the application is correct.

Response Headers Access-Control-Allow-Headers Access-Control-Allow-Origin Access-Control-Allow-Credentials

In Azure, we need to configure the CORS settings on the Azure Management UI which overrides any application CORS settings. This configuration outside of our web API application causes this problem with the header.

Since we are using OAuth bearer token security, we pass the client information as a header, and we do not use any type of cookies for security. This means that we do not need to use the withCredentials AJAX parameter.

withCredentials Standard CORS requests do not send or set any cookies by default. In order to include cookies as part of the request, you need to set the XMLHttpRequest’s .withCredentials property to true. The server must also enable credentials by setting the Access-Control-Allow-Credentials response header to "true"

Once the withCredentials parameter is removed from the AJAX request, the Azure API App started to work properly. This is how the code looks now:

$.ajax({                 type: 'POST',  async:true,                 url: 'https://someapp.azurewebsites.net/token',                                 dataType: "json",                 contentType: 'application/x-www-form-urlencoded; charset=utf-8',                 //xhrFields: {                 //    withCredentials: true                 //},                 headers: {                     'Authorization': 'Basic ' + appInfo                                    },                              success: function (result) {                     var token = result.access_token;                     //…                                   },                 error: function (req, status, error) {                     if (typeof(req) != 'undefined') {                         var msg = status || req.responseJSON.error;                         //…                     }                                    }             });

The resolution is to configure the request in a way that matches the expected response header from the server. In this case, there was no need to exchange security over cookies since this is done using a token. This is the solution for this particular case, but there could be other root cause that manifest in a similar problem.  

When implementing an Azure API App using MVC Web API with OAuth Bearer Token Authorization, we came across this error: Respons...

Read Article →

404 Error axd HTTP Handler

This error is common when a previously working web app has been migrated to another server or a cloud hosted environment, and it is now showing the HTTP 404 (Not Found) error.  To figure out the root cause and solution, let’s take a look at how the web app was configured initially. We will then take a look at the solution.

HTTP Handlers Configuration

When we look at the web.config settings we can find this entry:

<system.web>                  <httpHandlers> <add verb="*" path="myhandler.axd"   type="MyHandler"/>     </httpHandlers> </system.web>

This setting indicates that there is an HTTP handler defined by the type MyHandler. It also tells IIS to allow all requests (verbs = GET, POST etc.) with the route myhandler.axd as this handler should manage the requests. This is important because this also works as a mime type setting, so there is no need to add a mime type for this file extension on IIS. It is important to notice that this setting only works for IIS 5, 6 and IIS7 Classic Mode.  

If we migrate the app to a hosting service that has IIS7 (*Note that you can even notice this problem running on IIS7 express if you upgrade Visual Studio), we can probably recreate the 404 error.

There are two solutions to this problem:

1. Use IIS7 Classic Mode
2. Update the Web.config for IIS7 Support

Use IIS7 Classic Mode

If access to IIS is available, we can just change application pool Managed Pipeline Mode property to Classic, and the handler should be invoked properly. This can also be done for IIS Express by looking at the project properties - Manage Pipeline Mode setting.

Updating Web.config for IIS7 Support

In the case of cloud hosting, we need to make the change in the web.config by adding a new configuration section for HTTP handlers (*Note: This is used for IIS7 and future version). Let’s take a look at how that should look:

<system.webServer>        <handlers>                       <add name="myhandler" verb="*" path="myhandler.axd" type="ozkary.MyHandler"   preCondition="integratedMode"/>       </handlers> </system.webServer>

This setting indicates that we have a handler that should manage the requests in integrated mode. This is how HTTP handlers are configured when running on IIS7.  If we deploy again and load the site, we should no longer see the 404 error.

We should notice that these settings can co-exist in the web.config, but only one will be loaded which is dependent on your IIS environment.  This approach can let us develop on previous version of IIS and target more recent version on our deployments.

This error is common when a previously working web app has been migrated to another server or a cloud hosted environment, and it is now sho...

Read Article →

Publish MVC Web App on Azure Virtual Directory

Azure Web Apps are deployed as a new website on the Azure cloud. For those who have control of the server, this is similar to adding a new website on an IIS server. What if we need to deploy another web app on Azure, but we do not want to create a new web site?  Well the answer is to create a virtual directory and deploy the web app there. Let’s take a look at how we can do that using the Azure management website.  

We start by looking at a Web App that is already deployed on Azure. We need to look at the settings as shown below:

Azure Web App Settings

The image above shows the Virtual application and directories settings. This is the area where we can add a virtual directory that we can later target or use for another deployment. Let’s add a virtual directory named Admin. We will use this for the administration module of the web app. We need to enter the virtual directory name, physical path under wwwroot and check that we want this as an application which we need if we want to allocate the web app to an app pool. We can now save the changes, and the result should look as follows:

Admin Virtual Directory

We are now ready to show how to deploy this. Let's go over Visual Studio, open the solution and take a look at the publishing profile for the original app. Notice the Site Name and Destination URL settings.

Publish Profile Settings

Since we are now deploying to the same web app site and URL, we just need to append the virtual directory information (/Admin) as shown below:

Publish Profile - Virtual Directory

We can now just press the publish button, and we have one Azure web app instance hosting two web apps with one at the wwwroot and the other on the virtual directory off of wwwroot.

I hope this tip provides some insight for your web app deployment strategies on Azure.

Azure Web Apps are deployed as a new website on the Azure cloud. For those who have control of the server, this is similar to adding a new w...

Read Article →

SharePoint App List Lookup Delete Behavior

A SharePoint list can have a field type lookup which is a reference to another list. As an example, we have a client and project lists. The project list has a client lookup field which as reference uses the client list. As in any application, we need referential integrity, and we need to prevent the deletion of a reference/parent record by adding a constraint on the lookup field. (see sample project download at the end)

Add a Constraint to a List

In order to add a constraint to a lookup field, we need to open the schema.xml file under the list definition. Unfortunately for us, Visual Studio does not provide all the possible attributes for a list definition, so a manual change to the xml file is required. The schema.xml contains the metadata that defines the list and all the fields. We need to find the field that we need (in our case client) and add the following attributes:

RelationshipDeleteBehavior="Restrict"	Prevent deletes of the reference or parent record when a dependency exists.
Indexed="TRUE"	This field needs to be indexed in order to support a constraint. This field can also be updated from the properties tab.

Attribute Changes:

Features Deployment

Note*: When building SharePoint JavaScript apps using Visual Studio, we need to be familiar of how the features deployment works and how it can affect a list field lookup or relationship constraint.

Now that we have our lists definition and constraint, we need to make sure that dependencies are deployed first. During the deployment of the application, the deployment does not fail if a dependency is not defined first. In our example, the project list depends on the client list to be deployed first. If we deploy the project list first, the client relationship constraint will not be applied to the list, and the parent records could be deleted leaving orphan records. 

In order to prevent this deployment problem, we need to make sure that the features are deployed in the correct order. In our example (see image below), the Application feature (contains the web application artifacts) is defined before our lists. We then define the client and project lists.

By defining the client feature lists (with the client list definition and instance) before the project feature, we make sure that our constraint will be deployed properly. This helps us make sure that on the server data integrity is enforced. The order of the features can be rearranged by opening the package file under the package folder.  This opens an interface that allows us to move features up or down.

Now that we have our list definitions, we could move forward with building a SharePoint AngularJS SPA that shows how this constraint is actually working.  We will do this in another blog entry.

A sample of this project can be found here:  Github

Thanks

A SharePoint list can have a field type lookup which is a reference to another list. As an example, we have a client and project lists. The...

Read Article →

AngularJS Minimized File Unknown Provider

We have a working AngularJS single page application (SPA), but the moment we minimized the JS files, the app breaks with an Unknown Provider error.

When facing this problem, we need to look at how we are injecting dependencies into our modules because when minimizing the files, the parameters name will be changed and Angular would not be able to resolve the dependency.

Implicit (bad) Injection Approach

We start by looking at a common way of injecting dependencies which can lead into a problem.

    var app = angular.module('app', []);     

    app.config(appConfig);

    app.run(initApp);

    app.controller('appCtrl', appCtrl);

    

    function appConfig($myProvider) {

        $myProvider.appConfig();

    }

    function initApp(myService) {

        myService.initApp();

    }

    function appCtrl($scope) {

        $scope.appCtrl = 'hi ozkary';

    }

In this example, we are defining a module that has a configuration, app initialization and controller functions. When we define those functions, we are only setting the function names, but the function implementation has a parameter which indicates what needs to be injected. The problem with this approach is that when this code is minimized, it looks as follows:

function i(n){n.appConfig()}

function r(n){n.initApp()}

function u(n){n.appCtrl="hi ozkary"}

var t=n.module("app",[]);

t.config(i);

t.run(r);

t.controller("appCtrl",u)

As we can see, the parameters are renamed to “n” at which point there is probably no dependency with such name, and Angular is not able to find it. This is why we get the ugly Unknown Provider error.

Explicit Injection Declaration

To address this problem, we need to change the way we declare the dependencies using an array as parameter. With this approach, our code changes to this:

    var app = angular.module('app', []);

    app.config(['$myProvider', appConfig]);

    app.run(['myService', initApp]);

    app.controller('appCtrl', ['$scope', appCtrl]);

   

    function appConfig($myProvider) {

        $myProvider.appConfig();

    }

    function initApp(myService) {

        myService.initApp();

    }

    function appCtrl($scope) {

        $scope.appCtrl = 'hi ozkary';

    }

The advantage of this approach that is that the array values are not mangled by the minimization process, and this allows Angular to find and inject the dependency. The minimized version of our code now looks like this:

function i(n){n.appConfig()}

function r(n){n.initApp()}

function u(n){n.appCtrl="hi ozkary"}

var t=n.module("app",[]);

t.config(["$myProvider",i]);

t.run(["myService",r]);

t.controller("appCtrl",["$scope",u])

Yes, the dependency name is kept, and Angular should be able to resolve it. We can also notice that the parameter “n” is still used in the function, but what is important is the name declared on the array.

Moving forward, we should explicitly define our dependencies as minimization of resources is now a must standard.

Hope it helps.

We have a working AngularJS single page application (SPA), but the moment we minimized the JS files, the app breaks with an Unknown Provide...

Read Article →