I was having some problem running SonarQube plugin and SonarLint on Visual Studio Code.
After installing the former or both plugins, I tried to run (following the tutorial...) the command SonarQube Inject: Create global config with credentials to servers which ended up with the following message command 'sonarqube-inject.analyzeProject' not found.
On windows type: Ctrl-Shift-P and then write Sonar. The editor will show the options to use.
Problem is coming from the plugin binary not being executable by default (at least on my Ubuntu 16.04 / VSCode 1.14).
I just needed to make it executable:
cd ~/.vscode/extensions/silverbulleters.sonarqube-inject-1.3.0/tools/sonarlint-cli/bin/
chmod u+x sonarlint
Then, restart VSCode and run the command SonarQube Inject: Create global config with credentials to servers again and setup servers.
Related
I've been working with AWS lambdas for a few months. I was working with a lambda and it was fine at the end of the day. I came back to work on it the next day, and I can't get Visual Studio to even start the application using the Mock Lambda Test Tool.
I ended up creating an empty lambda that just returns the input (the standard project code that AWS gives you as a template) and that won't even run. I hit the play button to star the Mock Lambda Test Tool, it looks like it will run for a couple seconds, then it closes down. The command window does not even pop up.
This is the code from the template project.
public string FunctionHandler(string input, ILambdaContext context)
{
return input?.ToUpper();
}
This is all I get in the output window of VS:
The target process exited without raising a CoreCLR started event.
Ensure that the target process is configured to use .NET Core. This
may be expected if the target process did not run on .NET Core. The
program '[16700] dotnet-lambda-test-tool-2.1.exe: Program Trace' has
exited with code 0 (0x0). The program '[16700]
dotnet-lambda-test-tool-2.1.exe' has exited with code -2147450726
(0x8000809a).
I have tried re-installing the AWS toolkit, and also tried re-installing Visual Studio. This is an issue with VS 2017 and VS 2019. I just installed 2019 to see if that would fix the issue. Any help would be appreciated.
I came to this question having the very same issue. After installing AWS Toolkit I found that the lambda test tool was not installed and therefore I got the same error just as the OP. The only difference is that I was targeting .Net Core 3.1 and therefore I needed amazon.lambda.testool-3.1. However this answer should work for both scenarios.
Unfortunately I did not have the same luck as the OP of having a nice co-worker that could give me the files I needed. So, if this is also your case please continue reading.
In the official project site, which can be found here, there are the instructions to install the tools. It also says that installing the latest version of AWS Toolkit should be enough to have the tools installed (it was not in my case and probably in yours).
It says that in order to install the tools you should run the following commands:
dotnet tool install -g Amazon.Lambda.TestTool-3.1
or
dotnet tool install -g Amazon.Lambda.TestTool-2.1
depending on which tool you need.
However, running these commands fails with the following message:
The tool package could not be restored.
Tool 'amazon.lambda.testtool-2.1' failed to install. This failure may have been caused by:
* You are attempting to install a preview release and did not use the --version option to specify the version.
* A package by this name was found, but it was not a .NET Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.
For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool
And since the project is still in preview I just had to find the latest stable version in order to specify it in the command. For .net core 3.1 here is the nuget site, there I found version 0.10 to be the latest, so the command should look like:
dotnet tool install -g --version 0.10 Amazon.Lambda.TestTool-3.1
I have faced the same issue and when i tried to install dotnet-lambda-test-tool-3.1.exe using command prompt I got this issue:
Failed to create shell shim for tool 'amazon.lambda.testtool-3.1': Command 'dotnet-lambda-test-tool-3.1' conflicts with an existing command from another tool.
Tool 'amazon.lambda.testtool-3.1' failed to install.
And I did the following to fix issue
Deleted the dotnet-lamda-test-tool-3.1.exe from the installed folder (C:\Users%USERNAME%.dotnet\tools\dotnet-lambda-test-tool-3.1.exe)
Run dotnet tool install -g --version 0.10 Amazon.Lambda.TestTool-3.1 on cmd.
I have faced the same issue and got errors like "dotnet-lamda-test-tool-2.1.exe has exited with code.."
I did the following to fix the issue
Removed the dotnet-lamda-test-tool-2.1.exe from the installed folder
(C:\Users%USERNAME%.dotnet\tools\dotnet-lambda-test-tool-2.1.exe)
Removed the [amazon.lambda.testtool-2.1] folder as well
(C:\Users%USERNAME%.dotnet\tools\tools.store\amazon.lambda.testtool-2.1)
Installed dotnet tool from Developer command prompt using the command
[install -g Amazon.Lambda.TestTool-2.1]
Run the project. It is working
I have seen this issue many time on my system with dotnet-lambda-test-tool-6.0. Only one fix work for me
Remove dotnet-lambda-test-tool-6.0.exe from C:\Users\username.dotnet\tools
Open Command prompt from C:\Users\username.dotnet\tools
run command dotnet tool install -g Amazon.Lambda.TestTool-6.0
For anyone else that hits this same issue, it had to do with the the AWS toolkit install. I did not modify it, but somehow it was no longer working. I tried un-installing and re-installing, but it was still having issues running it. A co-worker sent me the exe and subdirectory that was setup on his machine under C:\Users\%user%.dotnet\tools. The exe is located in this directory, and there is another folder under .store for amazon.lambda.testtool-2.1. That directory had different folders and files than what I was able to install. So I copied in what he had and it worked. There might be a profile file associated to the tools install that points to these folders and files that might need to be modified. Since I was able to fix it with this, I didnt look any further into that.
I had the same issue with my .NET 6.0 lambda project. I installed the tool by executing dotnet tool install --global Amazon.Lambda.TestTool-6.0 --version 0.12.6 as suggested on https://www.nuget.org/packages/Amazon.Lambda.TestTool-6.0
Just ensure it is installed at %USERPROFILE%\.dotnet\tools\dotnet-lambda-test-tool-6.0.exe
I got the same issue with VS2019 with lambda design in 3.1 version and in Output window getting error
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
Then checked the folder having multiple version of lambda-test-tool in path
C:\Users{username}.dotnet\tools
I removed all the lambda-test-tool and installed the required tool only with version 3.1 by command in developer command prompt:
dotnet tool install -g --version 0.10 Amazon.Lambda.TestTool-3.1
Then I can able to debug the lambda
I am attempting the installation of ESP-IDF toolchain for windows with the installer from here
However the installation fails with the exit-code=128.
Since I am a newbie I am not sure if I am missing something assuming the installer will take care of installation of all the dependencies
I am attaching the logs here for the reference
System Spec:
1.OS : windows 10
2. Processor : I7-8th Gen
If you have installed git and python (I think you do if you tried to use the windows installer beforehand), you can try to install the toolchain from the terminal.
Open a CMD (Win+R, cmd, Intro)
Create a new folder (be aware that ESP-IDF does not like spaces in the path)
2.1 mkdir C:\esp
2.2 cd C:\esp
Clone the repository from git into the current directory with:
git clone -b v4.2 --recursive https://github.com/espressif/esp-idf.git . <= don't forget the . at the end
Run install.bat
Once installed, you can run in the folder you project lives c:\esp\export.bat which will set the environment variables for you to use idf.py tool.
If you are trying to install ESP-IDF on Windows and still having issues, try the latest installer with some pre-install verification.
You can download here: IDF-Installer
Alternatively, you can try this tool: idf-env
I am trying to set up a build environment for Code Composer Studio to build projects for the CC1352 Launchpad that I have with me, inside a docker container running ubuntu.
I was able to download and install Code Composer Studio version 9.0.0 (latest 10 - and I wasn't able to install the latest version through the command line). I was also able to install the Simplelink SDK which has software and examples for the dev-kit that I have.
I'm following this guide to import and build projects from the command line for Code Composer Studio:
http://software-dl.ti.com/ccs/esd/documents/ccs_projects-command-line.html
However, when I try to import a project (com.ti.ccstudio.apps.projectImport) into a workspace, or just try to create a new project (com.ti.ccstudio.apps.projectCreate), or really run any kind of eclipse command, I get an error:
java.lang.RuntimeException: Application "com.ti.ccstudio.apps.projectCreate" could not be found in the registry.
The main command that I'm running in order to build this code is :
./eclipse -noSplash -data "../../../ccs_workspaces/" -application com.ti.ccstudio.apps.projectCreate -ccs.name newProject -ccs.device com.ti.ccstudio.deviceModel.C6000.GenericC64xxDevice
Any ideas?
https://github.com/algebratech/ccsv9-docker
Used this docker container. Can now create projects.
I made a golang app on my machine that uses cron. On my machine, I
"go get github.com/robfig/cron"
to download and install dependency then in my app I
"import cron "github.com/rk/go-cron""
the app works fine and runs the way I want. I then upload it to the server where it's supposed to run and try to "go get github.com/robfig/cron" as I did on my machine, but then it gave me this
I downloaded and installed github but still the same result. I'm guessing the problem is with github on my server machine
I am new to golang and andy kind of help would be greatly appreciated. Thanks.
What you need to install is git. It is the version control system (VCS) used by GitHub.
The native GitHub application does not provide the command line tools used by Go.
Git can be found and downloaded at http://git-scm.com/downloads
Once installed, make sure you have the path to the Git cmd folder in your %PATH% environment variable.
You can check this by running the command: echo %PATH%
On a Windows installation, you might find it located here:
C:\Program Files (x86)\Git\cmd
I am trying to build a VS .sln that has multiple C++ .vcproj's in it. The solution file is generated using CMake and I've got this part working in Jenkins (with the CMake builder plugin). To build the solution file, I am using msbuild. I am able to build the solution using both Visual Studio and from the command line with the following command:
C:\Jenkins\workspace\SonioTest>"C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" /t:Rebuild bin/SonIO.sln
This builds successfully (on the same machine that Jenkins resides).
However, I am trying to automate this portion of the build in Jenkins and the build ends up failing with a couple of C1083 errors ("Cannot open source file: '..\path\to\file.ext': No such file or directory). I have tried using both the Jenkins msbuild plugin and using the exact same command that works in the terminal as a "Execute Windows batch command" build step, with the same result.
When using the Windows batch command build step, I can see in the log that the command being executed:
C:\Jenkins\workspace\SonioTest>"C:\Windows\Microsoft.NET\Framework\v4.0.30319 msbuild.exe" /t:Rebuild bin/SonIO.sln
... is exactly the same as the one that works from the command line, including the working directory.
I am running Jenkins as a service and I have the service logon as my account (with administrator privileges). Anyone know what directory Jenkins will execute batch commands out of?
Any ideas why I'm seeing this difference of behavior between Jenkins and the command line?
This is as much a workaround as a solution, but I ended up using devenv instead of msbuild and it works fine.
I know that this hints strongly as it being an environmental issue, but since it's not a problem to have VS installed on the build server, I decided to save the time that would be spent in the msbuild rabbit hole.
The environment being used by the account that the Jenkins slave agent is not the same environment as you use when doing the same command line from a prompt. Compare the two environments, note the difference, then add them to the Jenkins job.
To get the environment of the slave while running, have it do a "set" from a Windows Command Prompt
Without knowing much about VS build, it looks mostly like an environment setup.
My first advice would be to make sure, in Jenkins, you change directory to the same directory you ran the good command from and try it then.
Also, might want to try running Jenkins as a standalone app first.
And as a service, maybe allow service to "interact with desktop".
I may be late to the party, but I still ran into this problem on a new Jenkins setup on Server 2016.
My solution was to use the MSBUILD straight from the VS2017 installation C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin. No more errors.