We have an nunit3 test project that we're trying to run via command-line in dotnet core that is having problems being identified. In all our debugging we've not found an answer to fixing this.
Background: We build out these tests to test an API site after it's been deployed, alongside standard unit testing. So we package the test up as a DLL to run after we've built out the site, and configure it to run against the site. On our local machines, the tests can't be identified until we install Resharper on our Visual Studio.
After attempting a
dotnet test "path\to\bin\release\Test.dll"
we get the error:
No test is available in path\to\bin\release\Test.dll. Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.
Additionally, path to test adapters can be specified using /TestAdapterPath command. Example /TestAdapterPath:.
According to Resharper site, the tools require the run: dotnet tool install -g JetBrains.ReSharper.GlobalTools
doing so I've found the adapters at
C:\Users\USER\.dotnet\tools\.store\jetbrains.resharper.globaltools\2020.3.2\jetbrains.resharper.globaltools\2020.3.2\tools\netcoreapp3.1\any\TestRunner\Adapters
but when trying to load a given adapter dll using /TestAdapterPath, it says it can't find it. any idea how to get this test running?
Ensure your test project has a reference to the test adapter built in:
<PackageReference Include="NUnit3TestAdapter" Version="3.17.0" />
can be pulled from nuget package manager in Visual studio or placed into the section with all other package references.
after this, run dotnet test against your built DLL
Related
I have solution with following projects:
Api
Application
Infrastructure
Tests
Api is WebApplication (entry point) and has ProjectReferences to libraries Application and Infrastructure.
Tests is a xunit test project and has ProjectReferences to Api / Application / Infrastructure.
I want consistent package versions both during publishing main (Api) project and during running tests.
I added following properties to Api.csproj:
<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
<RestoreLockedMode Condition="'$(CI)' == 'true'">true</RestoreLockedMode>
And it generated Api/packages.lock.json - and it seems that this file also tracks versions of dependencies of referenced projects.
Here is how I publish application (Api):
RUN dotnet restore ./Api/Api.csproj
RUN dotnet publish Api -c Release -o out --runtime alpine-x64 --self-contained true /p:PublishTrimmed=true
So if CI=true env var is set, then commands above should either restore packages according to package.lock.json or fail.
However before publishing Api I run tests like this:
dotnet test ./Tests/Tests.csproj
My question is how to ensure that exactly same package versions will be used suring testing as in Api/package.lock.json? Because if I add <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile> to Tests project then it will have separate Tests/package.lock.json file which may not be same as the one in Api/package.lock.json, right? On the other hand when Tests project references Api project then from what I understand Api/package.lock.json is ignored (when running Tests project)?
Is it possible to have one package.lock.json for solution (same for all projects in solution)?
I feel a bit bad for making this an answer and possibly getting rep votes, when mu88 beat me by 12 hours in the comments to the question, but Central Package Management is the answer. There's also a blog post about it.
Currently, neither Visual Studio, nor dotnet add package support installing or upgrading packages, so you will need to hand edit all the xml (csproj, props) files. But support should be coming in VS 2022 17.4, .NET SDK 6.0.400.
I upgraded Visual Studio Community to the final release, and it stopped working. Specifically, I could generate a new project, but when I try to load it, it gave me an error
Critical Project 'SdkTest' load failed| [MSB4236] The SDK 'Microsoft.NET.Sdk.Web' specified could not be found. ...\SdkTest.csproj
Even though build and run worked fine
I ran "repair" on VS2022, and it seems to be working now from Visual Studio. However, dotnet --info doesn't show any SDKs; only runtime; and dotnet build or dotnet new give an error:
C:\Code>dotnet new console -o myapp
Could not execute because the application was not found or a compatible .NET SDK is not installed.
Possible reasons for this include:
* You intended to execute a .NET program:
The application 'new' does not exist.
* You intended to execute a .NET SDK command:
It was not possible to find any installed .NET SDKs.
Install a .NET SDK from:
https://aka.ms/dotnet-download
I even reinstalled .NET 6 and I see it in the list of applications (along with older SDKs). I checked the path, and I see everything that I expect to see:
C:\Program Files (x86)\dotnet\
C:\Program Files\dotnet\
C:\Users\me\.dotnet\tools
I am running Windows 11.
It's known bug in VS2022 installation.
Problem is that dotnet you access is located inside Program Files(x86)/dotnet, but all sdk's are located in Program Files/dotnet. You simply need to edit PATH environment variable so Program Files/dotnet goes before Program Files(x86)/dotnet. If you don't see Program Files(x86)/dotnet in user environment variable (which is likely to happen) then edit system environment variable (located below)
Example with screenshots: https://stackoverflow.com/a/44272417/10339675
I am trying to run a simple GRPC client-server code in raspberri Pi running Raspbian os.
Language that i am using -C# dotnet core (2.1)
I downloaded a sample project from here.
This is a dotnet core project . I am able to run it in Windows environment, i am also able to modify .proto file in this code and run successfully.
I published the solution as it is with command
{ dotnet publish -r linux-arm }
When tried running same on Rpi, i am getting exception. Attached screenshot has the details of it.
Any help to get through this would be of great use
tl;dr The problem is the libgrpc_csharp_ext native library which currently does not get compiled and built for the arm7 processor. I've compiled it (on a pi) for arm7 and released a nuget package to bridge the gap until they support it all the way: https://www.nuget.org/packages/libgrpc_csharp_ext.arm7/
I'll update with a link to a blog post when I finish getting the rest of the tooling and template finished I'm working on.
fuller explanation: the Grpc.Core nuget package contains the native libgrpc_csharp_ext library that the dotnet implementation of grpc loads in NativeExtensions.cs then maps with PInvoke in NativeMethods.Generated.cs. Inspecting that package, you'll see a version of that library in each /runtimes/[win, osx, linux]/native folder. Unfortunately, no linux-arm version of the library is included. However, in the code, if the platform is linux, it will try to load the static library using the name as formatted here. Dissect that a little and you'll see that as of right now, any 'linux' platform that isn't '64bit' (which despite the proc on the pi being 64 bit, the distro of linux you're using on there, including raspbian, likely isn't) will look for libgrpc_csharp_ext.x86.so. When you dotnet publish -r linux-arm, you'll see that library there in the build output, but unfortunately, it's the wrong one (I think publish just grabs 'the closest one' when it can't find a specific library in the runtimes folder).
The nuget package I created above is compiled for arm7 - I actually cloned the grpc repo onto a pi and peeled away enough of the /csharp build to just cmake the libgrpc_csharp_ext. The 'trick' the package uses is to put the library in runtimes/linux-arm/native folder within the package, which dotnet core recognizes when publishing and pulls into the build output - but the library is still named libgrpc_csharp_ext.x86.so because of the way NativeMethods.cs formats the library name.
I wrote a test project using .NET Core and assembled the self-contained deployment for Ubuntu 16.04 as described here (see Self-contained deployment without third-party dependencies).
But when I run the app I get the following error:
An assembly specified in the application dependencies manifest (Test.deps.json) was not found:
package: 'runtime.linux-x64.Microsoft.NETCore.App', version: '2.0.0-preview2-25407-01'
path: 'runtimes/linux-x64/lib/netcoreapp2.0/Microsoft.CSharp.dll'
I am using .NET Core 2.0 Preview 2, VS2017 Preview.
I will be grateful for any help!
This is an old question, but I just ran across this when I was trying to run a .Net Core application on Linux and wanted to share the solution. If you are getting the error above, you are likely trying to execute the wrong binary. For those following along from scratch, follow these steps:
On Windows, open a command prompt in the directory of the project you want to run on Linux.
Build the project for Linux using dotnet publish -r linux-x64
I chose to target linux-x64, but you can target a specific runtime if you'd like. Runtime identifiers can be found here.
Copy the published files to the Linux workstation. Because the above command omitted the configuration flag -c, the configuration defaulted to debug. The published files will be in Debug\netcoreapp2.0\linux-x64\publish
Note: there will be binaries in Debug\netcoreapp2.0\linux-x64\ too. These are not the binaries you want to copy to your Linux workstation. If you run these binaries, you will get the error described in the OP. Copy all the files in the publish directory instead. Ignore whatever files might be in linux-x64.
On the Linux workstation, give execute permission to the binary file. My project was named ConsoleUI, so I used chmod 764 ConsoleUI
Execute the binary using ./ConsoleUI
Keep in mind that you will need to at least have the .Net Core runtime installed on your Linux workstation.
I have a build definition in Visual Studio Team Services (previously Visual Studio Online) to build an ASP.NET web application using an on-premise agent. The agent has VS2012 installed and all the other necessary prerequisites to assist in building the application. However, when running the build, it fails and outputs below error:
C:\Program Files
x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4021,2):
Error : Web deployment task failed. (The .zip file package
'C:\BuildAgent\_work\1\a\' must be a file, not a directory.)
Process 'msbuild.exe' exited with code '1'.
I tried building the project on the agent machine using VS2012 and it builds fine. Also, I have defined following MSBuild parameters in the build definition which is same as my other builds that use a hosted agent:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
What could be the cause of this issue? Do I need to install anything extra?
You are using VS2012, you need to specify detail PackageLocation argument with .zip suffix ($(build.artifactstagingdirectory)\testWeb.zip). If you are using higher version of VS/MSBuild (e.g. vs 2015), a folder path is ok, it will adds [XXX].zip to the end of that path.