Is it possible to change connection string on cloud service deploy-time? - azure

I wrote an asp.net mvc 4 web site. For my corporation purpose, I created several publish profiles, in order to publish it on differents azure websites. Each profile changes the connection strings.
It worked very well.
I am now trying to do the same thing with an azure cloud service (I added my web site as a web role in a new cloud service project). But I can't find out how to change the connection string of my web role depending of my cloud service project publish profile at deploy-time.
Is there a way to do such a thing ?
Thanks !

You could store the connection string in the ServiceConfiguration file .cscfg of your Role and then use the following in your code to retrieve the setting:
string connectionString = RoleEnvironment.GetConfigurationSettingValue("myConnectionString");
You can modify the values in the ServiceConfiguration through the Management Portal once deployed.

Related

Is there any way to debug SharePoint online Remote Event Receiver i.e. provider hosted app without using Azure Service Bus?

Is there any way to debug SharePoint online Remote Event Receiver i.e. provider hosted app without using Azure Service Bus ? I don't have Azure Service bus subscription as my organization doesn't allow to connect code over there.
Assuming it's a provider hosted app...you can debug it like any other web app. For example, I have typically deployed my provider hosted apps to Azure, and then use Visual Studio to debug the Azure web site. I've used it in the past on remote event receivers as well.
It's rather lengthy, but you can look at aspects of such a design here: https://samlman.wordpress.com/2015/02/28/cloudtopia-connecting-o365-apps-azure-and-cortana-part-1/.
You have to enable debugging on the web site - have you tried that? I described a second way to do it here if you want to give it a shot: https://samlman.wordpress.com/2015/02/27/another-cool-way-to-remotely-debug-azure-web-sites/.

Azure App Service Application Key (where is it) - 2016

I've created an Azure App Service application and pushed it to Azure. Unfortunately, I am unable to find the application key that I should use in my client to create the connection to the service (as seen in the below code ).
MobileService = new MobileServiceClient(
"http://xxxx.azurewebsites.net",
"applicationKeyShouldGoHere");
I've seen a few answers to this question, but all seem to point to authenticating the USER within the client. I want to authenticate the call to the service.
Azure Mobile Services had an application key but I'm unable to find the key for App services. The difficulty is multiplied with the fact that the Azure Portal seems to get modified every couple of months...
Thanks in advance.
The new Mobile App Services doesn't need/use any Key.
You need to use Version 2+ of the Microsoft.WindowsAzure.Mobile package on your client.
The older SDK created the MobileServiceClient like this:
new MobileServiceClient(applicationURL, applicationKey)
The new (Version 2+) like this:
new MobileServiceClient(applicationURL)
So there is no need for a key.
We don't publish Azure App Service in the way as we publish Mobile Services(Actually in new portal, there is no Application Key for Mobile services either).
When publishing Azure App Service, you need to download the publish profile from the portal. Right click the project in VS, and choose Publish.... In the Publish Web wizard,import the publish profile you downloaded. When the wizard completed, the App Service will be published to Azure.
Check web-sites-dotnet-get-started for details.

Access websites connection string from web jobs

I have been trying to move my connection strings from the App.config files for my webjobs to the host website through the Azure Portal. I've tried the likes of:
ConnectionStringSettings test = ConfigurationManager.ConnectionStrings["AzureDB"];
I've also tried using GetSetting and putting the connectionstring in the app section of the configure options as a key/value pair.
That still only shows my local connection strings. I've also tried using the CloudConfigurationManager to no avail.
There are examples all over the place and in SO citing:
However, you don't have to set it in app.config for the web job if you set them in the portal. The WebJobs SDK knows how to read them from there.
So how do I access them?
Install Microsoft Azure Configuration Manager
Move your connection strings to the appSetting section (for debug purpose)
Retrieve you connection string using the CloudConfigurationManager:
var myConnectionString = CloudConfigurationManager.GetSetting("MyConnectionString");
You can now manage your connection string from within the Azure portal.
Azure WebJobs shares the settings with your website
http://blog.ploeh.dk/2014/05/16/configuring-azure-web-jobs/

Why do I need to configure connection strings for WebJobs in Azure Management Portal rather than in the App.config of my WebJob?

I created a scheduled Azure WebJob by right clicking on my WebApp project and adding a New Azure web project. I set the the AzureWebJobsDashboard and AzureWebJobsStorage connection strings in the App.config of the WebJob project. I left the default code in the .cs files alone for now. Next, I published from Visual Studio (2013 Update 4 by the way) to an Azure website. It created the WebJob and I can run it from the Azure Management site or Visual Studio and it is successful. I can see the output logs where I expect them to be. However, the Azure WebJob Details page shows the following warnings/errors:
Make sure that you are setting a connection string named
AzureWebJobsDashboard in your Microsoft Azure Website configuration by
using the following format
DefaultEndpointsProtocol=https;AccountName=NAME;AccountKey=KEY
pointing to the Microsoft Azure Storage account where the Microsoft
Azure WebJobs Runtime logs are stored.
The configuration is not properly set for the Microsoft Azure WebJobs
Dashboard. In your Microsoft Azure Website configuration you must set
a connection string named AzureWebJobsDashboard by using the following
format DefaultEndpointsProtocol=https;AccountName=NAME;AccountKey=KEY
pointing to the Microsoft Azure Storage account where the Microsoft
Azure WebJobs Runtime logs are stored.
It also provides a link that was to http://azure.microsoft.com/blog/2013/07/17/windows-azure-web-sites-how-application-strings-and-connection-strings-work/ which doesn't explain why I am getting the error message.
Now, to get this warning/error to go away, I go add the same AzureWebJobsDashboard connection string in the configure page in the Azure Management site.
So, I'm trying to figure out if I did something wrong or if this is just a kink in the WebJobs that Microsoft hasn't fixed yet. I would really like to be able to have this in the App.config rather than have to remember to set it up in each website we spawn up for different environments.
Thank you very much for your time and help.
The dashboard doesn't have access to your web job's app.config file and even if it did, you might have multiple webjobs so it wouldn't know which connection string to pick. That is why you need to set the connection string in the portal.
However, you don't have to set it in app.config for the web job if you set them in the portal. The WebJobs SDK knows how to read them from there.
I had to manually add authorization headers:
For get the value anfter "Basic " I used this code:
var byteArray = Encoding.ASCII.GetBytes("<user>:<password>");
var base64 = Convert.ToBase64String(byteArray);
Ithink is a Azure Scheduler UI bug

Windows Azure and MVC5 - How to use same database schema for desktop and mobile versions?

I have developed an MVC5 web application which uses Code First Migrations to build out the database. Now I am attempting to develop a mobile app (using PhoneGap if that matters) that exists as a native option to access the data of the application. However, I am having trouble finding a way for the databases to work nicely together.
Ideally, I'd like to use the same database schema entirely, and just have the application and the mobile app point to it. The database is hosted on Windows Azure. The issue I'm having is that with Azure, the standard way of handling databases with mobile apps is to use an Azure Mobile Service. However, when that service creates a database, it creates its own schema named after the service, whereas the web application uses the dbo schema. So the Users table might exist in dbo.Users for the web app, but in myAppName.Users for the Mobile Service.
I've already explored this solution, which seems to mirror my problem. However, there is an additional issue. The .NET MVC5 Authentication services use dbo as the default schema and there seems to be no way to change that.
Bottom line, if I use the default schema, the mobile app cannot access the database, but if I move the tables to the Mobile Services schema, the Login/Authentication fails because the tables don't exist in the default schema anymore.
Am I missing something here? It seems like it should be a fairly common task to have a web app and mobile app accessing the same database, but I've been investigating this for days without finding a solution.
Thanks for any help you can provide.
The standard way of using a database for mobile apps in Azure is not Azure Mobile Services. I mean, I would not call it standard but just one of the options.
When Azure Mobile Services creates a database it does not create the database with its own schema. Azure Mobile Services does not have a predefined schema. You can define your own schema. The only predefined logic is the addition of the azure mobile services tenant name as a prefix to all table names. This is done to help you host multiple azure mobile service accounts in a single database. You can override this logic if you write the app in .NET. I'm not sure if that's possible if you roll a JavaScript based Azure Mobile Services account.
My suggestion to you would be to roll your own ASP.NET Web API project and host it in Azure. You can host in Azure Web Sites or Cloud Services according to your requirements. Once you have your own APIs running in Azure you should have no problem accessing the APIs from a web site or mobile app.
Hope this helps.

Resources