Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests are failing on Linux for DesktopCLR #865

Closed
ghost opened this issue Jun 14, 2017 · 27 comments
Closed

Tests are failing on Linux for DesktopCLR #865

ghost opened this issue Jun 14, 2017 · 27 comments

Comments

@ghost
Copy link

ghost commented Jun 14, 2017

Description

I am trying to solve the following issues:

castleproject/Windsor#243
nunit/nunit3-vs-adapter#324

Steps to reproduce

Please clone the repro at: https://github.com/fir3pho3nixx/nunit-adapter-vs-xunit
Run build.sh on linux.

Expected behavior

I don't get System.ComponentModel.Win32Exception: Permission denied

Actual behavior

I get System.ComponentModel.Win32Exception: Permission denied

Environment

.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /usr/share/dotnet/sdk/1.0.1
@Faizan2304
Copy link
Contributor

@fir3pho3nixx dotnet test doesn't have capability to run Desktop test on Linux machine. We are tracking the work to enable it on Linux here

@ghost
Copy link
Author

ghost commented Jun 15, 2017

My issue is slightly different. I am using the targeting pack for net461 with framework override. Also my project builds fine. No mono from what I can tell unless that is what is happening under the covers.

@codito
Copy link
Contributor

codito commented Jun 16, 2017

Interesting issue. The framework override is here in the project.

dotnet test is trying to spawn testhost.exe for net46 target. PE executables are not natively registered in linux machines, the OS throws when we're attempting to launch something that it doesn't recognize as an executable. We need to launch testhost.exe with a CLR host (mono in this case).

In #851 we're fixing running testhost.exe within mono. I will raise a follow up PR to spawn mono testhost.exe for net46 tests.

@codito codito self-assigned this Jun 16, 2017
@codito codito added this to the 15.3 milestone Jun 16, 2017
@codito
Copy link
Contributor

codito commented Jun 17, 2017

Fix for this is in latest commit to #851

@ghost
Copy link
Author

ghost commented Jun 19, 2017

@codito - thank you for the quick response to this. I really appreciate it, it will clean up our build process and allow us to move off NUnitLite.

@JoseFMP
Copy link

JoseFMP commented Jun 23, 2017

Great that it will be fixed! Any work around in the mean time?

@ghost
Copy link
Author

ghost commented Jun 23, 2017

@jose-cf

Yes, you can temporarily use NUnitLite.

Make sure you set AppendRuntimeIdentifierToOutputPath to false.

Set your project type to exe.

Grab the nunit lite package.

Add Program.cs to your test project.

Then run it with NUnit options.

@JoseFMP
Copy link

JoseFMP commented Jun 23, 2017

Ok. In that case it looks simpler to do:

mkdir xunitTestRunner
sudo chmod a+rw xunitTestRunner
nuget install xunit.runner.console -Version 2.2.0  -OutputDirectory $PWD/xunitTestRunner
find ./artifacts/test -name "*Test.dll"       -print0 | xargs -0 -n1 mono xunitTestRunner/xunit.runner.console.2.2.0/tools/xunit.console.exe 

I hope dotnet test will fix soon.

@ghost
Copy link
Author

ghost commented Jun 23, 2017

Agreed, our tests are all in NUnit though :/

@ghost
Copy link
Author

ghost commented Jun 23, 2017

I hope dotnet test will fix soon.

That is exactly what this team is fixing with this issue. Please see #851. It is now in the 15.3 milestone.

@ghost
Copy link
Author

ghost commented Jun 27, 2017

@codito - Can we get this bundled into the current preview? Would be happy to be a test subject.

@codito
Copy link
Contributor

codito commented Jun 30, 2017

@fir3pho3nixx we're working on getting this into a dotnet-cli dev build (hopefully early next week).

@ghost
Copy link
Author

ghost commented Jul 2, 2017

@codito - Cool, ping back on this issue, I will have an answer for you the next day.

@codito
Copy link
Contributor

codito commented Jul 7, 2017

@fir3pho3nixx please try out the latest dotnet-cli dev builds: https://github.com/dotnet/cli#installers-and-binaries.

In local testing, we hit nunit/nunit3-vs-adapter#327, the workaround is to use dev builds of nunit adapter:

  1. Use nuget package source: https://www.myget.org/F/nunit/api/v3/index.json
  2. Use Nunit3TestAdapter version 3.8.0-dev-00491
  3. Disable source information collection as follows: dotnet test -- RunConfiguration.CollectSourceInformation=false

@ghost
Copy link
Author

ghost commented Jul 7, 2017

I am on holiday for a week and will be able to look at this when I get back. Thanks for pinging back! 👍

@codito codito modified the milestones: 15.5 (Sprint 121), 15.3 Jul 7, 2017
@ghost
Copy link
Author

ghost commented Jul 18, 2017

After updating to the nightly build I have found other issues. Please note, this was before I changed Castle.Core to use the dev build of the NUnit adapter.

dotnet restore

Appears to be functioning correctly; when I run the following commands

dotnet restore ./buildscripts/BuildScripts.csproj -s https://dotnet.myget.org/F/dotnet-core/api/v3/index.json
dotnet restore ./src/Castle.Core/Castle.Core.csproj
dotnet restore ./src/Castle.Services.Logging.log4netIntegration/Castle.Services.Logging.log4netIntegration.csproj
dotnet restore ./src/Castle.Services.Logging.NLogIntegration/Castle.Services.Logging.NLogIntegration.csproj
dotnet restore ./src/Castle.Services.Logging.SerilogIntegration/Castle.Services.Logging.SerilogIntegration.csproj
dotnet restore ./src/Castle.Core.Tests/Castle.Core.Tests.csproj

I get the following output:

Restore completed in 44.44 ms for /home/gavin/code/Core/buildscripts/BuildScripts.csproj.
  Restore completed in 25.53 ms for /home/gavin/code/Core/src/Castle.Core/Castle.Core.csproj.
  Restore completed in 22.53 ms for /home/gavin/code/Core/src/Castle.Core/Castle.Core.csproj.
  Restore completed in 2.93 ms for /home/gavin/code/Core/src/Castle.Services.Logging.log4netIntegration/Castle.Services.Logging.log4netIntegration.csproj.
  Restore completed in 34.41 ms for /home/gavin/code/Core/src/Castle.Core/Castle.Core.csproj.
  Restore completed in 1 ms for /home/gavin/code/Core/src/Castle.Services.Logging.NLogIntegration/Castle.Services.Logging.NLogIntegration.csproj.
  Restore completed in 178.18 ms for /home/gavin/code/Core/src/Castle.Core/Castle.Core.csproj.
  Restore completed in 17.11 ms for /home/gavin/code/Core/src/Castle.Services.Logging.SerilogIntegration/Castle.Services.Logging.SerilogIntegration.csproj.
  Restore completed in 54.3 ms for /home/gavin/code/Core/src/Castle.Core.Tests/Castle.Core.Tests.csproj.
  Restore completed in 3.48 ms for /home/gavin/code/Core/src/Castle.Core/Castle.Core.csproj.
  Restore completed in 3.78 ms for /home/gavin/code/Core/src/Castle.Services.Logging.NLogIntegration/Castle.Services.Logging.NLogIntegration.csproj.
  Restore completed in 2.12 ms for /home/gavin/code/Core/src/Castle.Services.Logging.SerilogIntegration/Castle.Services.Logging.SerilogIntegration.csproj.
  Restore completed in 0.71 ms for /home/gavin/code/Core/src/Castle.Services.Logging.log4netIntegration/Castle.Services.Logging.log4netIntegration.csproj.

dotnet build

Also appears to function correctly

dotnet build ./src/Castle.Core.Tests/Castle.Core.Tests.csproj /p:Configuration=Release || exit 1

I get the following output:

Microsoft (R) Build Engine version 15.3.406.54721 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Castle.Core -> /home/gavin/code/Core/src/Castle.Core/bin/Release/net45/Castle.Core.dll
  Castle.Services.Logging.log4netIntegration -> /home/gavin/code/Core/src/Castle.Services.Logging.log4netIntegration/bin/Release/net45/Castle.Services.Logging.log4netIntegration.dll
  Castle.Services.Logging.NLogIntegration -> /home/gavin/code/Core/src/Castle.Services.Logging.NLogIntegration/bin/Release/net45/Castle.Services.Logging.NLogIntegration.dll
  Castle.Services.Logging.SerilogIntegration -> /home/gavin/code/Core/src/Castle.Services.Logging.SerilogIntegration/bin/Release/net45/Castle.Services.Logging.SerilogIntegration.dll
  Castle.Core.Tests -> /home/gavin/code/Core/src/Castle.Core.Tests/bin/Release/net461/Castle.Core.Tests.exe
  Castle.Core -> /home/gavin/code/Core/src/Castle.Core/bin/Release/netstandard1.3/Castle.Core.dll
  Castle.Services.Logging.SerilogIntegration -> /home/gavin/code/Core/src/Castle.Services.Logging.SerilogIntegration/bin/Release/netstandard1.3/Castle.Services.Logging.SerilogIntegration.dll
  Castle.Core.Tests -> /home/gavin/code/Core/src/Castle.Core.Tests/bin/Release/netcoreapp1.1/Castle.Core.Tests.dll

Running net461 tests as a console app

This is where the problems start creeping in. Using the following command:

./src/Castle.Core.Tests/bin/Release/net461/Castle.Core.Tests.exe --result=DesktopClrTestResults.xml;format=nunit3

I get the following output:

./build.sh: line 48: ./src/Castle.Core.Tests/bin/Release/net461/Castle.Core.Tests.exe: Permission denied

Running the dotnet core tests using dotnet test

I also now have problems. Running the following command:

dotnet ./src/Castle.Core.Tests/bin/Release/netcoreapp1.1/Castle.Core.Tests.dll --result=NetCoreClrTestResults.xml;format=nunit3

I get the following output:

It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '1.1.2' was not found.
  - Check application dependencies and target a framework version installed at:
      /
  - Alternatively, install the framework version '1.1.2'.

@ghost
Copy link
Author

ghost commented Jul 18, 2017

Here is some more info about my environment:

dotnet --version

2.1.0-preview1-006784

mono --version

Mono JIT compiler version 5.0.1.1 (2017-02/5077205 Thu May 25 09:19:18 UTC 2017)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           __thread
	SIGSEGV:       altstack
	Notifications: epoll
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	LLVM:          supported, not enabled.
	GC:            sgen (concurrent by default)

lsb_release -a

Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.1 LTS
Release:	16.04
Codename:	xenial

Not sure what has happened here but it feels like either I am out of date and am in dire need of upgrading or things have gone slightly backwards.

If there is anything you guys need please let me know.

@codito
Copy link
Contributor

codito commented Jul 20, 2017

@fir3pho3nixx is there a branch I can look into for the source? I can try out at my end and suggest if there are any changes.

It should be possible to run both desktop and netcore tests with following command:

> dotnet test ./src/Castle.Core.Tests/Castle.Core.Tests.csproj /p:Configuration=Release || exit 1

@ghost
Copy link
Author

ghost commented Jul 20, 2017

@codito Thanks for getting back to me. I agree that this command should be used for both, however before I even upgraded the project to do this I was having problems with my current configuration so held off.

Our current working build is on master @ https://github.com/castleproject/Core. The build script is here and our TravisCI build configuration is here.

You can see from the above I upgraded mono and the dotnet cli which started causing the failures.

@codito
Copy link
Contributor

codito commented Jul 21, 2017

Running net461 tests

In Ubuntu, exe files are not treated as executables by default, also the OS doesn't know that it has to invoke mono to run these. Using following command runs the tests:

mono ./src/Castle.Core.Tests/bin/Release/net461/Castle.Core.Tests.exe --result=DesktopClrTestResults.xml;format=nunit3

Running netcoreapp1.1 tests

The error says .net core shared runtime 1.1.2 is not installed. With the dotnet latest dev builds it doesn't come packaged with SDK. The tests ran once I installed it separately from https://github.com/dotnet/core/blob/master/release-notes/download-archives/1.1.2-download.md (see Runtime Installer for the OS).

@ghost
Copy link
Author

ghost commented Jul 21, 2017

In Ubuntu, exe files are not treated as executables by default, also the OS doesn't know that it has to invoke mono to run these. Using following command runs the tests:

That is curious, as the binary file used to be generated with a 'x' attr. No problems, going to be converting it all over anyway.

Many thanks for taking the time to review. Will close this out once I have replicated your recommendations successfully.

@codito
Copy link
Contributor

codito commented Jul 21, 2017

In Ubuntu, exe files are not treated as executables by default, also the OS doesn't know that it has to invoke mono to run these. Using following command runs the tests:

That is curious, as the binary file used to be generated with a 'x' attr. No problems, going to be converting it all over anyway.

Mono docs mention it is possible to use binfmt on linux to register exe with mono. It recommends using a wrapper script for portability though :)

@codito
Copy link
Contributor

codito commented Aug 2, 2017

@fir3pho3nixx just checking in, were you able to run the tests in linux?

@ghost
Copy link
Author

ghost commented Aug 2, 2017

Not yet, will get to it this weekend. This week.

@Faizan2304
Copy link
Contributor

@fir3pho3nixx : If you don't have any open question here then can I close this issue?

@ghost
Copy link
Author

ghost commented Sep 11, 2017

My apologies, meant to close this ages ago. Thank everyone!

@ghost ghost closed this as completed Sep 11, 2017
@UncleFirefox
Copy link

UncleFirefox commented Sep 22, 2017

Hi, will this be fixed anytime soon in the official release? Thanks!

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants