I'm trying to install a custom test adapter via NuGet, but it seems like VS isn't recognizing it. I've looked through the code in Microsoft.VisualStudio.TestWindow.VsAdapters.UnitTestExtensionDiscoverer, so I've realized the dll has to end with *.TestAdapter.dll. Using that name makes vstest.console work for me when I specify /TestAdapterPath, so I'm not sure why the VS2013 test window isn't showing my tests.
The adapter does work when installed by copying the relevant files to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\Extensions.
Are there any other path or filename conventions I need to follow for VS2013 to load my test adapter? Without any logging or error messages I'm really not sure how to gather more information to debug this.
The issue seems to have been that I was trying to debug by overwriting my dlls in the packages directory. This doesn't work because VS copies your package directory to something like:
%TEMP%\VisualStudioTestExplorerExtensions\My.TestAdapter.1.0.0.23
essentially caching it with the key being the version number. If you copy the file into the project packages directory VS won't copy it because the folder number didn't change. So, to update your extension you have to keep publishing NuGet packages.
At least that's how I understand it.
Edit: I've also noticed that when you upgrade your test adapter through NuGet, it won't start using the new version until you restart VS, or kill vstest.*
Related
I have a solution in Visual Studio 2015 that uses several NuGet packages. When I build in Visual Studio 2015, the packages are restored properly and the build succeeds. However, when I push that same project to Visual Studio Online, even though I have "Restore NuGet Packages" checked, the build fails because MSBuild cannot find the referenced binary.
I have looked at the build log and see that my packages are all being restored. Why, even though the package is restored, is the referenced binary not found during the build?
I found that the problem was not in the NuGet package restore, but in the way that the hint path was written in my .csproj file. To the fix the problem, change the hint path to point to the solution directory using the $(SolutionDir) variable.
For example, the NuGet restore pulled the Microsoft.WindowsAzure.Storage.dll binary, but it could not be found on the build of the project. To fix this, I had to open the .csproj, find the reference to the dll, and change the path from
..\packages\WindowsAzure.Storage.6.1.0\lib\net40\Microsoft.WindowsAzure.Storage.dll
-- to --
$(SolutionDir)\packages\WindowsAzure.Storage.6.1.0\lib\net40\Microsoft.WindowsAzure.Storage.dll
By using the $(SolutionDir) variable, Visual Studio Team Services was able to find my referenced dll and build my project properly.
You might also consider checking if the file packages.config, which surely resides on you local system, also gets checked in and is under version control.
First, you might want to see if it's present at the build server (image below is from VS Team Services but it's the same general idea in on-site environment.
Secondly, verify that the file's under version control. As a test, see if it appears under Pending Changes if you add a package.
I made a project with a working build start to fail when I added nUnit. Then, as I checked in the package.config file, it started to restore the packages on the server. When I removed the file from the server, the builds starter to fail again. Details are described in this post.
I'm putting together a new stack of unit tests to be run together as a CI job. I'm using vstest.console.exe instead of mstest.exe mainly for its ability to run tests from several frameworks, but right now the focus is a few xUnit dlls. The jobs are run as part of a Jenkins pipeline.
I have tested everything successfully on a couple of dev boxes, but annoyingly test discovery is not working on any of the CI build boxes so far. This is after the addition of the 0.99.8 xUnit test adapter vsix (also tested with 0.99.7). The xUnit dlls are being built against 4.5 with the 2.0.0.2378 beta nuget version of xUnit.
I have reproduced the symptoms with the simplest possible dll, with a single public test method, working fine on my own box, not working on any build boxes. The deployment enviroment is pretty straight forward, with a VS2012 install and the xUnit test adapter, on Windows 2012.
I have enabled the TpTrace logging via the vstest exe config files and everything looks fine. I guess I'm looking for a way to troubleshoot the issue further (maybe tracing for the xUnit discovery process) or a workaround the problem. I'd prefer to retain the use of vstest console for the simplicity of running several frameworks.
I have written up this issue via the xUnit codeplex site as well.
I've checked out this SO post but none of the suggested solutions make sense here.
It takes me quite some time to find the solution of how to use vstest.console.exe and xunit for VS2013, so I think it worth the time to explain here how I did for everyone...
The first step is to follow what is explained here to install the pre-release xunit.runner.visualstudio nuget package in the xunit projects that need it to be able to run the xunit test from Visual Studio.
Then, when you run your vstest.console.exe command, you MUST use the parameter /TestAdapterPath.
Your command line should look like something (the path toward the xunit adapter is here relative so, you could put it in absolute or adapt depending on the active directory):
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" c:\path\to\your\assembly.to.test.dll /TestAdapterPath:".\packages\xunit.runner.visualstudio.0.99.9-build1021\build\_common\"
edit: Because the adapter dlls are copied to the output folder, we could simplify the command line giving the path "." to the /TestAdapterPath option:
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" c:\path\to\your\assembly.to.test.dll /TestAdapterPath:"."
For information, it works also with NUnit, nuget package NUnitTestAdapter and the command:
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" c:\path\to\your\assembly.to.test.dll /TestAdapterPath:"."
OK so problem solved, but after some frustrating troubleshooting that I will cover in case its useful for someone. The problem was that xunit.execution.dll was not available in the same folder as the dlls containing tests. This is required for xunit discovery. I only got here by:
Setting HKCU\Software\Outercurve Foundation\xUnit.net\Visual Studio Test Plugin\MessageDisplay = Diagnostic (this should be possible via the runsettings file but is not being picked up, and not possible via the VS tools options xunit page because its failing to open)
vstest now spits out 'Skipping xunitTests.dll (no reference to xUnit.net)'
This message actually means that xunit.dll and xunit.execution.dll weren't found in the folder
Problem solved by making sure that dll gets copied into that folder on the build boxes.
He have configured NuGet to run as part of the solution, but we have issues with configuration. It seems to only pick the local configuration file from %APPDATA%\..., which is the opposite to what we want it to do (use the config from the version control system, stored with the code). How can I figure out what exactly NuGet is doing when run during the build in Visual Studio? Is there an option for a verbose run, so that it dumps all the paths that it is using, etc.?
you can try to build the solution using msbuild:
"%WINDIR%\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" abcd.sln /t:Build /property:Configuration=Release /v:diag
What I'm trying to do
I currently have a project file that contains a single EF 5 Model with the .edmx configured to embed the metadata into the output assembly.
If I run a local package via Visual Studio 2012, the produced assemblies contain the correct resources. Manually running package through MSBuild also correctly embeds the resources in the assembly:
msbuild web.csproj /t:Package /p:Configuration=Release
When I manually inspect the assembly generated by Visual Studio or by the MSBuild package step with dotPeek, I can confirm that the package contains the .csdl, .ssdl and .msl resources.
The actual problem
I have on hand a build server that is running Microsoft Windows Server 2012 and Visual Studio 2012. If I manually run MSBuild via the Visual Studio 2012 Command Prompt, using the same exact command line as above, then an assembly is generated that does not contain the resources embedded.
Why are my EF metadata files not being embedded when I perform automated packages via MSBuild?
Simple Self Contained Correct Example
A SSCCE which demonstrates the workaround may be found here. The example contains the exact steps required to reproduce the error in the readme.txt.
Using your example, on Windows 8 + VS2012 installed, I was able to generate package using Package.bat and all generated assemblies are contain the all EF metadata files.
In the Readme.txt you are mention the MSDeploy
4) Run MSDeploy /t:package on the project
From your question looks like you have issues with MSBuild.
Could you verify that you don't have old TestEntityEdmx.Hackaround.dll sitting in the TestEntityEdmx\obj\Release... folder when you run build.
I've created a SSIS Custom Task in C# and I'm currently developing the UI. I was wondering if there is a better way of debugging the UI instead of compiling the project, copying the DLL's into the appropriate DTS folder and then opening the test Package within BIDS and then attaching the process to Visual Studio. This part I'm not bothered about but once you've tested the UI and made changes to UI within Visual Studio. I've got to recomplile the DLL's and then repeat the entire process. I've got to close BIDS and VS because they don't release the DLL's before I have to start the entire process over again. Does anyone have any tips to speed up this process. It's just so frustrating having to do this everytime.
Sorry, but that's the only way Microsoft has devised. If you are repeating this process over and over again, I would suggest creating a batch file for all the operations so that instead of doing 5 steps over and over again you just fire the batch file and be done with it.
I thought I would add this. The best way I've found of debugging SSIS components is to:
In the Project Properties under build set the OUTPUT path to the correct SQL Server DTS sub folder and then in Build under the Post Build events put:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\gacutil" -u "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Tasks\$(TargetFileName)"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\gacutil" /if "$(TargetPath)"
Uninstall the assembly using the gac and then resinstall it. The reason I'm uninstalling it is because I was having a lot of trouble with BIDS not referencing the newly inserted DLL. Even restarting my computer it kept referring to the older DLL. I guess is that it had cached it. I'm also using this for developing components for BIDS 2012. I am aware that you don't have to sign or register components with the gac for BIDS 2012 but BIDS was having problems referring to the newly created dll's. By doing this I dont have to close BIDS everytime or delete and readd the component to the design screen.
You would think there was a simpler version.
You may want to read the blogpost by Matthew Roche here. Its quite informative and gives you a better way of doing things.