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.
Related
I'm trying to understand how .NET Angular with typescript fits together with NodeJS (solution created using Microsoft Visual Studio).
If the endpoints are defined in typescript, and if NodeJS is needed to run typescript, how can the solution run without NodeJS installed? As per threads like: https://groups.google.com/g/angular/c/UjgOvDu0ads NodeJS is not necessary at runtime...
e.g. IIS can host the webservice that has those endpoints using https://levelup.gitconnected.com/how-to-deploy-angular-app-to-an-iis-web-server-complete-setup-337997486423
also see
https://www.codeproject.com/Articles/831752/JavaScript-for-Windows-server-side
We build our web app with Azure DevOps pipelines and deploy into Azure with an Azure DevOps release. I think today netcore got updated to netcore 3.1.4 on our build agent. But now our Azure DevOps deployment fails, because the netcore 3.1.4 runtime is not yet installed on our app service in Azure.
The error message we are getting:
Could not find 'aspnetcorev2_inprocess.dll'. Exception message:
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.4' was not found.
- The following frameworks were found:
2.2.8 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.0.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.1 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
You can resolve the problem by installing the specified framework and/or SDK.
This makes sense and can happen, but what is the best way to go about fixing this?
I could fix my build to a specific netcore version. But I don't like this, because we do want to keep updating to newer versions, but we don't want a version that is not available in Azure app service.
Am I correct in thinking that we would have to install our services self contained, because otherwise we could get into this issue more often when Azure DevOps is faster with installing patches than Azure?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
I just need some guidance in what is the best approach to fix this issue?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
AFAIK, there is no such a way to force update Azure app service to the new netcore 3.1.4.
We could keep track on the latest releases on the https://aspnetcoreon.azurewebsites.net/, but we could not update it at this moment.
To resolve this issue, we recommend that you publish your app as self-contained produces an application, which includes the .NET Core runtime and libraries, and your application and its dependencies. Users of the application can run it on a machine that doesn't have the .NET Core runtime installed.
Publishing your app as self-contained produces a platform-specific executable. The output publishing folder contains all components of the app, including the .NET Core libraries and target runtime. The app is isolated from other .NET Core apps and doesn't use a locally installed shared runtime. The user of your app isn't required to download and install .NET Core.
You could check this document .NET Core application publishing overview for some more details.
Hope this helps.
If you want version of netcore to be automatically updated as an updated version is available, building our service as self-container seems like a good option: no need to have anything installed on the machine running (ie the version on Azure DevOps and Azure Web App don't have to match).
The main downside of this approach is that the build is going to less deterministic: running your build twice with on the same commit might create different binaries depending on what is currently install on the build agent. if you want to know more, here is an interesting post arguing about why deterministic build is important.
To keep the build determinitic, you can use the Use .Net Core task at the beginning of the build (that will make sure that the desired version of the dotnet sdk is on the agent). You could also add a global.json in your repository to lock for both the build on your dev box and in Azure Dev Ops.
This is a common topic of discussion, and you can find a lot of blogs advocating one or another side.
There were big discussions started when Microsoft released LTS net core 3.1 and it took some time before Azure start supporting the 3.1 runtime as well.
You could find a lot of blogs strongly suggesting to deploy your web apps as self-contained (runtime is ~100MB in size) and cut loose the dependency towards Microsoft supporting the latest runtime. While others advocate that the applications should remain as light weight as possible and the runtime should be set in the pipeline. But that is still up on you. I, myself prefer to deploy self-contained apps after my bad experience with net-core 3.1.
There is no established best practice.
In the past , I've run into the same situation, you can fix this by manually setting the value from RunTime Stack drop down. If you manually update the build processes .yml file
RuntimeStack: 'DOTNETCORE|3.1'
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.
We realized that in our development team we have inconsistent Spotify versions. One part has 0.8.8 whereas the other part is having the old version - 0.8.5. Spotify is not upgrading for the accounts with the old version. However, apparently there are changes to the Spotify API, so that our app runs on 0.8.5 but not on 0.8.8. How can the other developers update to 0.8.8 as well?
The current production Spotify API framework should be the latest, regardless of the client version.
Right now it's ver. 0.2.8.
Remember that you need to declare your framework dependencies inside your manifest file. You can read more about it here:
https://developer.spotify.com/technologies/apps/guidelines/integration/#frameworks
0.8.5 is still the current live client, while 0.8.8 is gradually rolling out to a few users.
There is a preview API which depends on the bridge changes made in 0.8.8, but it shouldn't be used for production yet.
https://developer.spotify.com/technologies/apps/preview/
Can you run version 0.2.3 and 1.0.0 of the Spotify apps api at the same time in the same app? This would be really really helpfull for me during the development process in order to migrate our current Spotify-app from 0.2.3 to the new 1.0.0 api.
I am sorry but that it's not possible. The API version that your app uses is defined in the Dependencies section of your manifest.json file.
You can create a copy of your app, changing its BundleIdentifier, and try to isolate the code that is depending on the Spotify API, modularize it and port it step by step.