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.
Related
We use a app builder to create our applications, download them as .zip, and then just click "Add Application" on IIS, point to the application folder and it would be working.
Our applications require no server logic or database, they are self contained, the database is external and acessed via REST on javascript.
I can't seem to find the equivalent of the above procedure on Azure, it has options like Python/Node/Java/.NET but I'm not sure which of these fit our application needs.
How can I just easily upload a web app on Azure without any backend required?
If I'm understanding your question correctly, you can drag/drop a zip file into the "kudu" console of an Azure webapp to upload the file. Azure takes care of unzipping the file and putting the files in the web app.
To get to that portal, change your web app url to contain ".scm." and append /ZipDeploy to the end of the url:
https://yourwebapp.scm.azurewebsites.net/zipdeploy
Then drag/drop your file onto the web page.
From the main kudu page (remove zipdeploy from your url) you can upload entire directories of files if you need to. I regularly deploy webapps this way and it works great.
One of the easiest approaches is to make use of Azure App Services. This is Azure's Platform as a Service (Paas) offering that allows you to get a web site up fairly quickly whether that be a static site that is mostly client side logic or your more traditional apps such as asp.net\php\etc. You can deploy your app through various means from CI\CD, Github, FTP, etc. You can find more details and a 5 minute quickstart at https://learn.microsoft.com/en-us/azure/app-service/.
More recently Azure has offered the ability to host static web sites right in Azure's Blob storage. It doesn't come with all the features of Azure App Services and does not have any server side execution but has the advantage of price and simplicity and when used in concert with some CDN networks it can be attractive for static client side only sites. More details at https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-static-website
I Used Azure Website Migration Assistance to migrate my web service that was running on my Local VM's IIS. My Migration process was successful and also I was able to use this web service. But I can't find where to find the migrated source code in azure portal. All I can see is some 20Mb of data in on the dashboard graph of azure portal. If I need to changed some of my code where to do this?
What is on the Azure Web App should now match what was on your IIS server. Now, to update the web app, you can use the deployment techniques here: https://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/
The simplest method to deploy to check what content is on your web app would be to use the SCM site. This is available at: https://your-site-name.scm.azurewebsites.net. Go to Debug Console > CMD and then the site > wwwroot folder to see your web app content. You can also upload to the site via drag and drop.
Alternatively, you can download the publishing settings for your web app via the portal and then re-use the migration tool, select the site, and then upload the publishing settings. However I would suggest using the deployment techniques above first. (Disclaimer: I wrote the migration tool.)
There are multiple ways to push changes to your Azure Website/Web App. They are listed here: https://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/
One simple way is to use an FTP client like FileZilla. In the classic portal, you will find the FTP address (hostname) and the credentials in the dashboard tab. In the new portal, select your Web App and the FTP address will be displayed in the Essentials section at the top of the page. Click on Settings and Deployment credentials to set your FTP user password.
Another simple alternative is to use Dropbox. Take a look at this video for how to set instructions: https://channel9.msdn.com/Series/Windows-Azure-Web-Sites-Tutorials/Dropbox-Deployment-to-Windows-Azure-Web-Sites
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.
I don't have the latest version of the code deployed in the company's Windows Azure account, and I need to provide a fix to it. I know this can be done with "Azure Web Sites", but I'm not sure it's possible with "Azure Cloud Services".
Can anyone help?
If you did git deployment of the cloud service, you could fetch from the remote the same way you could with Windows Azure Web Sites. You may have updated the cloud service by uploading the package to blob storage first, in which case you could get the package. But, the package is not source code.
From a process perspective, you should label your deployments with a tag that can be matched in source control. You never know when a "hotfix" needs to be added to a branch off of the current production code.
In Windows Azure Cloud Services, instances are uploaded in the form of .cspkg packages.
According to the documentation, the Get Package operation retrieves a cloud service package for a deployment and stores the package files in Windows Azure Blob storage.
You could then download and extract this package (it is in ZIP file format) to retrieve its content. See this answer for more details.
In the case of ASP.NET applications, that will be a mixture of text files and binary assemblies (.DLLs). In the case of Java, it will be .jar files. You could use the appropriate decompiler to retrieve an approximation of the original source code. But it probably wouldn't be safe to change this reverse-engineered source code and upload it back into production, at least not without extensive testing.
yes. you can download it with an ftp client.
Ggo to dashboard of your site on https://manage.windowsazure.com.
Get credentials (username , password, host) and connect with you preferred ftp client.
Well, Azure now had a new portal and things are bit different. I had to retrieve the code for one of my websites.
To download the code,
go to App Service. In Overview panel, download publisher profile.
Now go to Deployment credentials panel. Enter the username for FTP and choose a password.
To connect to ftp, you need the URL from publishing profile (example.PublishSettings).
Now fire up your FTP client (FileZilla in my case) and put the FTP address and put the username like sitename\ftpusername (example\ftp-exmaple-user for me) and put in the password you choose in Deployment credentials panel.
wwwroot contains your code!
I realize it's an old question, in case anyone else needs it... I use the Cloud Explorer in Visual Studio 2017. In the Cloud explorer, you can drill down Subscription -> Resource Group -> App Service -> Files. Then, at the bottom of the Cloud Explorer, click "Download Files as a Zip."
I am looking at migrating a dotnetnuke website to Azure. I need both staging and production versions of the site to be running.
I have looked at using Azure Websites, but at the moment there is no support for SSL on custom domains so this can't be used for the production website. I have migrated the staging site to an Azure Website and now have numerous options for publishing updates (ftp, git, using web matrix).
Due to the constraints of Azure Websites, I used the DNN Accelerator to create a cloud service for the production environment. This set up will allow me to have control over IIS and therefore manage SSL certificates (I think).
The problem I have with this is there does not seem to be any publishing options. The only way I can publish is by connecting to the Azure instance via RDP and then copying the website files onto the files system.
Are there any other ways of publishing? I have looked at converting the website to a WAP, but I believe this has implications when it comes to updating to new DNN versions.
You should never publish your application through RDP since these changes are non-persistent (meaning what you published might disappear after a hardware failure / ...). Adding new instances would also mean that these instances don't have the files you published before.
I suggest you start by looking at the DotNetNuke Azure Accelerator first. If this doesn't fit your needs you might always try to build something yourself, but if you want to say with a regular website and not a web application I wouldn't count on Visual Studio support. In that case you might want to look at creating a package from the command line and using startup scripts to add your website in IIS.
Sounds like you need to use a Start-up task to install the files in the correct place for a Web Role (Cloud Service) Smarx has a nice overview here, MSDN has a wealth of info too http://blog.smarx.com/posts/introduction-to-windows-azure-startup-tasks
Another option is IAAS for Azure with a persisted VM, more work mind you, Cloud Service would be the most efficient and correct solution...