I'm trying to convert my page to PDF using HiQPDF. The code works fine when I run it on my local machine (through localhost), but when I push it to the server, I receive this error:
HTML from URL layout error
Here's some example code:
HtmlToPdf htmlToPdfConverter = new HtmlToPdf();
htmlToPdfConverter.ConvertUrlToFile("https://website.com/12345", filePath);
filePath is the path where the PDF should be created. Path is correct and the folders are all created. When I go to https://website.com/12345 as my site, I can view the page fine. Even in incognito. If I simply replace website.com with localhost it works fine locally.
The error suggests there's a problem with the code of the page.. right? What could the issue be?
Are you using this in an Azure web app? If so, it's not supported. If you're using Azure it would need to be deployed to a web role running in a cloud service.
You can use the HiQPdf library in Windows Azure Cloud Services and Virtual Machines but not in Web Sites because the Web Sites run in a restricted sandbox. Using Visual Studio you can easily transform an existing ASP.NET 4.0 or MVC application into a Web Role by adding a cloud service project to the solution containing your project. For this, open your solution, right click on the ASP.NET project and select the 'Add Windows Azure Cloud Service Project' option from menu. Right click on the added cloud service project and select the 'Package' option to produce a package and a configuration file you can deploy as an Azure Cloud Service.
http://www.hiqpdf.com/FAQs.aspx
I am using HiQPdf DLL to convert my HTML into PDF. It works on all server but when i deployed this to Azure ,it throws an error. Below is the error:-
"HiQPdf.HtmlToImage HTML layout error"
Thanks for your help in Advance.
Please check the HiQPdf HTML to PDF Converter for .NET FAQ regarding the Azure deployments. Below I copied the information from that page.
Basically you can use the HiQPdf library in Windows Azure Cloud Services and Virtual Machines but not in Web Sites because the Web Sites run in a restricted sandbox. Using Visual Studio you can easily transform an existing ASP.NET 4.0 or MVC application into a Web Role by adding a cloud service project to the solution containing your project. For this, open your solution, right click on the ASP.NET project and select the 'Add Windows Azure Cloud Service Project' option from menu. Right click on the added cloud service project and select the 'Package' option to produce a package and a configuration file you can deploy as an Azure Cloud Service.
I am currently building a Universal Windows Platform app, using an Azure database. Think all Microsoft stuff.
I created a mobile service and database through the official manage.windowsazure site. There I got 3 steps to follow, in order to add Azure :
Download a personalized Mobile Service project and add it to your project
Connect app and store data in it:
Add WindowsAzure.MobileServices Nuget Package to the project.
Add a public MobileServiceClient variable to app.xaml.cs
Add a sample ToDoItem class to your project
Use the Mobile Services client library to store data in the mobile service
Publish app to the cloud
Now, I downloaded that starter project and put it in one of the UWP's sub folders, cause it has to be incorporated in Visual Studio Online's version control, when I commit the whole thing. Screenshot of the folder structure is here, in case it's important: http://i.imgur.com/91K7Ehq.png
Then I added the WindowsAzure.MobileServices package to both my project and the add-on Service project, just to be sure. I also added that variable, no problem. Though I didn't add that ToDoItem class, nor store any data already, since it wasn't necessary yet. Ditto for the publishing.
Now the problem: When I try to build the project or open any of the Service files, I get a huge load of errors:
http://i.imgur.com/yuPSKzf.png
http://i.imgur.com/PtZEiZG.png
Does anyone know where I went wrong? Did I forget something important? Do I have to add one project as reference to another? Or add another reference to the Service project?
I ended up solving it. I downloaded the entire project from Azure and modified that to my needs. So basically remake the whole project.
I can't enter a webapp name when I create a new project, as well as after creating the project. I still cant publish to Azure because of the same reason.
I've tried the following available tutorials online but still the same. Both of my VS and Azure's accounts are the same.
This is how it looks like.
Try a workaround instead. Create the webapp in Azure portal. Then publish it again and choose the existing webapp.
I'm starting an ASP.net web project that will be hosted on Azure, but I'm not certain whether to develop the project as a regular ASP.net application and deploy it as a Web Site on Azure, or to develop it as a Cloud Application with a Web Role.
The project's nature is that of a web site (simple database back-end), but the question is one of deployment. We aim to build versions of the application and then deploy to staging and production environments, meaning the output of a build should result in a single package (similar to what's described in msdn).
There's plenty of information on how to create a service package to publish a cloud service, but articles on publishing a web site to azure follow a 'web deployment' scenario, where deployment is done via Visual Studio (subscription file from Azure etc).
Is there a way to deploy a web site to azure as a package? Or are tools like Visual Studio needed for a web deploy? If so, then is composing the project as a Cloud service with only a web role the correct choice?
I posted a comment under the question, regarding differences between Cloud Service & Web Site, but to answer your question about packaging: Cloud Services & Web Sites take two different approaches to deployment, and there's not really "works for both" packaging:
Web Sites are designed to accept your code deployment from either a source code repository. The idea is that you have a labeled version of your code, and push it out from TFS, git, Bitbucket, etc. You can also push your code up with ftp, or drop it into a dropbox folder. Because Web Sites run in IIS, and because you don't have any control over the VM farm running your Web Sites, you cannot push up startup scripts as you can with Cloud Services; you cannot install registry updates, COM objects, msi's...
Cloud Services are designed around a stateless VM model. Every time you scale out (add instances), a baseline Windows Server VM is spun up, and the contents of your deployment package is copied to the new VM instance and executed. This includes startup scripts, installers, etc. Since you have admin-level access to each VM, you can configure it as you need to, from your startup scripts / OnStart(). Definitions for each role are combined into a single deployment package. To update one or more roles, you need to redeploy the package.
Web Sites have no tooling pre-requisites, while Cloud Services require Visual Studio or Eclipse to help you manage the deployment package. You can also use PowerShell and Visual Studio command line tools to build the package, as #Ben Robinson mentioned in the comments above. You can also use PowerShell to create and administer Web Sites. Both Cloud Services and Web Sites provide Staging and Production slots.
You can't push a deployment package to Web Sites.
David's answer does a great job covering the Cloud Services option. However, I believe the Azure Website option is well-suited to your needs. You don't have to deploy using Visual Studio. Instead, you can create a publish profile in Visual Studio that creates a Web Deploy Package which is simply a ZIP file that can be published at a later time using command-line tools, no Visual Studio required. It also generates a .deploy.cmd file that you can run to deploy to a remote server, and a SetParameters.xml file with parameters such as connection string that you can modify for your target deployment environment. The .deploy.cmd file calls msdeploy.exe which does the actual deployment.
See this for more details on Web Deploy command-line deployment. There's also a ton of information on MSDeploy and its package system on Sayed Ibrahim Hashimi's blog.
If you want to be able to change files directly in the web application then it is best to use an Azure Web App, because you can access those through FTP.
However an Azure Cloud Service does not provide FTP Access, at least not a useful one that would allow you to use an FTP Client to upload files. A Cloud Service is where you do not want to be bothered too much with much of the details of hosting a web application. While an Azure Web App does much of the same thing, it also allows you to have FTP access and direct access to the files post-deployment.