While i'm locally get the error in a unit test:
Mixed mode assembly is built against version 'v2.0.50727' of
the runtime and cannot be loaded in the 4.0 runtime without
additional configuration information
And the solution is to add
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
to the config file located in
c:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE
\CommonExtensions\Microsoft\TestWindow\vstest.executionengine.x86.exe.config
This still is going wrong on our TFS2012 build server. I also added the startup tags to the file on the TFS2012, but the build server reports the error.
How do I get this to work on a unit test project (using the new unit test framework of VS2012 & TFS2012) in a build definition?
While having problems to get it running on TFS too, you might give it a try to set it programmatically (e.g. using this approach). While I would not recommend using that in productive code it should be perfectly sufficient when it comes to UnitTests.
Related
All our unit test projects (About 8 of them) just stopped compiling and I can't find any good reason for it.
"error CS0234: The type or namespace name 'VisualStudio' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)"
From the TeamCity (v2017.2.2) build log the projects are missing the Microsoft.VisualStudio.QualityTools.UnitTestFramework DLL with error codes CS0234 and CS0246. I can't see any code changes that could have caused it
there was however a server restart that might have kicked in some pending changes.
What has been checked
Checked both with a Visual Studio (SLN) and MSBuild runner step, both gave the same results (MSBuild was previously working fine while the Visual Studio was failing on the C# 6/7 code, the reason why we changed to a newer MSBuild version)
These Test projects build fine on the same build server if the solution is opened in Visual Studio 2017 Enterprise (Installed on Build server)
Project Reference configuration
<Choose>
<When Condition="('$(VisualStudioVersion)' == '10.0' or '$(VisualStudioVersion)' == '') and '$(TargetFrameworkVersion)' == 'v3.5'">
<ItemGroup>
<Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
</ItemGroup>
</When>
<Otherwise>
<ItemGroup>
<Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework" />
</ItemGroup>
</Otherwise>
</Choose>
MSBuild Version
We use the MSbuild v15.6.82.30579 in Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin not the default one in C:\Windows\Microsoft.NET\Framework64\v4.0.30319 (Added as such to environmental variables)
Any recommendations will be appreciated. I really don't want to start adding DLL's to the GAC if it can be helped.
If you are using Build Tools 2017 on your server, and you don't have Visual Studio 2017 installed, then you have to switch to MS Test v2:
https://blogs.msdn.microsoft.com/devops/2017/09/01/upgrade-to-mstest-v2/
https://www.nuget.org/packages/MSTest.TestAdapter
https://www.nuget.org/packages/MSTest.TestFramework
Old MS Test framework is not supported with Build Tools.
Then in TeamCity in Build Step you have to change your runner type to Visual Studio Tests, Test engine type from MSTest to VSTest, and Test engine Version to VSTest 2017
Install "VC++ 2017 version 15.7 v14.14 toolset" component under individual components, seems that the default toolset does not have the unit test binaries.
References:
Unit test files not installed by Visual Studio Build Tools 2017
Okay so the issue seemed to be broader than just Unit Tests. In short even though MSbuild and Visual Studio build (from the build server) running MSBuild step from Visual Studio does not utilize the same 'shared' folders.
I had to make use of a couple of different strategies to sort out version and missing common DLL's:
Update the Visual Studio Build Tools to the latest version i.e. get the latest version of MSBuild to the build server and ensure it is added to the OS environmental PATH (Set the default MSBuild to be the new one). In my case it was changing it from 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319' to 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin'
Add the missing/newer DLL to the MSBuild BIN folder and mark it as read-only so that it is not overridden again
As last resort you add the DLL to the GAC using the gacutil.exe. This is not recommended because it obfuscates the relationship (Rather try to find where it is used with Fusion logging and add it there).
I am running into an weird issue where my build works perfectly on local machine but almost always fails on Visual Studio Team Services build agent. I say almost always the same code sometimes builds fine on VSTS build agent.
The error is that for a project in my solution, the compiler could not find System.Web.Http.dll, which is referenced in Microsoft.AspNet.WebApi.Core NuGet package. I've checked the reference and it is there. I've removed the NuGet and re-added it to fix any potential NuGet hiccup.
The exact error is this:
Error CS0234: The type or namespace name 'Http' does not exist in the namespace 'System.Web' (are you missing an assembly reference?)
The reference is in the csproj file:
<Reference Include="System.Web.Http, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\Microsoft.AspNet.Cors.5.2.3\lib\net45\System.Web.Cors.dll</HintPath>
</Reference>
The NuGet restore task from VSTS suggested that all NuGet packages were installed, but the build still failed.
I then did a diff between the command lines of the successful build and failed build, both from Visual Studio Team Services build agent and found that the failed build CoreCompile task was missing some assembly references.
CoreCompile gets the assemblies to reference from ResolveAssemblyReferences. But ResolveAssemblyReferences claims that it could not find System.Web.Http.dll.
For SearchPath "{HintPathFromItem}".
Considered "....\Microsoft.AspNet.WebApi.Core.5.2.2\lib\net45\System.Web.Http.dll", but it didn't exist.
Is there any known issue with NuGet restore from VSO? We are using NuGet 4.0.
UPDATE:
Visual Studio Team Services support came back to me. I had my own nuget.config which had the following 2 lines. This interfered with the global NuGet cache on the build agents. Once I removed these 2 lines everything went smoothly as expected.
<add key="globalPackagesFolder" value="..\nupkgs" />
<add key="PackageSaveMode" value="nuspec" />
It looks like, at some point, this reference was added manually, and the relative paths match up on your local PC.
In every valid nuget reference I've seen, those relative paths are prefixed with "packages". Try deleting the nuget package, and delete this reference, then reinstall it.
Here is the answer to the issue I ran into.
Visual Studio Team Services support came back to me. I had my own nuget.config which had the following 2 lines. This interfered with the global NuGet cache on build agents. Once I removed these 2 lines everything went smoothly as expected.
<add key="globalPackagesFolder" value="..\nupkgs" />
<add key="PackageSaveMode" value="nuspec" />
I am working on a C++ project and I developed a few test cases. I was able to execute the test cases until suddenly all the test cases disappeared from the test explorer. I mean to say that test methods are not shown in test explorer even though the test project is compiled properly.
I followed the steps given here with no success.
These are the things I have done:
I deleted the content of %temp% folder.
I changed the default Processor Architecture to X64. (Test>Test Settings>Default Processor Architecture>X64)
Restarted the VS2015.
Restarted the system.
I tried running devenv /safemode (in command prompt), no luck.
I tried running devenv /ResetSettings (in command prompt), no luck.
Notes:
There is only 1 test project in my solution and it only contains a few tests right now.
My project files are located on a network drive since I am not allowed to store on local.
I cannot disable the anti-virus software or firewall and I don't have admin rights on my system.
Look into your .vcxproj file and make sure it says
<ClCompile Include="[your-file-name].cpp" />
for each of your files.
I have a project upgraded from Visual Studio 2010 to 2012 and the .testrunconfig file was included in the upgrade process.
I noticed that it was possible to click "Analyze code coverage" on any of the unit tests that I had run and it would correctly display the result. However, my test run configuration (originally from VS 2010) had code coverage disabled.
After doing a bit of research I learned that the VS 2010 configuration files have been deprecated and replaced by .runsettings files. It would appear that VS 2012 enforces assembly instrumentation by default which has a massive overhead associated with it.
Therefore, I would like to know how I can disable code coverage in VS 2012. Based upon my current findings it does not seem to be a trival task. One recent article I read had me creating an XML file manually and naming it "MYCONFIGURATION.runsettings" and manually manipulating XML attribute values.
Does anyone know how this should be done?
This is what I understand from your post:
You have a Test project with .testsettings file. You have not enabled code coverage in the test settings.
Code coverage instrumentation is not enabled by default in your scenario. Binaries will be instrumented if you do 'analyze code coverage' from VS.
Additional Info:
You can confirm that .coverage file is not generated by running the following command from visual studio developer command prompt:
vstest.console.exe /Settings:<your test settings file> test.dll
A coverage file will only get generated if you have enabled coverage in test settings.
Code coverage is only enabled through the Test Explorer using data driven adapters. The metadata for tests ran through the test explorer is almost completely different than that of tests ran straight from the unit test session window. Have you tried simply running it straight from the code (the MSTest gui bubbles) or from the unit test session window?
How do you enable code coverage for unit testing in TFS2010 automatic build?
In Visual Studio 2010 we enabled Code Coverage for our test projects (Test --> Edit Test Settings --> Local Test Settings --> enable Code Coverage and choose assemblies to run code coverage against).
Now this is working fine (we can read code coverage) when running from Visual Studio 2010 (Test --> Run --> All Test In Solution).
The problem is that no code coverage is reported in TFS 2010 when building.
Note that the test projects are used by the build controller but without any code coverage.
Is very important for us to enable code coverage together with unit testing.
I forgot to mention that the problem I'm encountering has to do with code coverage for a web application project.
At step:
Test --> Edit Test Settings --> Local Test Settings --> enable Code Coverage and choose assemblies to run code coverage against
when choosing assemblies you can choose the web application. I think that the problem is related to Path (the value under the Path column from wizard) which is the one from developer machine (http://localhost...). When building and deploying with TFS the build goes on one server and the deployment on another.
The question should be now: which path should be available in testsettings. The build path or the deployment path?
Currently I'm not at work and can't test my doubts.
I'll let you know as soon as I get in touch with TFS.
You need to tell the build server which test settings file to use. You will find this in the build settings under Process >2. Basic >Automated Tests >1. Test Assembly >TestSettings file.
Once you have that specified then the Code coverage should work.