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

AppDomain and CurrentDirectory is different from NUnit. #61

Closed
dacat opened this issue Jul 19, 2013 · 5 comments
Closed

AppDomain and CurrentDirectory is different from NUnit. #61

dacat opened this issue Jul 19, 2013 · 5 comments
Labels

Comments

@dacat
Copy link

dacat commented Jul 19, 2013

Let me preface by saying I am not an expert in C# or the .NET framework. I just stumbled on this.

When I run NUnit tests, either from ReSharper or with in VS2012, the AppDomain.CurrentDomain.BaseDirectory is the build output path from the project properties. ex

c:\vsprojects\mySolution\target\bin\debug\x64

Also the Directory.CurrentDirectory during launch is also the the build output path from the project properties, same example as above.

However when your run NSpecRunner from the package management console, obviously, the CurrentDirectory is current path where you executed NSpecRunner from and the AppDomain.CurrentDomain.BaseDirectory is
c:\Users\myuser\documents\Visual Studio 2012\Projects\mySolution\packages\nspec.0.9.67\tools.

Honestly I don't know if its relevant to even report it. Its just a minor inconsistency between the two, and I only stumbled upon it consuming someone else's library that relies on have a AppDomain.CurrentDomain.BaseDirectory\Bin directory.

Thank you for developing NSpec :)

@amirrajan
Copy link
Collaborator

We struggle quite a bit with getting all the AppDomain stuff right...so I'm not surprised by this issue. It's an on going problem unfortunately. Here is the class that does all the app domain specific stuff for NSpec:

https://github.com/mattflo/NSpec/blob/master/NSpecRunner/NSpecDomain.cs

If you cant tell, we've taken a reactive (read hacky) approach to this class as errors have cropped up (this being another one). If you know any AppDomain gurus that can help us, that would be awesome. I'll take a stab at it of course :-). Thanks for submitting the issue.

@amirrajan
Copy link
Collaborator

Still relevant, but should be resolved when NSpec requires all devs to create their own Program.cs (which will be stupid simple)

@BrainCrumbz
Copy link
Collaborator

This should be closed once dotNET Core port is fully ready, as there's no AppDomain in ported version (at least as of now, future Core versions might add some parts of BCL back).

@amirrajan
Copy link
Collaborator

This brings me tears of joy.

@BrainCrumbz
Copy link
Collaborator

Closing as library has been ported to .NET Core, and in current implementation there's no use of AppDomain

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

No branches or pull requests

3 participants