So this is really strange.
Local dev environment :
OS : Win x64
Node version : 8.x (LTS)
The project does not build with the AOT flag. It throws "xyz" does not exist in object of type {}.The fix to this is very obvious.
Remote env:
OS : linux x64
Node version : 6.x (LTS)
The project builds successfully without the above-mentioned compiler errors!
Both environments have the same CLI version. The only difference being the node version, local being higher.
Can anyone shed some light on this? Does the compiler behave differently on node versions higher than 6.x LTS?
Related
I just started getting this error today on my Linux system, building a net6 solution on Rider - It builds but won't run. I've tried upgrading my version of Microsoft.Data.SqlClient from nuget but that's made no difference. This was working fine last week.
There are a couple of things I've done that may have broken it - I got mono working over the weekend to try and get some legacy NETFramework code building for another project, for one. The other was a global update of ef tools dotnet tool update --global dotnet-ef as I had the 5.x tools version installed.
My OS has multiple runtimes installed...
dotnet --list-runtimes
Microsoft.AspNetCore.App 6.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.13 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
The app builds to target 6.0.
I'm a bit lost as to where to start trying to find problems - I#ve read about the netstandard2.0 version of this library being a kind of breaking stub, but the Assembly Explorer in Rider tells me that the version of Microsoft.Data.SqlClient in my bin directory is net6. I'm not sure what I should be seeing in the runtimes directory in here - I have a unix runtime shown there but NOT a linux specific runtime - Is this a red herring or am I on to something?
I've reverted the dotnet-ef tool by uninstalling it and running dotnet tool install --global dotnet-ef --version 5.0.0 - This hasn't helped at all.
TLDR: I think this is a bug in the .NET builds of Manjaro Linux. When you downloaded Microsoft's builds of .NET, it didn't have this bug and worked correctly.
This is what the OS says about itself:
# cat /etc/os-release
NAME="Manjaro Linux"
PRETTY_NAME="Manjaro Linux"
ID=manjaro
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="32;1;24;144;200"
HOME_URL="https://manjaro.org/"
DOCUMENTATION_URL="https://wiki.manjaro.org/"
SUPPORT_URL="https://forum.manjaro.org/"
BUG_REPORT_URL="https://docs.manjaro.org/reporting-bugs/"
PRIVACY_POLICY_URL="https://manjaro.org/privacy-policy/"
LOGO=manjarolinux
And this is what .NET thinks about your OS:
sh-5.1# dotnet --info
.NET SDK (reflecting any global.json):
Version: 6.0.113
Commit: 4a23b50f97
Runtime Environment:
OS Name: manjaro
OS Version:
OS Platform: Linux
RID: arch-x64
Base Path: /usr/share/dotnet/sdk/6.0.113/
...
Do you see how confused .NET is about whether this is Arch Linux or Manjaro?
.NET has a fallback graph that tells it which assets from another OS it can use:
# jq '.runtimes' /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.13/Microsoft.NETCore.App.deps.json
{
"arch-x64": [
"arch",
"linux-x64",
"linux",
"unix-x64",
"unix",
"any",
"base"
]
}
But that only contains arch-x64 (that is, Arch Linux), not manjaro-x64.
If you try and build/run your application with the environment variable COREHOST_TRACE, you can see output like this:
HostRID is manjaro-x64
Falling back to base HostRID: linux-x64
So it finally decides this OS is Manjaro, but then has no idea that Manjaro is compatible with everything listed in the fallback graph above. It just falls back to Linux.
Unfortunately, Microsoft.Data.SqlClient is built for either Windows (windows) or for Unix (unix). .NET can't find a linux variant. It finally uses the fallback version of Microsoft.Data.SqlClient.dll, one that just prints errors instead of doing anything useful.
It seems that the issue was, in part, related to having 2 6.x framework versions installed, or with 6.0.13 - I'd tried installing the 6.x packages from the Manjaro repositories over the weekend to replace the script installs.
Dani's comment above pointed me in the right direction (https://github.com/dotnet/SqlClient/issues/1643#issuecomment-1265104713) - There's something odd going on here.
I removed them all and installed again using the .dotnet-install.sh script - that just did nothing, so I copied the 6.0.0 install from a backup folder (mv .old FTW) and it all fell into place again.
Whether this is an issue with 6.0.13 or with having multiples I'm not sure.
I'm on a Microsoft Surface Pro X (it features Windows 10 Home on ARM 64-bit processor) trying to install Node.js. I've decided to use NVM for Windows. I can successfully install and get NVM for Windows running correctly. To my understanding, I'm able to install different versions of Node (i.e. 16.16.0 and 16.13.1, for example, both LTS) as shown in below graphic. But when I try to run Node, I get the error "This version of C:\Program Files\Nodejs\node.exe is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher."
I am not clear on the why this is happening. Am I not downloading a version of Node that is compatible on my ARM 64-bit processor? I've read through several closed issues on the GitHub page but I haven't encountered someone bringing up this same error. I'm pretty confident it does NOT have to do with the integrity of my symlinks too, or my system environment variables. See below:
Your help and insight is appreciated. Thanks.
The Omnis docs state "node.js is embedded into Omnis Studio".
I understand I can check node.js version in terminal node -v, however this is the version on my machine itself.
How do I determine what version of node.js is bundled within Omnis Studio?
After installing it, you can go to the directory that contains Omnis' Node executable. On Windows, it may be:
C:\Program Files\Omnis Software\OS 10.2 31315\clientserver\server\remotedebug
Then you can run node -v from that directory. The latest version looks to be 16.6.1. (This may well be a different version from the global Node on your personal machine - for example, my global Node version is 14, which I get when running node -v elsewhere, outside of that directory)
The latest release notes also say that the Node version in Macs is also 16.6.1:
The version of Node.js released with the macOS version of Studio 10.2 is now V16.6.1
which supports node running natively on macOS on M1 machines.
I am currently working on a jhipster project.
I had to encounter some difficulties with jhipster translation-not-found[error.url.not.found],
that I was able to solve and I would like to share the result of my research.
here is my problem in a few pictures.
After refreshing the page, the credentials no longer work
Infos :
jhipsterVersion: 6.10.5
applicationType: monolith
clientFramework: angularX
Environment and Tools
java version "11.0.12" 2021-07-20 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.12+8-LTS-237)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.12+8-LTS-237, mixed mode)
git version 2.15.0
node: v12.16.1
npm: 6.13.4
Docker version 20.10.7, build f0df350
docker-compose version 1.29.2, build 5becea4c
Resolution,
The problem is due to the high size of the headers at the FRONT (Angular) and BACKEND (Spring-boot) level.
1- FRONT correction :
Edit package.json (Edit the package.json file and add the following parameter On title webpack-dev-server and webpack : --max-http-header-size=102400000)
2- BACKEND correction :
Edit application.propertie files (application-dev.yml and application-prod.yml), add : server.max-http-header-size: 102400000
I humbly hope this helps you
Translator: Google translate
An issue similar to this post: node: could not initialize ICU (check NODE_ICU_DATA or --icu-data-dir parameters)
I get the same error message:"node: could not initialize ICU (check NODE_ICU_DATA or --icu-data-dir parameters" with the fresh node installation. It is a brand new computer with Windows 10 Pro system version 10.0.17763 Build 17763. I have tried installing version 10.16.0 LTS and version 12.6.0 current from node.js website. In both cases I have exactly the same error, does not matter if I run as admin or a normal user. I cannot use the solutions described above as npm will not run (same error). I have no idea what to do next.
I managed to sort it out. As it turns out, other software was using the environment variable: NODE_ICU_DATA. I have removed NODE_ICU_DATA variable, restarted computer and installed node again. It is working fine now.