I'm having trouble getting a nodejs app which relies on JSDom to work on Azure due to it depending on a native module - Contextify, I understand Azure does not provide compilation for native modules.
However according to Azure documentation
Since Windows 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.
It all works fine on my dev box as it's compiled during npm install, what I don't understand is why it isn't working on Azure as I am providing the compiled version? If it works on my windows dev box the compilation is clearly successful. I deploy to azure form a local git repository so I'm wondering if the compiled files are being left out when I commit?
UPDATE: the latest Azure release (specifically, the Mobile Services backend) supports arbitrary NPM modules - See the section on Mobile Services: NPM Module Support
From the JSDom docs on the npm:
Unfortunately, doing this kind of magic requires C++. And in Node.js, using C++ from JavaScript means using "native modules." Native modules are compiled at installation time so that they work precisely for your machine; that is, you don't download a contextify binary from npm, but instead build one locally after downloading the source from npm.
https://npmjs.org/package/jsdom#contextify
Since your "native modules" don't have the same signature as whatever machine in azure's "native module" would be signed, it doesn't load.
Related
I have an azure mobile app that is consumed by a Cordova app - this azure mobile app is built in node.js and is responsible for managing the push notifications for this Cordova app.
In this node app, I use mobileservices-sqlserver to register in the database the devices that will receive the push notifications, and I am having problems with this module compilation in node version 6.1.9 - actually any version higher than 0.8x.
Can I pre-compile this mobileservices-sqlserver to a newer node version, maybe using node-gyp? I couldnt find any instructions on how to do that.
Sorry if that is silly question, but I'm really new to node.js.
I've seen some similar issue here, but I'm not sure if it's the same.
Is this an old Mobile Services service? If so, check out the Mobile Apps Compatibility NPM, which replaces mobileservices-sqlserver with the msnodesqlv8 and will allow your service to work with modern versions of Express and Node.js.
If this is already a more modern Mobile App service, see also the mssql NPM for SQL Server data access.
I just upgraded my app to use the latest Microsoft.SqlServer.Types package v14 from v13. This resulted in an well-documented runtime error. The reason here would be missing native libraries:
Spatial types and functions are not available for this provider because the assembly 'Microsoft.SqlServer.Types' version 10 or higher could not be found
The Nuget package also contains the native DLLs that were missing, so I could theoretically copy them to my bin folder and load them through my code, but:
I didn't have to do that with my v13 binaries
When I deployed the updated project to Azure, it ran just fine.
My current assumption would be that I got the v13 binaries with my local SQL install, and on Azure, those binaries (both v13 / v14) are preinstalled.
However, when googling a bit about the issue, most developers have the opposite problem of things not working on Azure due to the missing libs, so I wonder whether not going the manual route might be dangerous with regards to Azure deployments. If anybody had some insight here, that would be awesome!
As far as I know, the azure web service install the SQL server SDK version is 9.0 - 13.0. So you need install 14.0 by yourself.
You could find the dll in the kudu console in your web service.
D:\Program Files (x86)\Microsoft SQL Server\130\SDK\Assemblies>
To open the kudu you could refer to below steps:
1.Find the Advanced Tools in DEVELOPMENT TOOLS click go.
2.Click dubug console's cmd.
3.Find the path.
Notice: You need firstly type cd.. to locate the root path.
You could find the Microsoft.SqlServer file as below:
I want to deploy my in-house UWP app only to selected Windows Phone 10 devices via a download link.
This already works for iOS and Android, but I have troubles with WinPhone 10.
On my development device, I can just download and install the created appxbundle file. However, it seems that the appxbundle does not include the dependencies (Microsoft.NET.CoreRuntime.1.0.appx, Microsoft.VCLibs.ARM.Debug.14.00.appx). Therefore the installation does not work on devices, which have never been used to develop the app (and therefore do not have the dependencies installed).
Is there a way to create a complete appxbundle which also installs the dependencies?
Building the app in release mode solved the problem.
The .NET native toolchain includes all the required dependencies into the executable and therefore the installation of the dependencies is not required.
I'm just starting out trying to integrate Ensime scala ide-support into vscode. I have pulled out some of the integration parts from my atom package https://github.com/ensime/ensime-atom into https://github.com/ensime/ensime-node.
However, when depending on this from vscode I get red squigglies that it can't be found:
However, code still build and runs just fine. I got worried. I found this:
Q: Can I use native Node.js modules with my extension?
A: A Visual Studio Code extension package contains all of its
dependencies. This means that if you develop your extension on Windows
and depend on a native Node.js module when you publish that extension,
the Windows compiled native dependency will be contained in your
extension. Users on OS X or Linux won't be able to use the extension.
The only way to make this work for now is to include binaries for all
four platforms of VS Code (Windows x86 and x64, Linux, OS X) in your
extension and have code that dynamically loads the right one.
What does this mean? I can't use fs, net, child_process and the like? Kindof need them all I think or does vscode provide all that through abstraction layers?
You do have the basic node modules (fs, etc) already included as part of the dependency of vscode itself.
Did you remember to include this module in your package.json file as a dependency?
A way to check this would be to clean your code, put it in a new folder, and run "npm install" - if everything then runs fine, you are good to go.
See this docs:
https://code.visualstudio.com/Docs/extensionAPI/extension-manifest
Be sure to also read up on the new extension authoring update in the latest version: https://code.visualstudio.com/Updates
We use TeamCity as our CI server (but I imagine this applies to any build server).
We have not installed the azure SDK on the build server and are able to build the projects which use the SDK using the workaround described here.
I now want the server to produce the packages for deployment to Azure, but when I run an MSBuild task to create the packages (as directed here) I get a strange error
error MSB4057: The target "WatGetTargetFrameworkDirectories" does not exist in the project.
which yields few useful google results.
Do I need to install the SDK? Or is this error related to something else?
WatGetTargetFrameworkDirectories is a target from AzureSDKs .targets file. Looks like your error related to Azure SDK.
Except it could be more subtle error related to not very good msbuild Azure Targets. For our own azure packaging we did need to call 2 targets "Clean;CorePublish", not just "Publish". Maybe this will also help you.
Side note: why you don't want to install AzureSDK on TeamCity BuildAgent? Build agents made exactly for that - to have frameworks you need for build. Also 1.6 and 1.7 AzureSDKs can be installed side-by-side.