Build/ debugging instructions

[corliss]

I'd like to help fix #22. I have not debugged a visual studio extension before. I understand that there is a way to run Visual Studio itself under the debugger, with the debug build of the extension. However, trying to debug the NUnitTestAdapter project does not work - there are no debug settings configured.

Could you please add a brief README (or just add to this issue) that explains how to get started?

On another note, I ran the unit tests from the Master branch and 24 tests failed (69 passed.) Is this expected?

[CharliePoole]

Good suggestion. Re: running tests... they should definitely all pass.

[CharliePoole]

@OsirisTerje This seems like a good opportunity to figure out how we can make an individual project wiki interface cleanly with the general dev wiki. Can you take a shot at setting up a wiki structure for nunit-vs-adapter? It should point to the main wiki for general stuff and have a similar breakdown to the main wiki for items that are unique to the adapter. I think this is probably the project that most clearly shows breaks between what is project-specific and what is general to NUnit and the question of how to set up for developing the adapter is quite unique.

[OsirisTerje]

Hi !

You're quite right that many tests fails now. I did notice, but thought my setup was flawed after a new machine was setup. Obviously not.
The cause is that we updated to NUnit 2.6.3,and after that a bunch of the unit tests failed because of library dll's requiring 2.6.2.
I have pushed up a branch named Version263Fixes which corrects this, and which also references the VS2013 object model for the MS Testplatform. In the Lib folder there you can find the 2.6.3 dll's. Note: They are not signed!
Update: Last commit contains signed versions :-)

@Charlie: Yes, I will write up debug/development information on this wiki pretty soon.

But with the unit tests working you can at least start doing something.

And - a small quick and dirty tip - if you need to debug in-situ, add some well-placed temporary Debugger.Launch commands inside the code, that fires up the debugger. If you use the code, there are some such statements behind a #define. If you define the symbol LAUNCHDEBUGGER at the top of the file you want to debug, the debugger will be launched at strategic places in the code.

/terje

[corliss]

Hi - I am looking into this again. A couple of requests:

1. I tried loading and running the solution (from a checked-out copy of the latest master branch) in VS2013.

a) The NUnitTestAdapterInstall project is listed as incompatible, and does not load. b) Clicking Run All in the test explorer (with version 1.0.0.0 of the test adapter being installed) does not run any tests at all.

So I tried loading the solution in VS2012 instead. Here too NUnitTestAdapterInstall is listed as incompatible and does not load. However, clicking Run All in the unit test does run all tests. There is one failure - RegistryTestExists.

2. Could you please provide just a few lines of debugging instructions assuming I know nothing about debugging add-ins? What you have stated above seems to assume that debugging has already started. Without some very basic instructions, I might be stuck here for a while.

[OsirisTerje]

Have you read through the prerequisites here: https://github.com/nunit/nunit-vs-adapter/wiki/How-to-build-and-package-a-release ? It very much sounds like you dont have the SDK installed, since that is where you find the VSIX support, which is needed for Install project.

In order to debug it you need to

Option 1: Attach to a running instance of either the VSTest.executionengine or the VSTEst.discoveryengine, depending on which phase you're working on. Note that there might be multiple instances running! Keep it simple and run only one instance of VS:

Option 2: Add a line with System.Diagnostics.Debugger.Launch() at the place in the code where you want to break in. That will start a VS instance selector, and you can select your project.

Option 3: Start it as an experimental instance. I rarely go that route... so try 1 or 2 first.

Also, for 1 and 2, remember to install the newly built vsix first.

For 1b) above : Is there any messages in the Output/Tests window ?

[corliss]

Thanks. I just installed the SDK and now NUnitTestAdapterInstall does load in VS2013. I had to fix the paths to Microsoft.VisualStudio.TestPlatform.ObjectModel to point to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\Microsoft.VisualStudio.TestPlatform.ObjectModel.dll in order to get the unit tests to run.

Question: I am trying to determine why certain tests are not being discovered in VS2013, but are in VS2012. It occurs to me that this hard-coded reference to a VS2012 dll may have something to do with it. Is this possible? I will investigate further in any case.

In order to debug it you need to

Could you define "it" a bit more clearly? It sounds like I need to install the package before debugging, since you don't suggest using an experimental instance. Is that correct?

Option 1: Attach to a running instance of either the VSTest.executionengine or the VSTEst.discoveryengine, depending on which phase you're working on.

Is there any documentation explaining these phases? Also, I'm assuming that VSTest.executionengine and VSTEst.discoveryengine are part of the Visual Studio installation, although I haven't located them in my filesystem yet.

Thanks!

[OsirisTerje]

I'll try to write up a more complete guide "real soon now".

1. Yes, the path must be fixed up.
   It refers to a VS 2013 dll, since the path says ...\12.0... 12.0 is the codenumber for VS 2013. We should add some powershell script to set this correctly after cloning.
2. Correct, for option 1 and 2 you need to install the package first. Starting up an experimental instance work too, but it doesn't save you any time, once you get the hack of it :-) In any case you must fire up a new instance of VS.
3. When the test explorer runs it will start up these two background processes. Use the task explorer to locate them, or just select Attach to process in VS, and they will be present in the list of running processes there.

[OsirisTerje]

This information above should be added to the wiki.

[CharliePoole]

@OsirisTerje So, adding it to the V3.0 milestone was to mean that you don't intend to fix it at all for V2.0. Is that correct?

I'm taking your "adding to the wiki" to mean "adding to wherever we decide this stuff belongs" in the separate discussion we are having. :-)

[CharliePoole]

@OsirisTerje Not sure what to do with this. Both wikis have sets of instructions now. Should we close this? Give them a review first?

[kirill-d-lappo]

@OsirisTerje @CharliePoole guys, so what about this bug, are there any plans on it? "How to build" page still has no steps for building and debugging test adapter locally, neither nunit/docs/wiki/Visual-Studio-Test-Adapter has. I tried to build adapter for my own test purposes, but I don't think I did everything as it should be.

[OsirisTerje]

I'll go over the doc and write up. @Kira-Lappo Good if you can review and test the procedures afterwards

[kirill-d-lappo]

I'll go over the doc and write up. @Kira-Lappo Good if you can review and test the procedures afterwards

@OsirisTerje Sure, just let me know, when it is ready to be tested. And as a little note, I was actually able to build adapter dll for linux platform and use it in test project, which is suprise for me