I'm trying to deploy the following sample node application to an Azure website:
var http = require('http');
var port = process.env.port || 1337;
http.createServer(function (req, res) {
res.writeHead(200, { 'Content-Type': 'text/html' });
try {
var canvasModule = require('canvas'),
canvas = new canvasModule(200, 200),
ctx = canvas.getContext('2d');
ctx.rotate(0.5);
ctx.font = '30px Impact';
var message = "Hello World";
ctx.fillText(message, 40, 40);
ctx.strokeRect(30, 5, 160, 50);
res.end('<html><img src="' + canvas.toDataURL() + '" /></html>');
} catch (e) {
res.end('Error: ' + e);
}
}).listen(port);
The tricky part is that I'm using a node module called "canvas" that needs to be compiled at install time using node-gyp.
According to this Microsoft page native modules are not supported on Azure Web-sites and the compiled version of the module should be copied to Azure for the app to work properly:
Native Modules
While most modules are simply plain-text JavaScript files, some
modules are platform-specific binary images. These modules are
compiled at install time, usually by using Python and node-gyp. One
specific limitation of Azure Web Sites is that while it natively
understands how to install modules specified in a package.json or
npm-shrinkwrap.json file, it does not provide Python or node-gyp and
cannot build native modules.
Since Azure Cloud Services rely on the node_modules folder being
deployed as part of the application, any native module included as
part of the installed modules should work in a cloud service as long
as it was installed and compiled on a Windows development system.
Native modules are not supported with Azure Web Sites. Some modules
such as JSDOM and MongoDB have optional native dependencies, and will
work with applications hosted in Azure Web Sites.
I deployed everything to Azure (using the publishing Wizard) and all the files were sent to Azure (apparently at least), including the compiled modules. When running the site on Azure I obtain the following exception:
Error: The specified module could not be found.
D:\home\site\wwwroot\node_modules\canvas\build\Release\canvas.node
But that file is in-fact deployed on the server:
Creating a VM would obviously be an option but I would prefer to use web-sites. Anyone has any idea that I can try out?
The error message ""The specified module could not be found" is a bit misleading. It can mean one or more dependent dlls are not found.
I assumed you used the build instruction in Windows. If you built canvas against the GTK2 zip file in the instruction, you can copy %GTKDIR%\bin\freetype6.dll to %YourApp%\node_modules\canvas\build\Release. This dll is not copied during the build process. You would need to do this deploying to a VM as well. Or you can build canvas against the Windows GTK3 bundle.
And unfortunately even after you have all the dll, the sandbox of Azure Websites seems to prevent canvas from running. Hopefully it would be enabled in the near future.
Alright got this working today!
You need to deploy your node_modules directory, in addition to that you need to copy all the contents gtk/bin to the root of your application, which makes it a bit messy, but it works. I imagine you could change the path to look elsewhere but I needed to get the app running so I didn't investigate any further.
That last line in #mtian's answser is key. You can spend time getting it to deploy but ultimately the Azure Website VMs lack the GDI+ APIs that node-canvas relies on to execute (presumably blocked for security considerations). If you want node-canvas on Azure, you can't use Azure Websites and will instead need to setup and manage your own VMs.
Related
I have written a code to save all the slides in a presentation as jpeg. It works well in visual studio locally on my system, but when I deploy it on Azure app service, I get 500 internal server error.
IIS received the request; however, an internal error occurred during the processing of the request. The root cause of this error depends on which module handles the request and what was happening in the worker process when this error occurred. IIS was not able to access the web.config file for the Web site or application. This can occur if the NTFS permissions are set incorrectly. IIS was not able to process configuration for the Web site or application. The authenticated user does not have permission to use this DLL. The request is mapped to a managed handler but the .NET Extensibility Feature is not installed.
The code:
using pptd = NetOffice.PowerPointApi;
using NetOffice.PowerPointApi.Enums;
using NetOffice.OfficeApi.Enums;
public void genThumbnails(string originalfileName,string renamedFilename, string dirPath)
{
pptd.Application pptApplication = new pptd.Application();
pptd.Presentation pptPresentation = pptApplication.Presentations.Open(dirPath + renamedFilename, MsoTriState.msoFalse, MsoTriState.msoFalse, MsoTriState.msoFalse);
int i = 0;
foreach (pptd.Slide pptSlide in pptPresentation.Slides)
{
pptSlide.Export(dirPath + originalfileName + "_slide" + i + ".jpg", "jpg", 1280, 720);
i++;
}
pptPresentation.Close();
}
What is the mistake that I am doing? Does NetOffice package also need MS Office installed on the server like Office.Interop?
The standard windows and Linux web apps used blessed operating system images. As part of the PaaS design, customers are limited as to what they can run as there is no MS Office inter-op present and also because Azure Web Apps is a sandbox.
My suggestion would be to create a container image that has the necessary dependencies that you need and then deploy your custom container to an Azure Web App Container.
I am creating an Electron app and am using electron-builder to package and build the app. Users are able to make plugins for the app (plugins can be node modules with their own dependencies and such). Everything is working fine except the part of the app for exposing the app's API to the plugin.
I created a module in the app for handling the plugins "Plugin-handler" that imports the plugin and also exposes the API to the plugin (The app's API is just a set of functions and it is bundled with the app).
The dilemma is that the user should be able to place a plugin anywhere on their machine and the app does not know the path before the build. Consequently, I excluded the "plugin-handler" module in the Electron-builder config so it does not bundle with the Webpack. Now I need to find the right way to expose the API to the plugin.
Here is how I am doing it now, to load the plugins and passing the API:
// In the Plugin-handler module
const API = require('api')
const plugin = require('path-to-plugin')( API )
path-to-plugin is added by the user in the app when they import their plugin.
As seen above, currently I pass the API to the plugin as an argument, which is not ideal, instead, I need a way to exposing the API module (or any other module that is bundled in the APP) to the plugin so users can access it in their plugin like below:
// In the plugin
const { arg1, arg2,... } = require('api')
I've seen apps doing this, and allowing users to access their API in their plugins, but since I am new to all this, I may be doing things wrong, so please do be kind, and thank you for the help!
I drew a simple chart for better portraying the question:
I am writing services with Serverless Framework & Azure Functions. Examples out there are very simple. But when I try to take a step further, I run into problem. Currently learning from AWS Lambda and then trying to implement it on Azure Functions.
The goal of doing so is:
1) Implement functions as es6 classes and then building the project with webpack.
2) Find a right project structure, which makes more sense.
3) Follow SoC pattern.
I have created a github project https://github.com/GeekOnGadgets/serverless-azure-settings and when I try to build this project serverless package it creates .serverless folder and inside it there is .zip file (the compiled version). Which I understand gets deployed to azure when you run serverless deploy. But when I check on Azure the function is just development code and not the compiled one (please refer to the code below).
Can someone please help with this. Any suggestions is appreciated.
import Settings from './src/Settings/Settings'
module.exports.settings = (event, context, callback) => {
let settings = new Settings();
const response = {
statusCode: 200,
headers: {
"Content-Type": "application/json"
},
body: JSON.stringify(settings.dev()),
};
callback(null, response);
}
Indeed javascript azure functions run on nodejs so commonjs modules are the natural format. Node also natively supports much of ES6, though the Functions version of node might not be the latest.
however, there is a current speed issue with loading all the dependencies in node_modules. This is due to file access so a workaround exists to bundle everything into a single script which package.json -> main points to.
I cant comment on how that fits in with serverless, but perhaps this will help clarify.
As far as I know, Node.js still does not support import/export ES6 syntax for modules. See also here.
Try a new deploy changing from
import Settings from './src/Settings/Settings'
to
const Settings = require('./src/Settings/Settings')
I am working with Electron and Node.js. We have developed an application that works fine on windows and as a requirement had to package it for mac os. I packaged the application using electron-packager, the packaging process completes and package is generated. Double clicking it throws an error that permission denied for mkdir, as i am using node localstorage to maintain some settings on the user's local machine. somehow mac doesn't local storage to create folder in the root of the application. Any help in this matter will be great. Thanks
First off, is the code in question in the main process or in a renderer process? If it is the latter, you don't need to use 'node-localstorage', because you can use the renderer's native LocalStorage. If you are in the main process, then you need to provide your own storage strategy so using 'node-localstorage' is a viable option.
In any case, you need to carefully consider where to store the data; for starters, let's look at where Electron's renderer processes would store its LocalStorage data: this differs based on the OS, but you can get and set the paths using the app module -- the path in question is userData, which on OS X would default to ~/Library/Application Support/<App Name>. Electron uses that folder to persist cookies, caches, LocalStorage etc. so I would suggest using that folder as well. (Otherwise, refer to XDG defaults for good defaults)
What your example above was trying to do is store your 'errorLogDb' in the current working directory, which might depend on your OS, where your App is installed, how you executed it, etc.
Finally, it's a good idea to differentiate between your 'production' app and your app during development and testing, because you might not want to use the same storage folders for every environment. In any case, just writing to './errorLogDb' is likely to cause lots of headaches so I'd be thankful for the permission denied error.
this strategy worked for me:
const { LocalStorage } = require('node-localstorage');
let ls;
mb.on('ready', () => {
let prefsPath = mb.app.getPath('userData') + '/prefs';
ls = new LocalStorage(prefsPath);
loadPrefs();
});
mb.on('after-create-window', () => { /* ls... */ }
exports.togglePref = () => { /* ls... */ }
How can I add JSON or TOML files in an Electron app for deployment? The following code works in development environment, but does not after packaging by electron-packager.
var presets = toml.parse(fs.readFileSync('presets.toml','utf8'));
According to the guide that took me way too long to find, the Electron team patched the fs module to provide a "virtual file system" under the root (/).
That means your file is accessible at fs.readFileSync('/presets.toml'); (notice the forward slash).
I went crazy till I found this one.
The problem is not adding it because it's already added.
Problem is finding base path after packaging.
So here it is:
const { app } = window.require('electron').remote;;
console.log(app.getAppPath());
Also, as you can see, if you're using React you need to use window.require instead of regular require (it throws nasty error otherwise).
Found about this here:
https://github.com/electron/electron/issues/3204#issuecomment-151000897