Tried to create CI build in Azure DevOps. But getting the below message.
No test available in C:\agent...\bin\DEV\projectname.dll
Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.
I have used C# in Visual Studio, with NUnit version="3.12.0". NUnit 3 Test adapter 3.16.1.
It's working fine in my local.
From your description, it could run successfully on your local Visual Studio (contains NUnit 3 Test adapter 3.16.1).
You could try to add this package (NUnit3TestAdapter -Version 3.16.1) to your project. Then this package will be added when you build this project.
For example:
Package.config:
<?xml version="1.0" encoding="utf-8"?>
<packages>
....
<package id="NUnit3TestAdapter" version="3.16.1" targetFramework="net472" />
</packages>
Or xxx.csproj
<ItemGroup>
...
<PackageReference Include="NUnit3TestAdapter" Version="3.16.1" />
</ItemGroup>
You could check if it could work after adding this package reference.
On the other hand, the test Plantform version seems to affect this test.
You could set the test plantform is X64 in the Visual Studio Test Task.
Here is a Blog about the detailed troubleshooting steps.
Hope this helps.
So far I've been developing my project using CLion on Linux and everything worked fine, but now I'm trying to setup my project on Windows to get familiar with the Visual Studio IDE, and I'm having trouble getting Visual Studio to discover my tests.
I'm using the CMake project directly in Visual Studio and things like building, running and etc. work fine, the problem beings when I try to run the individual tests using the Run Test option in the editor - the Test Explorer doesn't see them.
I've installed the Catch2 Test Adapter and added the required .runsettings, as described here but even with that the only things that I see in Tests output is
No tests found to run.
Has anyone tried a setup similar to this and can guide me on how to solve it?
I'm using Visual Studio 2019.
Ok, I got it working by generating a Visual Studio Solution and using it instead of the CMake project, my .runsettings look like this:
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<!-- Configurations that affect the Test Framework -->
<RunConfiguration>
<MaxCpuCount>4</MaxCpuCount>
<ResultsDirectory>.\TestResults</ResultsDirectory><!-- Path relative to solution directory -->
<TestSessionTimeout>60000</TestSessionTimeout><!-- Milliseconds -->
</RunConfiguration>
<!-- Adapter Specific sections -->
<!-- Catch2 adapter -->
<Catch2Adapter disabled="false">
<FilenameFilter>test</FilenameFilter>
<WorkingDirectoryRoot>Solution</WorkingDirectoryRoot>
</Catch2Adapter>
</RunSettings>
Select it in Test Explorer > Configure Run Settings > Select Solution wide runsettings File
The scenario
You add a nuget package, which in turn injects <Import .../> statement into your csproj file which references a targets or props file from the package itself.
This works fine when building the code in Visual Studio, but fails miserably when building the same solution with msbuild.
The root cause
There are several. First, the logic to restore the packages is executed by the VS itself outside of the build proper. We can solve it by importing Nuget.targets which would run the RestorePackage target before the build. Check.
But the second problem is more serious. The Import statements importing targets/props from the packages can only be resolved after the packages are restored. Meaning restoring the packages cannot be part of the build. It must happen before the msbuild is given the solution to build. Yes, Visual Studio does it already, but I do not use Visual Studio on my Gated Check-In or CI server. I need it to work with msbuild.
What one can do?
As far as I understand, I need to be able to run the same logic VS does only on the command line. I.e. identify the packages and restore them before running msbuild. But devil is in details. Cannot be I am the first one to face this problem.
How do you do it?
Found the answer in this blog post - http://sedodream.com/2013/06/06/HowToSimplifyShippingBuildUpdatesInANuGetPackage.aspx
Following this blog I have created before.MySolutionName.sln.targets file with the following content:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Restore">
<Target Name="Restore" BeforeTargets="Build">
<Exec Command=".nuget\nuget.exe restore $(MSBuildProjectName)" LogStandardErrorAsError="true" />
</Target>
</Project>
Now all the packages in the solution are restored before the build.
Thank you, Sayed Ibrahim Hashimi.
I developed a single plugin for on-premise crm 2013 (PreCreateOpportunityProduct - nothing special). In my visual studio crm solution I added a project (called BusinessLogic) that includes my generated Entities.cs as well as partial classes for each entity. Therefore I can encapsulate the logic for one special entitiy in one separate class. No big deal so far.
Now I want to use those logic, therefore I add the project reference in my plugin project. I know that I need to merge all needed DLL's to one, so I added a post-build event to merge all dll's with ILMerge.
Overview of Solution / Project with used DLLs:
The post-build command looks as follows:
mkdir "$(TargetDir)Merged"
"$(SolutionDir)Libs/ilmerge.exe" /keyfile:"$(ProjectDir)keypair.snk" /target:library /copyattrs /targetplatform:v4,"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0" /out:"$(TargetDir)Merged\Flag.Plugins.dll" "$(TargetDir)Flag.Plugins.dll" "$(TargetDir)BusinessLogic.dll" "$(TargetDir)Microsoft.Crm.Sdk.Proxy.dll" "$(TargetDir)Microsoft.Xrm.Sdk.dll"
del "$(TargetDir)*.*" /Q
move "$(TargetDir)Merged\*.*" "$(TargetDir)"
The RegisterFile.crmregister:
<?xml version="1.0" encoding="utf-8"?>
<Register xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/crm/2011/tools/pluginregistration">
<Solutions>
<Solution Assembly="Flag.Plugins.dll" Id="f4dff197-5b7a-e411-80c3-005056ba5a51" IsolationMode="None" SourceType="Database">
<PluginTypes>
<Plugin Description="Plug-in to PreOpportunityProductCreate" FriendlyName="PreOpportunityProductCreate" Name="Flag.Plugins.PreOpportunityProductCreate" Id="0f7bd0bc-2b7b-e411-80c3-005056ba5a51" TypeName="Flag.Plugins.PreOpportunityProductCreate">
<Steps>
<clear />
<Step CustomConfiguration="" Name="PreOpportunityProductCreate" Description="Pre-Operation of Opportunity Product Create" Id="107bd0bc-2b7b-e411-80c3-005056ba5a51" MessageName="Create" Mode="Synchronous" PrimaryEntityName="opportunityproduct" Rank="1" SecureConfiguration="" Stage="PreInsideTransaction" SupportedDeployment="ServerOnly">
<Images />
</Step>
</Steps>
</Plugin>
</PluginTypes>
</Solution>
</Solutions>
<XamlWorkflows />
</Register>
Note: I am Deployment Manager + System administrator -> all permissions
When I click Deploy on CrmPackage project, the error
Error registering plugins and/or workflows. Plug-in assembly does not contain the required types or assembly content cannot be updated. C:\Program Files (x86)\MSBuild\Microsoft\CRM\Microsoft.CrmDeveloperTools.CrmClient.targets
Note 2: When I deploy the plugin.dll without merging all the other DLLs the deployment works like charm, but the plugin throw the exception because the BusinessLogic.dll is not known.
Can anyone help me with this issue?
Thanks in advance
I found the problem: I was merging too many files! In detail: It was the Microsoft.Crm.Sdk.Proxy.dll and Microsoft.Xrm.Sdk.dll. Those libs are already in the crm server GAC. After removing those files from my ilmerge command, the deployment finally works.
Here is the link which gave me the important hints:
https://community.dynamics.com/crm/f/117/p/146347/326928.aspx#326928
I've run into a recurring problem with a few different projects using MSTest in VS2012, where every now and then my code coverage stops working (seemingly at random) and instead gives me:
Empty results generated: No binaries were instrumented. Make sure the
tests ran, required binaries were loaded, had matching symbol files,
and were not excluded through custom settings. For more information
see http://go.microsoft.com/fwlink/?LinkID=253731
I've checked the obvious (what it's suggested) but can't seem to figure out what is causing it.
Here is my runsettings file:
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<DataCollectionRunSettings>
<DataCollectors>
<DataCollector friendlyName="Code Coverage"
uri="datacollector://Microsoft/CodeCoverage/2.0"
assemblyQualifiedName=" Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector,
Microsoft.VisualStudio.TraceCollector,
Version=11.0.0.0,
Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a">
<Configuration>
<CodeCoverage>
<ModulePaths>
<Include>
<ModulePath>.*\.dll$</ModulePath>
</Include>
<Exclude>
<ModulePath>.*\.tests.dll</ModulePath>
</Exclude>
</ModulePaths>
<Attributes>
<Exclude>
<Attribute>.*ExcludeFromCodeCoverageAttribute$</Attribute>
<Attribute>.*GeneratedCodeAttribute$</Attribute>
</Exclude>
</Attributes>
<UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
<AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
<CollectFromChildProcesses>True</CollectFromChildProcesses>
<CollectAspDotNet>False</CollectAspDotNet>
</CodeCoverage>
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
</RunSettings>
I just ran into this using Visual Studio 2019. The solution was to go to the "Test" menu item in VS and then update the Test -> Processor Architecture for AnyCPU Projects setting from X86 to X64.
This link solved my issue: Issue with Code Coverage in VS 2012
Close Visual Studio 2012, find the .suo file, delete (or rename) it, restart. Worked fine. No idea what is in the .suo file that prevented proper coverage analysis.
If you can't make the Code Coverage to work even after you've deleted the *.suo file, please check your Event Viewer for errors. In my case, after each run I had the following error:
"TraceLog Profiler failed in initialization due to a lack of instrumentation methods, process vstest.executionengine.x86.exe"
I've found the answer here.
In case the link is no longer available, I'm pasting the content in here:
If you find yourself with a an empty .coverage file and see errors
similar to the below in your event logs you most probably have a
corrupt install
(info) .NET Runtime version 4.0.30319.17929 - The profiler has
requested that the CLR instance not load the profiler into this
process. Profiler CLSID: '{b19f184a-cc62-4137-9a6f-af0f91730165}'.
Process ID (decimal): 12624. Message ID: [0x2516].
(Error) TraceLog Profiler failed in initialization due to a lack of
instrumentation methods, process vstest.executionengine.x86.exe
Check
a) Environment variable VS110COMNTOOLS is set to
\common7\tools
b) Regkey HKLM\SOFTWARE\Microsoft\VisualStudio\11.0\InstallDir is set
to your \Common7\IDE\
c) covrun32.dll and covrun64.dll exist in "\Team
Tools\Dynamic Code Coverage"
Good luck,
Nadav
I had a similar problem after running PerfView.
Re-running perfview having copied it into a folder of it's own and starting a collection run, followed by stopping it seems to have fixed the issue.
I was getting 0x8007007e errors loading the profiler with a guid of {9999995d-2cbb-4893-be09-fce80abc7564} (Vs2015 profiler) and {6652970f-1756-5d8d-0805-e9aad152aa84} (perfview profiler)
Hope that helps someone else.
There appears to be a bug in Microsoft.NET.Test.Sdk 16.3.0+ which results in the same error output and currently the workaround is to downgrade to 16.2.0 which worked for me. In addition to the troubleshooting tips MS provides here there may be SDK issues.
In my case, the issue was that my test dll path contained the string "DataCollector" and seems coverlet has an internal ignore over any path that matches something like .*DataCollector.*
I modified the Property group associated with my debug environment so that it looks like this:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<DocumentationFile>OurProjectName.xml</DocumentationFile>
<DebugType>full</DebugType>
<DebugSymbols>true</DebugSymbols>
</PropertyGroup>
For my core.net 3.1 application running xUnit 2.4.1 this was the only thing that fixed it in visual studio 2019 preview.
Configure Test -> Processor Architecture >> AnyCPU Projects setting >>> X86 to X64.This works for me
I was also facing the same issue and tried out all the above options but it did not work for me.
I could solve this problem only after creating full debug information. The settings for full debug information may vary from version to version. As I am using MSVS 2017, in the build menu there is a submenu which allows to have the full debug version.
I hope this will help others as well.