Recently I came to know about the nuget based adapter/runner (http://xunit.github.io/docs/running-tests-in-vs.html)
I was trying to understand how these runners/adapters are recognized by Visual Studio and then used by the TestWindow.
For example, if I install "xunit.runner.visualstudio" nuget package all the xUnit based tests in my project are discovered and displayed in the Test Window.
I am trying to understand how does VS hook the Test Discovery using the package installed in packages folder?
Where/how do VS and nuget based adapter get hooked?
I tried finding this information but my google fu failed me. :(
I checked answer for the question (Custom test adapter installed via NuGet isn't discovering tests) and it does say that VS copies the packages to the path %TEMP%\VisualStudioTestExplorerExtensions but that's pretty much it.
Since this involves a lot of how VS works internally, I don't think you'll get a totally definitive answer. However, to solve the issue you linked to I looked at a bunch of disassembled code, so I have a pretty good idea. Here's how it seems to work:
You build a project that references a package named Sample.TestAdapter
VS copies Sample.TestAdapter directory from packages to %TEMP%\VisualStudioTestExplorerExtensions
Something triggers test discovery - rebuild always does, sometimes incremental builds do too. vstest.console.exe is useful here for debugging.
VS launches vstest.discovery.exe which looks in VisualStudioTestExplorerExtensions for an assembly that implements ITestDiscoverer
If an ITestDiscoverer is found, VS calls it with a list of assemblies that may contain tests
Tests that are discovered are sent back to VS by your test adapter
So, as far as I can tell it's a pretty simple reflection based plug-in architecture. Hope that helps.
Related
I've had a problem with my Windows 7 after an update, neither Safe Mode nor Recovery Mode could resolve the problem. I was forced to reinstall Windows completely. To develop on my projects I need Visual Studio 2010.
I always had ReSharper installed and got used to its features, so I installed it aswell.
Everything setup I tried building my solution but encountered a problem ...
(The underlined file can be found here: https://up.zone/aj)
After hours of trying to resolve the problems, I figgured out that ReSharper was the problem. I can build the solution perfectly fine without ReSharper installed. Having it installed, even if all features are turned off and the services are suspended, causes these errors in the picture above to show on build.
I managed to resolve two out of three errors by following the instructions of this Reddit user on his post: https://up.zone/ag
Now I am left with one more exception I cannot figgure out how to resolve. I couldn't really find anything helpful googling, which means you guys are my last hope. I really do not want to go back to developing without ReSharper.
This is the one:
Any idea?
Thank you!
Update 1
I figgured out that the problem must be in the NuGet.targets file, located in the .nuget folder in our solution.
I managed to find a workaround following the suggestion of this post, I am now able to build the solution without any errors.
To summarize, remove this line out of your *.csproj file
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Although this works, I don't think this can be the solution. This line is there for a reason I assume. Anybody with a deep understanding of NuGet who might know how to properly resolve this problem?
Update 2
I found out that as soon as you reload your solution/project, the line gets added once again. Also, if you have certain dependencies nuget should download for you - it won't, because the line which makes that call and handles this got removed.
I'm now at a point where I know where the problem is but not why it is caused.
Does ReSharper change anything in the way NuGet behaves? As far as I can tell, nothing gets added or removed to or from the NuGet.targets file due to ReSharper.
There were one more report on this topic, at https://youtrack.jetbrains.com/issue/RSRP-462271 .
The best guess so far is that this is caused by two things happening at once: (a) using MSBuild tasks in C# source code form inside MSBuild XML files rather than DLLs and (b) having some of the MSBuild opensource DLLs shipped with the latest version of ReSharper for its own project file handling needs.
The source code gets compiled into a task DLL during an MSBuild run (not a much common thing to have; Roslyn would do this rather than ship a DLL? seriously?). When building from within Visual Studio (rather than with msbuild.exe), the in-process MSBuild instance is used, and it would run in the same appdomain as ReSharper, so it uses the common assembly reference resoluiton. If it's not too accurate, then it might accidentally pick the wrong DLL version by the short name, which would break the task compilation (that's a separate error, maybe cached away) and then result in the task-not-found error later at runtime (SetEnvironmentVariable task not found in here case).
I've tested on sample solutions with source code based tasks and could not get it broken. So trivial cases are OK. Never heard back from the original issue reporter, so there was no further progress.
Now I've got a hint that this is Visual Studio 10 (any other VS versions installed on that machine?) and maaaaybe it's Roslyn tasks. We might know for sure if you run MSBuild with more detailed logs (by setting the logging options at Tools | Options | Projects and Solutions | Build and Run | MSBuild project build output verbosity to at least Detailed) and building just the faulty project.
I'll also try this out with VS10 and update this reply with new data.
I have a C# project in which I have a COM Reference. It compiles fine when opened in VS 2013. But, it fails as part of TFS build definition.
TFS version : 2013
TFS Build Controller & Agent : 2013
VS version : 2013
The failure message says that it could not find the Interop dll. I cannot manually create the Interop dll and check-in into TFS because it would keep changing and I want my C# project to always take the udpated COM reference.
I tried the COMFileReference suggestion but it did not solve my issue. I even manually registered the COM dll using regsvr32 but still I am facing the issue.
Any help is highly appreciated.
Regards,
kvk1985
A COM reference is the safest way to ensure that your program matches the actual installed component when you test your code. The compiler will read the type library of the component, a very similar mechanism that's used for normal .NET assembly references. Except that the type definitions come from the type library instead of .NET metadata.
But has a disadvantage in your case, it can only work when the component is actually installed on the machine. That probably did not happen on that build server. That's fairly normal, the people that maintain build servers don't particularly like anybody messing with it. And it is a maintenance headache, the build breaks when the devs update their machine with the latest version but forget to update the build server as well. And old builds get to be hard to reproduce.
So installing the component on the build server is the Quick Fix. If that's an insurmountable obstacle then somebody needs to run Tlbimp.exe on their machine. That generates the interop assembly, it needs to be checked-in to source control. And the project must be modified, remove the COM reference and add the reference to the generated interop library. It will now build the same way on the build server and the dev machines.
That's of course brittle the other way, if a dev updates the component on his machine then there will be a mismatch with the interop assembly. That can be a very ugly one, an E_NOINTERFACE runtime error if the COM vendor did it right, something excessively nasty like calling the wrong method, a stack imbalance or an AVE if he didn't. Otherwise the exact same kind of failures that can occur if the user's machine doesn't have the right version of the component installed. Standard DLL Hell.
You'll have to make the call yourself, there's no One Right Answer.
Certain nuget libraries seem to force my project to rebuild (as in run fsc.exe to produce a new binary) every single time I build the solution, even if nothing at all has changed. As soon as I delete the reference in the Visual Studio references tree, fsc.exe is no longer called until I actually make a change.
I don't actually need any code at all to reproduce this problem - an empty main function in a project referencing a problematic library will face this issue.
After some trial and error two nuget libraries which definitely cause this problem are:
FSharp.Actor-logary
Newtonsoft.Json.FSharp
but it may well apply to others.
I read in a comment elsewhere on stack overflow that type providers always force recompiles, is that true? My empty test project doesn't use type providers, but maybe these libraries do.
I am using Visual Studio 2013.
I think I've solved it: the problematic libraries have a last modified date of 15/12/2030
I've opened an issue on the project's GitHub page: https://github.com/logary/logary/issues/74
This has been solved when MSFT fixed their assembly-generation bug in mono.
I am trying to build MSIs in a TFS Build by shelling out to DEVENV.exe (since MSBUILD does not support VSPROJs). In any case, my first installer project builds fine, the second one fails. If I reverse the order, same thing happends (i.e. the error does not follow the project). Looking at the output, I get the following errors:
Deserializing the project state for project '[MyProject].dbproj'
[MyProject].dbproj : error : Error HRESULT E_FAIL has been returned from a call to a COM component.
Also, I get:
Package 'Microsoft.VisualStudio.TestTools.TestCaseManagement.QualityToolsPackage, Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' failed to load
It looks as though the first build tries to serialize the DB project (and it says it succeeds, but there is no DBML file anywhere). Then the second build tries to deserialize the DB project and fails.
I've tried resetting env settings (using the /resetusersettings flag) as well as using the /resetskippkgs flag. Nothing works.
Any ideas?
When you shell out to DevEnv, are you building that specific project (.vdproj file), or are you building the solution? It sounds like VS is trying to open the solution on the build machine and the database and test project systems aren't present.
Have you considered porting your setup project to WiX?
Start simple. Unless you're well versed in the problem you're trying to solve it's usually best to try it "by hand" before getting it running as part of a TFS build. RDP into the build server and try running the necessary commands at the command line and see what happens. You can even go simpler than that and RDP into the build machine and load Visual Studio and build it.
Bottom line is that if you can't get it to build within Visual Studio or at the command line by calling devenv.exe it won't work as part of the team build.
I am using the below Exec task to do precisely what you are doing as part of a TFS build. So I know this works. Your platform and configuration may vary depending on what you're building. The nice thing about this is that you'll have a log file at C:\Temp\MSIBuildOutputLog.txt that you can analyze for additional errors and information.
<Exec Command=""C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" "$(PathToSolution)\solution.sln" /Build "Release|Mixed Platforms" /out "C:\Temp\MSIBuildOutputLog.txt"" />
One important thing to note... There is a bug in VS2010 which causes MSI generation to fail when you try to run it at the command line using devenv.exe. This took me days to find and figure out, but you need this hotfix. Worked like a charm...
http://archive.msdn.microsoft.com/KB2286556
Actually it's the deployment projects that don't support msbuild. FWIW, this is all deprecated in the next release of Visual Studio so you might want to start looking at InstallShield Limited Edition and/or Windows Installer XML now before spending too much time on dead end, broken technology. Both of these alternatives have proper MSBuild support aswell as many other improvements.
It would be perhaps better and quicker to adopt WIX (Windows Installer XML) which is the technology MS now recommends to use within VS/MSBuild/TFSBuild environment to crate MSIs.
It is relatively easy to setup and integrate within your VS Solutions. It uses XML based files to describe your MSIs and uses these files to create your MSIs when you compile.
I would start by downloading Wix from http://wix.codeplex.com/
Once installed you would be able to use the VS2010 integration of Wix based projects to create MSIs. To get started quickly simply add a new Wix project to your solution and reference the projects whose output you wish to combine into an MSI. Next you can run a tool called "Heat" which is included with Wix toolkit to generate the XML files by scanning your projects.
Once you have these XML files, add them to your Wix project and compile.
I'm in the process of upgrading our VS 2008 solution to run on VS 2010
I managed to successfully build in VS 2010
My next step now is to configure a build machine running TFS 2008
Whenever I start a build it does my projects in alphabetical order with no regard for dependencies. I've googled a lot and I can't seem to find a solution to this.
The closest solution to my problem is found here: msdn link which links to this: dependency solution
However I'm dealing with 129 projects, so I would really rather not do this all manually in the xml.
Has anyone been able to effectively remap the dependencies in a way which msbuild recognizes without manipulating the xml for days...?
It turns out that the conversion to VS 2010 makes the build agent have to use the .NET 4.0 version of msbuild.
So I followed the steps outlined here and it worked: Building .NET 4.0 Applications Using Team Build 2008. Keep in mind that those instructions were written during the beta and the path is now v4.0.30319.
This was required even though all my projects are targeting 3.5
Basically I had to make a one line change and now everything is happy (still working on getting my build to pass but the order is good). It had nothing to do with dependencies not being preserved, simply that the way dependencies were being managed wasn't understood by msbuild 3.5
We also have a large number of projects. We wound up (programmatically) creating a MasterSolution.sln file that contained all of the projects. We also require our developers to only use project references in their code. This way, MSBuild always gets the correct order as it parses the .sln file.