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

WorkingDirectory coming incorrectly for .NET Core and .NetFramework #311

Closed
saikrishnav opened this issue Jan 3, 2017 · 11 comments
Closed
Assignees
Milestone

Comments

@saikrishnav
Copy link
Member

Description

With .Net Core 1.0, Working DIrectory is IDE folder whereas with .Net framework, it is System32 folder.

Steps to reproduce

File -> New -> Test -> Unit test project:

When test app targets only .NET Core 1.0:

Directory.GetCurrentDirectory() = C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE

When test app targets both .NET core 1.0 and .NET Framwork:
(netcoreapp1.0;net451)

Directory.GetCurrentDirectory() = C:\Windows\system32

Expected behavior

Expected Working Directory should be the directory where the test binary is. Since TestResults folder, or TRX files or Code Coverage files are generated relative to working directory, this is required to be "Test binary" directory. Also, Compat.

Actual behavior

Actual is "system32" or "IDE" folder

@pvlakshm
Copy link
Contributor

pvlakshm commented Jan 5, 2017

@singhsarab
Copy link
Contributor

Commit : b554ca7

@dazinator
Copy link

dazinator commented Mar 3, 2017

I am seeing same problem.

test host used is: C:\Users\Darrell\.nuget\packages\microsoft.testplatform.testhost\15.0.0-preview-20170125-04\lib\netstandard1.5\testhost.dll

Directory.GetCurrentDirectory() is: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE

I am using xunit 2.2.0 and xunit.runner.visualstudio 2.2.0

@smadala
Copy link
Contributor

smadala commented Mar 9, 2017

@dazinator Can you please try Microsoft.NET.Test.Sdk: 15.0.0. It should work for run scenarios, For debug scenario, .Net Core project WorkingDirectory comes as "C:\Windows\System32" for which bug is tracking for VS 15.1.

@kdrblkbs
Copy link

@smadala i tested out Microsoft.NET.Test.Sdk: 15.0.0 and experienced the same issue. On running units tests from the MS Visual Studio 17 gui Directory.GetCurrentDirectory() is still C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE. When i use the cmdline tool the current directory is resolved correctly.

@singhsarab
Copy link
Contributor

@kdrblkbs

  • What version of VS are you using? Please use the latest Visual Studio RTM.
  • What dotnet framework does your project target?
  • What test framework are you using ?
  • By commandline tool, you mean dotnet test ?

@kdrblkbs
Copy link

hello @singhsarab
i am using MS Visual Studio Enterprise 2017 15.0.0-RTW+ 26228.4. The framework target of my test project is .NETCoreApp 1.0. I am using xunit 2.2.0 and xunit.runner.visualstudio 2.2.0, too. and the final answer is yes.
regards

@singhsarab
Copy link
Contributor

singhsarab commented Mar 13, 2017

This is interesting, as I tested this scenario and it works fine.

Can you please try the following commandline
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\TestPlatform\vstest.console.exe" pathToTestDll /framework:".NetCoreApp,Version=1.0"

@kdrblkbs
Copy link

@singhsarab its working now. i guess i was relying on the debug mode to check the result of GetCurrentDirectory() conveniently. If it is relevant in my case it is still C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE and not C:\Windows\System32. thanks and regards

@cwharris
Copy link

cwharris commented Mar 17, 2017

In VS 2017 release, It seems that Directory.GetCurrentDirectory() returns C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE when debugging tests, but otherwise returns the test project's debug directory, aka {project_path}\bin\Debug.

Is this intended? Because it doesn't look like it's intended.

@smadala
Copy link
Contributor

smadala commented Mar 17, 2017

@cwharris Yes, you are right,It is a bug, has been fixed, fix will be available VS 2017 update 1.

MarkMichaelis added a commit to IntelliTect/EssentialCSharp that referenced this issue Jul 16, 2017
-Fixed to handle cross platform new lines;
-Addressed MSTest but which required setting the initial directory to be the location of the assembly (required due to bug - see See microsoft/vstest#311)
MarkMichaelis added a commit to IntelliTect/EssentialCSharp that referenced this issue Jul 16, 2017
…icrosoft/vstest#311

- Converted all new lines to use Evironment.NewLine
- Used reflection to locate directory of test assembly and then switched that to the current directory due to incorrect starting directory as described at See microsoft/vstest#311
MarkMichaelis added a commit to IntelliTect/EssentialCSharp that referenced this issue Aug 4, 2018
-Fixed to handle cross platform new lines;
-Addressed MSTest but which required setting the initial directory to be the location of the assembly (required due to bug - see See microsoft/vstest#311)
MarkMichaelis added a commit to IntelliTect/EssentialCSharp that referenced this issue Aug 4, 2018
…icrosoft/vstest#311

- Converted all new lines to use Evironment.NewLine
- Used reflection to locate directory of test assembly and then switched that to the current directory due to incorrect starting directory as described at See microsoft/vstest#311
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

8 participants