I have a site that works by a number of webservices talking to each other, hosted on the same site. This works perfectly well in IIS. The console part of the application passes a Bing Maps key and displays Bing Maps perfectly using Geolocate.
In the web.config for the app I have this line:
<add key="BM_Key" value="NOTREALVF7QTW-LZfG0p7-RhSPeGvlfx3fdtgR-Gk_SB-wfF8kCj2J7nI57wjIna"/>
in a different application hosted on the same IIS
<endpoint address="http://dev.virtualearth.net/webservices/v1/geocodeservice/GeocodeService.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IGeocodeService" contract="GeocodeService.IGeocodeService" name="BasicHttpBinding_IGeocodeService" />
<endpoint address="http://dev.virtualearth.net/webservices/v1/geocodeservice/GeocodeService.svc/binaryHttp" binding="customBinding" bindingConfiguration="CustomBinding_IGeocodeService" contract="GeocodeService.IGeocodeService" name="CustomBinding_IGeocodeService" />
When I convert this to Azure App Service, I have the webservices talking to each other and to the backend Azure hosted SQL.
However, the Bing Maps fails with the error "Invalid Credentials. Sign up for a developer account at.."
Bing Maps works fine in the IIS environment and the key we have is valid, so what do I need to do to get it working in the Azure App space?
It feels like the BM_Key is not being passed to the Bing Maps service or it is being blocked somehow.
Please advise if you know anything worth trying.
I have already tried creating an Azure Bing Key, but this does not work if I substitute the keys. I have also added the BM_Key in the Azure App Service Application Settings, but this does not work.
Many thanks all
Pete
That looks like the old Virtual Earth SOAP services which have been deprecated for a couple years now and taken offline last summer. If you want to use Bing Maps, use the REST services: https://msdn.microsoft.com/en-us/library/ff701713.aspx
If working with .NET, there is also a toolkit available here: https://github.com/Microsoft/BingMapsRESTToolkit
Alternatively, you might also want to take a look at the Azure Maps REST services:
https://azure.com/maps
https://learn.microsoft.com/en-us/rest/api/maps/search/getsearchaddress
Many thanks to Ricky Brundritt for your help in directing my thinking process. "If it works in IIS then there is no reason for it to not work in Azure." I focused on our app and found some inconsistencies in versioning between the database and webservices, which when I updated Azure database to the same version as used in IIS, it worked perfectly.
This is now marked as resolved.
Related
I'm in the process of evaluating App Service and in particular Api apps and logic apps. I want to be able to make use of git deploy for an Api app instance.
This article https://azure.microsoft.com/en-gb/documentation/articles/web-sites-publish-source-control/ mentions that even though it is based on web apps, you can apply the same processes to api apps, however, when I attempted to follow the tutorial using an api app instance, I was unable to see the "deployment" tile on the api app blade in the azure portal. I was able to complete the tutorial for the web app instance.
Does anyone know why I wouldn't be able to see the deployment tile for an api app blade?
I want to use the api app so I can make full use of swagger and the logic app service.
Edit
Thinking about it, do I even need to use an api app or could I get away with using a web app (with swagger meta data) for connecting to logic apps?
Update
Found it - see my own answer.
OK, I found it and it's not a bug. I was being (a bit) dumb. Following this article, I discovered that I needed to click on the Api app host section and then all settings then continuous deployment.
This is, imho, a poor UX decision here, given the blade looks exactly the same as others that do have the deployment tile, but at least I can set up git deploy for my api apps now.
#Simon
This may be a bug - I will poke the Azure Team for it asking that. Even though, WebApp, APIApp and MobileApp are EXACTLY the same service, only changing name. So, if you can see deployment tile for one of them, you should be able to see all others then.
BUT, there is a "invisible business link" around them that make all things working. When you work with Logic Apps, it will search for custom API Apps at - guess what! - you API App list. So, you can host a API application at WebApp, but probably the Logic App will not go for it by default.
I am currently doing some research for the development of a mobile application for our company that should support offline data sync (on an iPad). We have explored many possibilities including PhoneGap/Cordova, Xamarin and simply native iOS development. Xamarin, for many different reasons, seems to be our best choice, so my question will assume we will develop in Xamarin.
I was looking into a library for managing offline data synchronization and the most obvious solution is Microsoft Azure MobileServices. However, my company is Canadian, and apparently it's hard to trust (legally) our data to clouds based in the US. Since we already deployed internally our WebApi on our intranet, I figured there was probably a way to point the MobileServices library to our own WebApi. I have read about the Azure Hybrid Connection possibility, but our data still conveying through Microsoft servers might not be a possibility. So, my question is this:
Is there a way to configure the Microsoft.WindowsAzure.MobileServices Client library to point directly to our intranet, RESTful WebApi backend, without going through any Microsoft Azure servers ?
I understand that, in order to be able to use the Client librairies seamlessly, we probably would have to adapt our WebApi to implement the necessary .net Backend interfaces. I'm mostly wondering if it's even possible as the MSDN documentation on the libraries all seem to point to direct connections to their servers (no possibilities to configure your own connection strings) and all instructions redirect you to their Azure Mobile Services website.
Thank you.
If you look at the API for your mobile client, you'll notice that the Azure Mobile Services Client SDK only cares about two things:
new AzureMobileClient( url, appkey)
...where it's hosted shouldn't be a concern. Everything else is just configuration.
If you want to host the Azure Mobile Services Backend on your own servers, technically you could do this, but there are likely a few caveats. Microsoft has announced that they will be launching a Canadian Azure data center, but we won't see it until 2016.
In the meantime, here's how you can host the services locally. Note that I have not tried to emulate all of the features of Azure Mobile Services (aka Zumo) so your mileage (or kilometerage) will vary.
Hosting Locally:
From a technical feasibility, you absolutely can run the services locally. I know this because you can create the Azure Mobile Services Backend project from within Visual Studio and run it locally for development purposes. This is what our development team does for testing their mobile applications.
Note that you can create the Azure Mobile Service backend directly from within Visual Studio: New Project -> Cloud -> Azure Mobile Service. You can also download the exact same template (pre-configured with your URL and ApplicationKey) directly from the Azure dashboard: Create -> Mobile Service.
Obviously, if you're hosting it on your server it will be up to you to configure and use a proper SSL certificate for your site.
ZUMO Permissions:
By default, the security roles on the server are turned off. So if you're locking down any of your methods using the [AuthorizeLevel] attribute these settings will be ignored at runtime. If you need to enable this feature you can do so by modifying the WebApiConfig.Register() method and marking the site as self-hosted: config.SetSelfHosted(true).
Configuration:
From a configuration perspective, the Azure Mobile Service dashboard provides several tabs for configuring Identity, Push Notifications, Connection Strings and App Settings. Sadly, you won't have a dashboard, but all of these settings have a corresponding value in the local web.config. Any value you provide here is automatically overwritten in Azure, but they're used when running locally.
The minimum settings you'll need to configure are listed here. The ApplicationKey you can distribute with your ZuMo client, but the MasterKey is for the Admin authorization level so you'll want to keep that secret. The MobileServiceName is used by the EntityFramework for your database schema and what appears in the URL of your site.
<add key="MS_MobileServiceName" value="myzumosite" />
<add key="MS_MasterKey" value="masterkey" />
<add key="MS_ApplicationKey" value="appkey" />
Values that start with a MS_ prefix map to corresponding values in the Azure Portal. MS_GoogleClientID and MS_GoogleClientSecret map to the Google Identity values in the dashboard, for example.
Any other value in the AppSettings node is immediately accessible via the ApiServices.Settings property and corresponds to the Settings node in the Azure dashboard.
Database connection strings continue to exist in the connectionStrings node. The same is true for azure notification hub.
Database:
Obviously, the database you configure will be up to you as well. Permissions and User accounts are also obvious. There may be some minor differences between the SQL Azure syntax for Entity Framework database migration scripts that you'll need to worry about. (I've discovered the database migration scripts don't work from the Package Manager, but they do work when the database scripts are run when your website starts)
Caveats:
You will not have a nice dashboard for monitoring performance of your site, reviewing logs or changing runtime settings
You will not be able to scale out your site immediately; Scaling and deployment will be your problem
Deployment configuration is your responsibility (Project -> Publish won't be available unless you configure it)
Not sure if you'll be able to use Azure Active Directory as an authentication scheme, though from the sounds of it that won't be a concern. You can write your own authentication providers: Microsoft's Zumo library only supports a handful, but the underlying Owin.Security package that Microsoft uses supports several dozen systems!
Your site will need to be publically visible to your mobile clients
Push Notifications should work, but you will be using Azure's notification hub for this.
I have no idea where ApiServices.Log will go
The easiest path to take would be to:
Create the Mobile Service in Azure to get the notification hub and settings preconfigured
Download the starter site from the dashboard
Configure the web.config as mentioned here.
It's not possible to simply configure WAMS Client library to work with your own WebApi Backend.
But WAMS library is available at github, so I'm sure you can reuse a lot of code from the WAMS project, especially if you want to use a PCL project.
To route your data securly through Azure, you could think about setting up express route. Additionally, for last weeks update, it's possible to apply a custom domain to the WAMS Backend, including your own certificate to secure your connection.
In IIS you can create an Application on a site so now I want to try and accomplish the same on Azure Cloud Service:
tenant.mysite.com - One Cloud Service
tenant.mysite.com/api - Another Cloud Service
The reason I want it done like this is cause this is a multi-tenant site and the api needs to be called with the tenants URL.
Is there any way out the box to do this with Azure? Am I looking at the whole solution wrong or do I have to look into doing a proxy of sorts?
I did host the application similar to what you have did.
There are a few points that you will need to take care of
1. Overlapping sections of web.config file should be locked using <location path='.'.... > tags
2. Proper references for the dlls to be given
This is easily achieved in both the Azure websites and Azure Cloud Services. The link that explains how you can get started is given below. Post questions if you have tried this and run into some issues.
http://blogs.msdn.com/b/tomholl/archive/2014/09/22/deploying-multiple-virtual-directories-to-a-single-azure-website.aspx
I have been looking through the C# and Rest API's for the Microsoft Azure web sites but I cannot find a way of executing the drop box sync command that can be done through the azure portal. Is this possible from an API that any one knows of?
There is support for deploying a WebDeploy file to a Website using PowerShell, so there must be a corresponding API for it.
If you download the publish settings for the website, you'll se that it has a PublishUrl which is the WebDeploy endpoint for the server, along with a msdeploySite, which is your unique site on the server. A WepDeploy file is nothing more than a fancy zip (AFAIK), so by digging into this it should be possible to come up with something which can talk to the webdeploy endpoint and thereby publish.
I don't think that API is something Microsoft publishes though, so you might have to dig deep.
I have created a Cloud project on VS 2012 with .net 4.5. This consists of two web roles, an API and an front end website.
I have followed the instructions here: http://msdn.microsoft.com/en-gb/library/windowsazure/gg443832.aspx in order to set up remote desktop, and deployed the service.
When I try to connect (I have double and triple checked the credentials), I get told that 'The credentials that were used to connect to did not work. Please enter new credentials.
My web roles are both operational, and I can visit them both in the browser.
I have tried waiting a while after deploying for changes to propagate, but this makes no difference. The only thing I can think of is that I have not done anything with certificates as of yet other than download the appropriate bits in order to deploy from visual studio. I can't find any documentation that says I need to though.
I have also tried out adding various domains to the username but nothing works.
Am I missing something, or is there a chance that there is a bug with azure at the moment?
EDIT: Have now tried deleting the cloud project from visual studio, deleting the cloud service in azure and redeploying with only a single web role. Still seeing the problem.
Just checking for completeness,
Did you use the button on the website for your first access?
http://blogs.msdn.com/b/avkashchauhan/archive/2011/04/03/how-to-login-into-windows-azure-virtual-machine-using-remote-desktop.aspx
On the other hand, this is the link that worked for us, it includes how to set up the cert needed too.
http://geekswithblogs.net/MagnusKarlsson/archive/2012/12/03/connect-to-running-web-role-from-remote-desktop-connection-and.aspx
I fixed this by removing the <Import moduleName="RemoteAccess" /> and <Import moduleName="RemoteForwarder" /> lines from the .csdef then removing all references to Microsoft.WindowsAzure.Plugins.RemoteAccess and Microsoft.WindowsAzure.Plugins.RemoteForwarder within the .cscfg files. I then was able to deploy and enable remote desktop access from the newer Azure portal.
After adding users to the Azure Active Directory Domain, (e.g. smith#mydomain.onmicorosft.com), I tried logging in as one of those users, but got "Your credentials did not work." After some trial and error, I found that I had to add the users (e.g. smith) as local users on the VMs. Once I did that, and assigned, passwords, the users could RDP in.