I signed up for the free azure website (not web role) and installed DNN 7 from the app catalog. So far so good.
My concern: The last time I checked (and I could be wrong) the application package that is published to azure is immutable and if you want to make changes to it, you must publish a whole new package to azure. Since DNN allows for upgrades and module installations, are these changes persisted? Can you still upgrade DNN by FTP'ing the upgrade package over the installation? If not how do you do it? I know about the dotnetnuke accelerator for web roles but I want to stick with the azure websites for now.
The immutable thing is for Web Roles, not Azure Web Sites. If you make a change to a web site, it is persisted.
Related
I am developing Mobile App .Net server and want to use the service on self hosted servers for production usage. The service will be deployed on IIS instead of Azure portal. I am working on offline data sync feature using Microsoft.Azure.Mobile.Server package. And for client Microsoft.Azure.Mobile.Client is being used. And all these packages and dependent libraries are open source as its available on github.
So, what about its licencing? Is there any limitation or licencing clause that restricts from using these applications without Azure portal?
Or its free to use?
As you mentioned, these libraries are open source licensed with Apache 2.0. So, you can use them without any problem, as long as you mention the original authors.
I am trying to use ABCpdf .NET with Azure App Service and getting the following error when generating a PDF.
Unable to render HTML. Failed to configure IE 9 or above for the MSHtml engine:
Access denied while writing to the registry.
For IIS applications, please enable "Load User Profile" or
consult MSHtmlBootstrap in the documentation.
Usually in a VM I would set Load User Profile to True and it works but in Azure App Service, I do not have access to IIS Application Pool configuration.
According to the developer of ABCpdf, it should work with Azure websites.
http://www.websupergoo.com/support-azure-abcpdf.htm
Windows Azure Web Sites
WAWS sites operate as 32-bit processes in a multi-tenanted environment. In order to isolate one site from another WAWS is locked down to prevent inter-process communication. While you may find ABCpdf (32-bit) will install to WAWS, we expect the functionality will be diminished.
You cannot modify the registry with Azure Web Apps (formerly Web Sites). So, you're getting an error because the app cannot register itself. Being a multi-tenant service, you are not allowed to make registry modifications.
You need to go back and look at that page again, where they suggest using a VM or a web/worker role (both of which do allow for registry modification).
Even though this is a few years old it's the top StackOverflow question for "ABCpdf App Service" so it seems pertinent add an updated answer.
As of version 12.1 ABCpdf.NET includes the ABCWebKit HTML rendering engine based on WkHTMLToPdf 0.12.6 (Qt patched version).
Although limited compared to the default ABCChrome engine, it will enable rendering in a 64-bit Azure App Service on Windows using Basic App Service plans B1 and above.
NB: it will not work on any of the free App Service plans, or on 32-bit instances.
More information:
Updated ABCpdf .NET Azure Deployment Guide for App Services
Example project on GitHub
so I have several websites running on Azure. One has its own instance, and I know I can upgrade that by just updating the code. But quite a few websites I have are Azure Websites. I installed Orchard from the gallery. Orchard 1.6 has just been released, not on the gallery yet, but will be soon I assume. Is there a way of upgrading my existing websites to 1.6 when it is released?
Or do I have to like ftp the latest code?
Azure web sites are like a regular hosting plan: you upgrade the same way you would anywhere else (WebDeploy, FTP, Git...). See http://docs.orchardproject.net/Documentation/Upgrading-a-site-to-a-new-version-of-Orchard
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...
What type of projects/software applications are suitable for Azure and why?
Thanks
Rather than thinking of what can be supported in Azure, it might be more helpful to think about its challenges as you decide to port your app over:
Web applications. Since a Web Role hosts IIS, you'll generally have little issue porting a general-purpose asp.net or asp.net mvc website to Azure. There are some glitches you'll run into - see my related answer for more details.
UI. If your app has specific output similar to a WinForms app, you won't be able to run it since you have no video output.
GPU dependencies. If you're doing some background processing dependenton a specific GPU, you won't be able to run in an Azure VM.
Registry and other system-level access. If your app needs to update the registry or run an MSI, you won't be able to install your app.
Instance affinity. If your app requires session stickiness (e.g. a logged-in user MUST visit the same server instance with each access), you won't be able to accomplish this.
COM interop. COM interop is very limited, since you can't install anything via the registry. If you rely on Excel Services, you won't have that capability.
SQL limitations. SQL Azure is limited to 50GB today, and offers no ability to custom-tune the server instance. Also, while it does support a big subset of SQL Server, it doesn't support 100% of SQL Server, so it's possible some of your sprocs may no longer work. There's no SQL Agent today, so you'd need to recreate that functionality in a worker process.
That's just a quick braindump of some challenges you might run into - I'm sure there are others.
Just keep in mind that Azure is providing Windows 2008 Server images for your app to run on, so if your app can run in that environment today, and doesn't require things I listed, you should be in pretty good shape.
You can make most of the .NET projects working in Azure. Azure has support of following project types: web site (both ASP.NET and ASP.NET MVC), worker (background application) and wcf service.
Don't forget security too - there's various ways of authenticating onto Azure but none are as simple as just setting IIS/ASP to windows auth.