When we download git project and click build button in VS, it restores nuget packages and then compile. always cool.
Just like that, I'd like to install Redis locally before compile because my project unit test job requires Redis.
I found Redis-64 in nuget but I don't know why it does not install properly. It displays "Redis-64 is already installed" but it's not.
There is Chocolately nuget package and Redis for chocolatey. It looks promising to utilize them.
To achieve my goal, it would be required to (1) check installation of chocolately first, and then (2) download redis-64, and then (3) execute redis-server.exe before compile process (could be placed at the Pre-build event command in .csproj property).
I want to know how to check Redis chocolatey installation and rest of other steps in VS. Would you please teach me how to achieve to do that?
I could be way off the mark here, but the redis package that you are referring to, i.e. from NuGet should only include the assemblies that you could then consume within your application. If you actually want to have the Redis application installed, you would want to install the Redis application from Chocolatey.org, which you can find here.
In terms of getting Chocolatey etc installed as part of your build process, you might want to take a look at the build script for ChocolateGUI. As part of it's build, which is executed on AppVeyor, it checks for Chocolatey, and if it isn't there, installs it, and all required applications.
For what you want, I think you need to include:
choco install redis
Within your build script, and this will give you the redis-server.exe that you are looking for.
I installed the redis-64 NuGet package and it just worked for me. It is an unusual package in that it doesn't associate itself with any Visual Studio project, but rather it is referenced from a solution-level packages.config.
To use the Redis server in my integration test, I start the server with this code:
Process.Start(new ProcessStartInfo(Path.Combine(Directory.GetDirectories(#"..\..\..\packages", "Redis-64.*").Single(), "redis-server.exe"), "--bind 127.0.0.1") {
WindowStyle = ProcessWindowStyle.Hidden
});
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
In Visual Studio, I'm trying to configure an ASP.NET Web API project to be published to the Azure cloud. Authentication will be done through the Microsoft Identity Platform. Currently, this is not configured in the project's publishing settings:
Clicking "Configure" pulls up a dialog box where I complete a series of simple config steps. At the end, the dialog seems to execute a number of tools/utilities to put in place the settings I just specified. One of these commands it attempts to run is failing:
Inserting code...
dotnet msidentity --update-project --tenant-id [OUR TENANT ID] --username [MY USERNAME] --client-id [OUR CLIENT ID] --project-file-path "[OUR PROJECT PATH].csproj" --calls-graph=True --calls-downstream-api=True --code-update=true --json
Unrecognized command or argument '--code-update=true'
I'm not sure what to do about this, as all these commands are being generated and executed internally. I have the latest version of the Azure.Identity (1.5.0) and Microsoft.Identity.Web (1.21.1) NuGet packages installed. All other Nuget packages are up to date as well.
Any pointers on how I can try to debug this?
I was able to find help and get an answer by posting on the Visual Studio support site:
https://developercommunity.visualstudio.com/t/aspnet-api-project-microsoft-identity-platform-con/1627164
It turns out there are a separate set of packages- besides both NuGet and the standard install of .NET- which I was completely unaware of: "local CLI tools". Specific versions of certain command line tools were created as part of the VS project, and these versions were in fact out of date and so created a conflict with the newer code from NuGet.
Using the .NET CLI, I ran the command dotnet tool uninstall on all local packages for the project, which effectively tells the project to just use the version of the tool present in the current install of the .NET framework, rather than a specific version from a local copy. This fixed the problem.
I need a NuGet (example xunit.runner.console) to run UT from command line.
Right now in one of project I have added xunit.runner.console as dependency so it is downloaded, path is known and I can use it in my build script.
This Project was removed and build-script is broken now. I will need to add it to another project, but the same situation can occur again (or other reasons).
I there a way to download this package but don't link it with concrete project?
You can install the nuget cli and then get the package needed using the build script. So, to answer your question, you can just use it in the build script and fetch the package before starting to build your project.
I'm have command line tool built as a NuGet by TeamCity.
My problem is that I would like to use the tool in a build step within the same TeamCity server and the execute the command line tool as part of the step.
The easiest way would be to just compile the command line tool and create an artifact without creating a NuGet and then take an artifact dependency in the other build process and execute the command.
But I would like to know if it's possible to do the same with a NuGet package so I can reuse the tool for other purposes?
Update
After some more testing with TeamCity I think the main issue is that the "NuGet Installer" runner requires a solution file. I can do what I want with a powershell task:
# install the latest package
%teamcity.agent.tools.dir%\NuGet.CommandLine.2.7.1.nupkg\tools\NuGet.exe install octospike-migrator -o tools -excludeversion -source %teamcity.nuget.feed.server%
# run the command line tool
.\tools\octospike-migrator\lib\Octospike.Command.exe
The build step above is working a intended but I have the feeling that the default runner "Nuget Installer" should be able to handle this?
I'm running TC7 so it might be working in TC8
Assuming the package is referenced in your solution and you have enable missing package restore enabled, the package will be downloaded and unpacked into your solution. The executable will go into a known location (whatever directory you've specified for the package). You should then be able to access the executable as you would any other resource.
If you need flexibility in regards to where and how the resources are unpacked (e.g., if they need to go in a directory outside of the project), you can build this as a Tools package in NuGet.
In TeamCity, the complexity will be reduced if you break this process into separate tasks.
I'm trying to install something with the following command:
make world
It takes a long time, and usually it ends up with an error saying that I'm missing some kind of package. I found out what the package is, install it, and run the thing again, only to find out after a long time that I'm missing another package. Is there a way to find out all the packages I need to install without having to go through this process?
This is generally what the configure script does. If the project you're building doesn't have one, you should write one.
The best way to deal with dependencies is with a package manager such as:
On Ubuntu: apt-get
On Red Hat / Fedora: yum
On Mac OS X: port
On Windows: cygwin
If you install software with a package manager, it will automatically fetch, download, and install any dependencies as necessary. These package managers support a huge number of popular open source projects, but not all projects are supported. Some of these package managers support creating custom package repositories, which allows them to be used for dependency management in-house, as well.
Unfortunately, there is no general way to get all the library dependencies of a Makefile (short of grepping for "lib", ".so", and "-l" which may give you spurious results); however, if you are installing an open source project, chances are that it is supported by a package manager on your system.