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
Related
I would like to know what are the list of default fonts used by an azure app service.
This is for an app which we have installed on azure app service and its source code does not have any fonts folder.
Adding to Md Farid’s response, if you’re looking at rendering custom fonts (system-installed font is used instead) not supported on the standard App Service, because of sandbox restrictions.
Azure App Service provides pre-defined application stacks on Windows like ASP.NET or Node.js, running on IIS. The preconfigured Windows environment locks down the operating system from administrative access, software installations, changes to the global assembly cache, and so on.
This is because, the Azure Web Apps run in a secure environment called a sandbox. Each app runs inside its own sandbox, isolating its execution from other instances on the same machine as well as providing an additional degree of security and privacy which would otherwise not be available.
However, using a custom Windows container in App Service lets you make OS changes that your app needs, so it's easy to migrate on-premises app that requires custom OS and software configuration. This tutorial demonstrates how to migrate to App Service an ASP.NET app that uses custom fonts installed in the Windows font library.
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-windows-containers-custom-fonts
Also, see sandbox page -https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox
Just added an answer here -
it is any web fonts you want, just config in web.config and add the font in a directory in the app service under WWWROOT
Is it possible to install fonts on an Azure App Service?
Seems there is no such official docs about that , but you can follow this post to register mime type in Azure webapp IIS for your own custom fonts files.
I think you can mount the storage like in that ticket: Azure Linux App Service with .Net Core Stack. Unable to use NodeJS
i have a web application which is created using .net framework 2.0 which is running on windows server 2003.is it possible to migrate that to Microsoft azure.if so does it require an entire rebuild on azure?
A really useful utility for this case is Azure Migration Assistant.
https://azure.microsoft.com/en-us/downloads/migration-assistant/
It will check all your IIS sites and show you if it can be moved up to an App Service, checking target framework, port bindings, etc.
If everything is ok, it can do the migration for you.
Worst case scenario, you can move your application to Azure inside a VM.
It depends on what you mean by "migrate".
If you think about moving as is, you have an option to choose IaaS, where you'll just get a VM and do what you want on it. That'll give you both full control as well as full responsibility over your app.
Otherwise, if you want to avail of the PaaS offering, you'll have to make minor tweaks to your application (assuming the framework version is supported).
Current my company delivers our software to our customers through a Citrix Xenapp Server. As administrators we are able to launch instances of the servers and our customers are only able to launch their specific application
My Question is does Windows Azure also offer this type of environment. I am looking to deploy a new version of our application and I am leaning towards Azure, but if that is the direction we go in I would like to migrate all of our existing system to Azure and not maintain both Azure and Citrix.
Greg,
In principle yes you can do this, but you can't just plug in Azure as a direct replacement for XenApp (with zero/minimal effort). Azure effectively has it's own runtime. While it is Windows based and there is certainly potential to reuse code in an existing app in an Azure equivalent, you would need to re-write your app to make it run in Azure.
Given your app is running on XenApp it is likely it is a fat client app, i.e. most of its logic lives in the main executable that you run on XenApp, with potentially some other back end services being utilised. In comparison you should think of Azure as a platform for providing web apps. So you would re-architect the app as an Azure hosted web app, then you could deploy it via Azure in a multi-tenanted manner to your customers who would then access it through a browser rather than a Citrix Receiver.
Regards,
Donovan
I'm curious to know if this is possible, and if so, is it a good or bad idea?
We are developing an Azure application that is largely centered around worker roles that receive their work on a CloudQueue, and put the results in a CloudBlob, that the client then downloads. The web interface itself is a dead-simple ASP.NET MVC site that throws jobs in the CloudQueue, and builds URLs to download CloudBlobs.
Currently we accomplish this by having a Azure Cloud Project in our solution, which has a Web Role with the UI, and Worker Roles with the actual work.
Could we use Azure Websites to publish and host the UI, which calls back to our Worker Roles? The Azure DLLs are just regular old .NET libraries, I'm assuming Azure Websites won't have a problem with them. So, when we want to update the UI, we just publish with Visual Studio. And when we want to update the Worker Role - which is 300MB+ and has a bunch of nasty dependencies like Crystal Reports - we can build the cloud bundle and update the Cloud Service through the Azure management portal.
This seems to me like doing this would make it easier to update the UI. I think it would also be cheaper to host it, as we won't have to buy a bunch of instances for the Web Role.
If your question is "Could we use Windows Azure Websites*", based on your application architecture, you sure can use Azure Website to deploy your front end and configure all the networking connection properly so you can continue access other Azure Storage services. As you are using mostly Blob and Queue, you can continue use HTTP/HTTPS settings in the Azure websites. You can keep worker role by as it is however if it is very complex to deploy, using Windows Azure VM may be another direction to go.
I could say website deployment could be easier if your web app does not have something complex to configure in web server as websites may not be able to match web server level configuration compare to webrole and Azure VM. Answering "Easier and cheap" could be very subjective as this is all depend on load and distribution so you would have to try and evaluate it.
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.