I am using Windows 10 and and dotnet 2.2. When I install a tool like this:
dotnet tool install -g mydotnet-tool
Where does dotnet put this tool? I know you can specify the path on installing a tool but I am looking for the default global dotnet tool path.
According to the docs, the default global installation paths are:
Windows - %USERPROFILE%\.dotnet\tools
Linux/macOS - $HOME/.dotnet/tools
In Windows, this means the full path will be something like:
C:\Users\[User]\.dotnet\tools
Global Tools
According to the docs, the default global installation paths are:
Windows: %USERPROFILE%\.dotnet\tools
Linux/macOS: $HOME/.dotnet/tools
In Windows, this means the full path will be something like:
C:\Users\[User]\.dotnet\tools
Local Tools
Local tools are stored in the global NuGet package folder.
Windows: %USERPROFILE%\.nuget\packages
Mac/Linux: ~/.nuget/packages
In Windows, this means the full path will be something like:
C:\Users\[User]\.nuget\packages
Related
I have installed the dotnet-ef and a number of other packages but for some reason, I can't use them.
I added $HOME/.dotnet/tools as shown here:
https://learn.microsoft.com/en-us/dotnet/core/tools/troubleshoot-usage-issues
but running dotnet tool list still shows no packages.
Please note that dotnet tool list command checks for local tools by default. Try dotnet tools list -g to look for globally installed tools. Make sure your PATH contains the global tools folder location before running the installed tool. You can check your PATH by running echo $PATH. You can also check globally installed tools by running dotnet tool list --tool-path $HOME/.dotnet/tools. Following steps work for me:
dotnet tool install --global dotnet-ef
export PATH="$PATH:$HOME/.dotnet/tools"
dotnet tool list -g
dotnet-ef
HTH
I am building the Visual Studio Code from the source checked out from the git repository:
git clone https://github.com/microsoft/vscode
I am building using:
export NODE_OPTIONS=--max_old_space_size=2048
./scripts/npm.sh install --arch=armhf
./scripts/code.sh
I am using node 10.16.3 on a Raspberry PI 4, using Raspbian buster
There were no errors during build.
The installation downloads a precompiled version of electron on the first run.
However each time I try and run code, it starts but with an error:
[storage state.vscdb] open(): Unable to open DB due to Error: Cannot find module '../build/Release/sqlite
If I look in node_modules/vscode-sqlite3/build/Release/
I can see:
sqlite3.a
sqlite.a
It is unclear to me why electron/vscode cannot find this library. I would be greatful for any pointers on how to tell the runtime where to look for the modules.
On inspecting the build scripts and after many painful experiments, I've found and solved the 2 problems leading to this error.
The fact that .a static libraries are left behind hinted that some settings in the binding.gyp, config.gpy and/or makefiles are wrong, as Native Node Modules are normally dynamic libraries with an .node extension. One conditional line in the binding.gyp file under vscode-sqlite3 seems to the the culprit:
...
["target_arch=='arm'", {"type": "static_library"}]
...
Disable that line (by removing it or changing 'arm' to something else) and then run:
node-gyp configure
to regenerate the config.gpy file(s) under the build directory. Then build the module with:
node-gyp build
A sqlite.node will be generated in build/Release.
Unfortunately, the latest electron ABI version rarely matches that of the Node.js version. In my configuration, the electron ABI version is 72 (v6.0.12) but the latest stable Node version is for ABI 64. Therefore we have to do an electron-rebuild to update the sqlite.node to match the electron version.
To do this, you would have to first install electron-rebuild (yarn add electron-rebuild) then run electron-rebuild by giving supplying explicitly the version number of the electron binary that vscode downloaded:
electron-rebuild -v 6.0.12 -m /home/dev/vscode -o vscode-sqlite3
Of course you would have to state the version number of your particular version of electron you are building for.
(Please look up electron-rebuild --help for the meaning of the options. It takes a while to rebuild the binary module...)
The resulting sqlite.node can then be moved into the build/Release/. directory under the vscode project directory. Voila, we have a working latest version VS-Code for Raspbian!
I am trying to install a NuGet tools package inside an Alpine Docker container.
In Windows I would do the following -
nuget install SomeToolPackage
Doing so would result in a new set of directories like -
tools\netcoreapp2.1\SomeTool.dll
tools\netcoreapp2.1\* many other files
Question
What is the equivalent in for Linux. I am aware that some people are using Mono to run the Windows nuget.exe file.
I can also use wget and unzip.
I hope there is a better way using the tools from Microsoft.
The path going forward is to use dotnet tools (see also dotnet core global tools overview and creating a global tool). However, it's not a 1:1 mapping with nuget.exe install, as the package must be authored as a tool, whereas nuget install allows you to "install" any package.
Need to build a version of grpc with just static libs. Without plugin support and not building shared libraries. I cant seem to find a way. I'm also using a custom version of SSL and system zlib and have set the required
cmake .. -DCMAKE_BUILD_TYPE=Release -DgRPC_ZLIB_PROVIDER=package -DgRPC_SSL_PROVIDER=package -DOPENSSL_ROOT_DIR=<path to my ssl root>
Running on CentOS7 although this seems it should be a platform agnostic request/feature.
I dont need to do a make install as we check the binaries into our source tree so that the rest of our project will build and then link this static version of grpc and our custom ssl.
First and foremost, I'm trying to find the answer to a minimal C/C++ protobuf/grpc setup myself for a container build. I don't need all the support for all the other languages.
Secondly, checking your binaries into a source code repository? Really? You should be using something like bintray, artifactory, nexus etc. for that.
I had a similar question, though in my case I was trying to figure out how to do it in Windows. I wanted static libs but linked against dynamic runtime (/MD versus /MT.)
Tried to build gRPC myself. Eventually went the vcpkg route, which is so much better, especially when working with open source software in Windows!
However, on Windows vcpkg only builds 2 things by default: fully dynamic, or fully static. What I wanted was static libs linked against the dynamic runtime. To do that you have to create your own triplet. Here is how I did it:
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
bootstrap-vcpkg.bat
vcpkg integrate install
vcpkg integrate powershell
cd triplets
copy x64-windows.cmake x64-windows-mixed.cmake
Edit x64-windows-mixed.cmake so it contains these 3 lines:
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)
Then install and build both gRPC & protobufs:
cd ..
vcpkg.exe install grpc:x64-windows-mixed protobuf:x64-windows-mixed
If you are on Linux, then it looks like the default triplet may already be correct, since the x64-linux.cmake file defaults to:
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)
set(VCPKG_CMAKE_SYSTEM_NAME Linux)
Once you have everything built in vcpkg, you'll want to customize your own project's cmake file to look for the correct software, and link in the right .a files. I didn't try this on linux, but in Windows my project includes the following:
FIND_PACKAGE ( protobuf CONFIG REQUIRED )
FIND_PACKAGE ( c-ares CONFIG REQUIRED )
FIND_PACKAGE ( gRPC CONFIG REQUIRED )
FIND_PACKAGE ( ZLIB REQUIRED )
FIND_PACKAGE ( OpenSSL REQUIRED )
FIND_PACKAGE ( Threads REQUIRED )
To ensure I have the correct vcpkg include directory, I used this:
FIND_PATH ( SYSTEM_INCLUDE_DIR zlib.h )
INCLUDE_DIRECTORIES ( ${SYSTEM_INCLUDE_DIR} )
And then when linking, I make sure TARGET_LINK_LIBRARIES includes the following:
PUBLIC Threads::Threads
protobuf::libprotoc protobuf::libprotobuf protobuf::libprotobuf-lite
gRPC::gpr gRPC::grpc gRPC::grpc++ gRPC::grpc_cronet
c-ares::cares c-ares::cares_static
OpenSSL::SSL OpenSSL::Crypto
ZLIB::ZLIB )
When you first run cmake, remember to specify the toolchain file and prefix path. In my case on Windows I also had to tell it which triplet to use. The command looked like this:
mkdir build
cd build
cmake \
-DCMAKE_BUILD_TYPE=Debug \
-DCMAKE_TOOLCHAIN_FILE=/src/vcpkg/scripts/buildsystems/vcpkg.cmake \
-DCMAKE_PREFIX_PATH=/src/vcpkg/installed/x64-windows-mixed \
-DVCPKG_TARGET_TRIPLET=x64-windows-mixed \
..
(That last command cannot be broken up that way in Windows, I only did that here to help show the parameters I'm passing in.)
I used 4.7.2 for the past months. Now I downloaded 4.7.3. Now I am searching to type "configure -static". But I don't know where the hell "the qt path". Can anybody shed a light on this issue.
Download the source package here. Download and install your favorite perl distribution. I must warn you that Strawberry perl comes with its own toolchain and that may get used instead of the MinGW you downloaded. Use ActivePerl if you don't want any trouble, or build it yourself.
Unzip it to say, C:\Qt-source so that there is a configure.exe in C:\Qt-source
Open the toolchain's command prompt
a) If you're using the Visual Studio compiler, search in the "start" menu for a CMD shortcut in the Visual Studio folder. The Windows SDK also has this shortcut.
b) If you're using MinGW, either use the accompanying mingwvars.cmd, or open a command prompt, (Run->"cmd.exe") and type set PATH=C:\path\to\mingw\bin;%PATH%. Try gcc -v to see if it can be found.
Make a build directory, preferable something like C:\Qt. Do set QTPATH=C:\Qt and set PATH=C:\Qt\bin;%PATH% and cd C:\Qt, and type:
..\Qt-source\configure -static
After configure finishes, you'll either have to type nmake (Visual Studio) or mingw32-make.
Go do something else, because it will take a while.
Some tips that result from my experience, and add a bit more to the answer of rubenv:
Pass the install directory as a flag of the configure; be sure to choose a different directory from the one where you have stored a non-static version of Qt!
Some modules will likely cause you troubles when compiling statically because you need to resolve the dependencies statically; one example is webkit, so if you don't need it be sure to disable it
It is generally not a good idea to build the debug symbols into a static library, so I normally debug with the dynamic version, and use the static Qt to generate releases only.
Therefore, my configure looks something like this:
configure -static -prefix C:\Qt\4.8.6_static -no-webkit -release