I have created a release pipeline in azure for my .Net core test project. I am using runsettings file to store test inputs for my selenium automation project.
While running the pipeline it's getting failed with error - Assembly Initialization method Tests_MSTestAssemblyHooks.AssemblyInitialize threw an exception. System.Exception: System.Exception: Unit test Provider already set. Aborting test execution.
This is the same error in Visual studio when we don't select runsettings file from Test> Configure Run Settings. From this I guess, it is not able to find runsettings file.
I have mentioned runsettings file in VsTest task. As it didn't work, then I also added Copy file task in the release pipeline.
Here are some more screenshots from VsTest task log - 1, 2, 3 as I am not able to attach the file here.
I am using MS Test as a test framework and a self-hosted agent pool if that matters.
I had one unloaded unit test project in my solution which is using NUnit adapter. Nuget restore in my build pipeline was installing it. When release pipeline was dropping all assemblies in single folder, where MSTest and NUnit adapters were present. Test started executing its getting conflict between these adapters, as a result tests were not able to find runsettingsfile.
I removed that unit test project and it started working.
Related
I've a legacy project, which is a ASP.net Website project(not having .csproj file). It holding .aspx files and packages.config for nuget and other dependencies. Now I want to deploy it to Azure app service by automation with CI/CD in Azure Dev Ops pipeline.
I can't find anything which is suitable for all tasks I need for CI.
Here I don't have .csproj, so I build it using packages.config
Task I tried
Update .sln to .config, because I have more than one website in single solution.
Update Nuget Restore task with install, it doesn't work with restore
And while queue, this pipeline got failed on Build task
Error it thrown
Visual Studio Build task cannot build packages.config file, this task uses MSBuild to build. In Solution argument, only .sln file or .*proj file can be specified.
Solution: Required) If you want to build a single solution, click the
... button and select the solution.
If you want to build multiple solutions, specify search criteria. You
can use a single-folder wildcard (*) and recursive wildcards (**).
For example, **.sln searches for all .sln files in all
subdirectories.
You can also build MSBuild project (.*proj) files. If you are building
a customized MSBuild project file, we recommend you use the MSBuild
task instead of the Visual Studio Build task.
Default value: ***.sln
I tried to switch from Visual Studio to Visual Studio Code with my CORE project. I can build the C# project in Visual Studio without any problems. When I tried VSCode, I see that I need to define tasks. Fortunately, VSCode offers default tasks definition (it generates tasks.json) for me, so I tried them (there are variants for CORE and .NET, as I understand). But both don't work. I tried to make build from command line, but get error (I translate the error to English, it's not original text):
C:\Program Files\dotnet\sdk\2.1.700\Microsoft.Common.CurrentVersion.targets(3046,5): error MSB4216: can not execute task "GenerateResource", because MSBuild cannot create tasks server with execution environment "CLR4" and architecture "x86" or to connect to it. Verify that, (1) required execution environment and architecture do exist and (2) required executable file "C:\Program Files\dotnet\sdk\2.1.700\MSBuild.exe" exists and can be ran. [D:\prj\...\Test.csproj]
and when I tried to find MSBuild.exe in this folder, I found MSBuild.dll only, no any MSBuild.exe. So, I tried to run it with dotnet after entering this folder - it works. But if I try to call dotnet build or to run it with full path to MSBuild.dll from my project folder, I always get this error. Seems, that dotnet command calls MSBuild.dll multiple times and always hit this problem. May be I should setup some paths or similar. But where to do it (without to break ability to build the project in Visual Studio)? What is the convenient way to build CORE projects in Visual Studio Code? How to build them in command line?
PS. May be all documentation which I found was outdated...
I have codedUI and unit tests in my solution. Solution and the unit tests are successfully building in TFS 2017. CodedUI tests fail. I get an error.
Failed to initialize the unit test extension 'urn:CodedUITest': A unit test extension is not registered for the following attribute: Microsoft.VisualStudio.TestTools.UITesting.CodedUITestAttribute.
All the tests successfully pass in my local machine. What configuration am I missing in my build process?
kindly, help!.
According to the error info, seems the issue should more related to build agent Environment setting. Make sure you have Visual Studio and Coded UI features installed on the build agent. You could double check this by remote to the build agent and manually run Code UI in the agent machine instead of through TFS build.
If you are using Nuget Visual Studio Test Platform Installer , this is not support for now, take a look at the similar issue: VSTS build release agent unable to run Coded UI tests when using the Nuget VsTest platform
Currently Coded UI and UWP tests not support with VSTest platform
nuget package. /cc #PBoraMSFT for blog/doc and timeline for support.
Hi I have a set of MsTest tests that runs with NHibernate, SQLLite.
I can succesfully load the assemblies from any DEV machine and run the tests.
On TFS we have a drop folder where we put all the assemblies and a copy of MsTest.exe, where we run the unit tests from.
The problem I get on TFS is the following:
Unit Test Adapter threw exception:
Type is not resolved for member 'NHibernate.HibernateException,NHibernate,
Version=3.3.1.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4'..
But this assembly and the related dependencies are copied to the drop location, so I don't understand why MsTest can't load this assembly.
I run the tests using this command in MsBuild:
mstest /testcontainer:"mydll.dll" /detail:errormessage /detail:errorstacktrace
But unfortunately I can't see the real error, I guess it is related to SQLLite.
Background
I am utilizing the following:
VS 2012
.NET 4.5 apps including an MVC4 app, a C# Domain app, and NUnit projects.
A custom MSBuild File
CruiseControl.NET running on a build server
I have the following build targets:
Clean: deletes the buildartifacts directory
Init: creates a blank buildartifacts directory
Compile: compiles the solution
Test: runs NUnit Tests
Package: creates a ZIP package for deployment
Deploy: Deploys package to a remote IIS Server
Problem
When I run the build from my local machine, it packages and deploys perfectly.
When CCNet runs the same build target, the files appear to be deployed
Attempted Resolutions / Potential Leads
I have run the same target in PowerShell from both machines and have seen no errors or warnings on either.
Because I tell CCNEt to override the framework to point it to the .NET 4.5 files I've copied to the build server, I made my local machine point to the same files when running MSBuild but my local build still worked and deployed.
In Visual Studio, I have ensured that all content files are marked with a Build Action of "Content" and a Copy to Output setting of "Copy Always".
The Code
Available in a gist at https://gist.github.com/53ef2a63931d190593f6
(file has been scrubbed, app name & credentials replaced, etc.)
It turns out, this was a completely unrelated issue.
After doing a diff of both build logs, I noticed that the build server working copy contained old files that no longer existed. This led me to discover that the issue ended up being that the repository wasn't being updated.
CCNet was receiving a subversion error that wasn't registering as an error
As a result, I was never getting the latest version of the repository, and so all files were broken.
The error is related to this StackOverflow question, regarding a sqlite error when attempt to use tortoisesvn to update. The solution in my case was to simply delete the build server's working copy, recreate the folder, and perform an svn checkout.