1

Closed

MSTest broken with lastest NuGet 2.4 and 2.5 builds

description

I get the following error when NuGet Tools 2.5 Beta, the 2.5 nightly build or current 2.4 are installed:

------ Discover test started ------
Error: Missing method 'instance string [Microsoft.VisualStudio.TestWindow.Core] NuGet.VisualStudio.IVsPackageMetadata::get_InstallPath()' from class 'NuGet.VisualStudio.VsPackageMetadata'.
========== Discover test finished: 70 found (0:00:02.4115856) ==========

I've tried this with both VS 2012 Premium RTM Update 1 and Update 2 CTP 4. I have also seen various forum posts confirming other people experience this problem.

The impact is you can no longer run tests, but can still debug them (so there is a workaround).

The error message suggests the NuGet Visual Studio extension has not implemented a required "InstallPath" property.

file attachments

Closed Apr 15, 2013 at 5:13 PM by deepakverma

comments

dotnetjunky wrote Apr 3, 2013 at 10:21 PM

Can you describe what you were doing which caused the error to show up? What projects do you have in your solution?

CodeChief wrote Apr 4, 2013 at 12:09 AM

I've recreated the sample as follows... (first the screenshot)...

CodeChief wrote Apr 4, 2013 at 12:23 AM

...and the solution.

Here is the procedure:

1) New solution in VS 2012 Premium.
2) Add a class library project.
3) Add a unit test project.
4) Compile, no problems, click the test window, no problems.
5) Enable NuGet package restore, no problems.
6) Add a NuGet package to the class library, I chose the Entity Framework for example.
7) Rebuild then click the test window again, you will see the missing method error detailed here before.

Removing the NuGet package from the class library then rebuilding removes the error. Adding it back again returns the error. It seems easy to re-create.

I've experienced this originally on the VS 2012 Update 1 (current public release) and recently tried updating to VS 2012 Update 2 CTP 4 and now have the NuGet 2.5 Beta installed due to other issues with WIX projects. The MSTest error seemed to appear (confirmed by other forum posts) in the 2.4-2.5 versions. I've also tried this on different machines. Both machine have some other extensions on like ReSharper, PowerTools and Visual Studio Achievements, but it made no difference when I disabled them.

I wonder if the method name itself already points to the error in the source code? What is this InstallPath and why doesn't the NuGet extension expose it, or is it null when it should be an empty string? Perhaps it's just some metadata missing from the NuGet MSBuild targets. This error occurs during discovery. It's clearly running across anything referenced in the project and it expects the InstallPath to be implemented.

Does this make sense, or is it the other way around... is the MSTest doing the wrong thing by expecting every add-in to have the InstallPath implemented?.

CodeChief wrote Apr 4, 2013 at 12:24 AM

In case it is not clear from the screen shot you need to make sure the Output Window is visible (I have that set to pop-up automatically on build) and drop-down to the "Test" output window category. Although in my experience it pops up and switches to that view automatically when the error occurs, but not when there is no problem.

dotnetjunky wrote Apr 5, 2013 at 12:59 AM

This error looks like a bug in the MSTest component itself. NuGet does expose the InstallPath property. I'm not sure why it complains the property is not present.

dotnetjunky wrote Apr 5, 2013 at 8:48 PM

Fixed in changeset acf37fc37d28226c101711ccd689df951ed9838b

** Closed by dotnetjunky 04/05/2013 1:48PM

dotnetjunky wrote Apr 5, 2013 at 8:50 PM

** Closed by dotnetjunky 04/05/2013 1:50PM

CodeChief wrote Apr 15, 2013 at 8:22 AM

I can confirm this is fixed in today's build, tested together with the current Visual Studio 2012 Update 2 (Premium Edition / MS Test capable).

In case anyone else has this issue, you need to know it still didn't work with the nightly builds from last week, or the 2.5 Beta from early April. So you really have to download the work-in-progress build (or any later public release) to solve this problem.

Thanks again for the support.

dotnetjunky wrote Apr 15, 2013 at 3:42 PM

Thanks for testing and confirming.