Iam trying to push my asp.net(mvc) code azure devops using Git bash, but I am getting VSBuild error saying:
Error: Preparing the test sources file failed.
Error: No test sources found matching the given filter '**\*test*.dll,!**\*TestAdapter.dll,!**\obj\**'
VsTest task failed.
That error should be separate from a git push.
Meaning:
you are pushing your sources
but your Azure pipeline might not be correctly configured
See this thread for instance:
From this error (No test sources found matching the given filter '**\*,!**\obj\*'), we can see that you release pipeline do not get the build Artifacts sources.
So you need add a "Copy Files" task before your publish task in the build pipeline:
Or add a "Copy Files" task before your "VsTest" task in the release pipeline.
If it still an issue for you, please share your Organization name and log in account.(please choose "viewable by Microsoft Only")
See also "Publishing test assemblies with artifacts in order to use them during functional tests on VSTS", and this thread, which illustrates a correct pipeline configuration:
From the error we know that Vstest task failed to find the test assemblies.
It may because the test files you defined in Test Files field is incorrect, or you specified a wrong search folder where the test assemblies are not exist. For below example. Vstest task will search for all the files that matching *test*.dll in folder $(System.DefaultWorkingDirectory)(eg. c:/agent/_work/1/s). Check here to find more predefined variables.
The fix is simple if you know where the test assemblies is copied by VsBuild task. You can check the log of Visual Studio Build task, to find out where the test.dll files are located.
Hope you find above helpful.
Related
On a Windows machine there is a GitLab-Runner run from a domain user with admin rights. When I log as this user and call dotnet build -c release to build an ASP.NET Core app, the dll has all the information from the AssemblyInfo.cs file. When I do the same as part of a CI job, the produced dll is missing all this information (for example the version number).
The AssemblyInfo.cs file is not part of the repository, instead, it is produced by a prebuild event (using gitWCRev.exe tool). However after running some tests I can see that the AssemblyInfo.cs is actually generated when the job is run by the runner.
Any help as to why the file is ignored and how to overcome this issue would be appreciated.
At first I thought that this might be related to Pre-build task of Visual Studio project fails in GitLab Runner issue, but I don't get any build errors.
On the same machine, I build a .Net Framework app which has the same AssemblyInfo setup, but is compiled using msbuild /property:Configuration=Release by the runner and the produced dll file has all the expected information.
It turns out the problem was partially related to the AssemblyInfo.cs file not being part of the repository.
SDK-style csproj normally don't list the files in the project, but figure them out based on the folder contents. When dotnet build was run, AssemblyInfo.cs wasn't present in the project directory (GitLab-Runner usually clears out files not present in the repository before starting a job/pipeline), so build tools had no idea they needed to load it. It made no difference that the file was being created by the build tools.
The solution proved to be creating an empty AssemblyInfo.cs file before running dotnet build. This way build tools knew they needed to compile it. Actual compilation still happened after prebuild events, so all the needed information was there.
I created the empty AssemblyInfo.cs file using PowerShell:
New-Item -Path "Properties/AssemblyInfo.cs" -ItemType File
Also, checking the build logs helped me finally figure it out. To get the build logs I've called build tools like this:
dotnet build -c release /flp:v=diag
The .Net Framework app didn't have this problem because it wasn't an SDK-style project. All the files needed for compilation were listed in the project file and build tools knew to load them, even if they were created during the prebuild event.
I have an Azure DevOps GIT Repo with three different types of projects. Structure looks as follows;
Repository Structure
I have a Build Pipeline (Classic, not YAML) to build only the .Net Core Project as below.
Pipeline
The pipeline settings is pointed to consider only the NetCoreProject. The Restore, Build & Test tasks executes successfully. However, when it comes to the 'Publish' task the pipeline fails as it considers the entire repository (all projects) and not just NetCoreProject.
Actual cause of failure is in NetCPPProject folder there are some files without any extension (makefile, shortcut files, etc.) which the Publish task is not identifying and failing with below error.
##[error]Error: Failed find: ENOENT: no such file or directory, stat 'D:\a\1\s\NetCPPProject\inc'
Note: inc is a shortcut file (without any extension) and it is required to be present in the folder.
I tried following which did not work;
Added .artifactignore to ignore other folders but the .Net Core 'Publish' task seems not to consider that.
Tried specifying the arguments to Publish tasks to consider only the NetCoreProject .sln file and also .csproj file, but issue still occurs with same error message.
Reconfirmed the file exists in Build.SourceDirectory with a command line task.
Question is, how to make .Net Core 'Publish' task to exclude NetCPPProject and only consider NetCoreProject?
how to make .Net Core 'Publish' task to exclude NetCPPProject and only consider NetCoreProject?
To achieve this goal, you could try the following steps:
Step1: Disable Publish web projects option in Dotnet Publish task.
Step2: Set the target csproj file in Path to project field
For example:
Repo:
Result:
I had two build steps in VSTS:
To run tests (VSTS cmd task): DOTNET test -xml TEST-results.xml
To publish test results step (VSTS test publish task): format=XUnit and the file name from previous step
But after I upgraded to VS2017 the -XML tag is not working anymore. I changed step one to use this:
test --logger "trx;LogFileName=TEST-results.xml"
but the second step throws an error "Invalid results file. Please make sure the Test Result Format field in the task matches the result format of the file"
Is there another way to run .NetCore tests on VSTS? or am I doing something wrong?
Thanks,
starain-MSFT's answer will work, unless you want/need the xunit tests to be logged using an xunit logger. In that case, you'll need to do two things.
Add https://www.nuget.org/packages/XunitXml.TestLogger/1.0.2-pre-rtm as package ref to your test project, either through 'Manage NuGet Packages' in VS, or by adding the ref in your csproj file manually, i.e.
<PackageReference Include="xunitxml.testlogger" Version="1.0.2-pre-rtm" />
Modify the VSTS dotnet test build step to use this logger:
dotnet test -a:. -l:xunit
The -a:. switch, which specifies the adapter path, is only necessary for CLI tools V15.0, in 15.1 that can be removed (as discussed here). As of today, the VS2017 Hosted Queue is using 15.0, so you'll need the -a:. on VSTS for now.
The -l:xunit uses the friendlyname, which I think isn't so friendly since you have to dig into the source code for the particular logger to find the attribute where it is specified (as seen here for xunit and here for trx)
The docs for the -l switch are spotty to say the least, but in the github for vstest, there is a document which talks about test loggers and links to their repositories and nuget packages, which after you look at the source for the friendlyname, gets you all the way there for whichever logger you need. If you need a custom logger, those are great examples to help understand how to implement.
Finally, the publish step that you used originally should be fine, since the output file is still called TestResults.xml
Change "Test Result Format" to "VSTest of Publish Test" result step/task, it reads the result file correctly.
Use dotnet xunit instead of dotnet test. See Getting Started with .NET Core.
I am using VS2015, and MSBuild 14.
My solution has many projects, but three of them are old ASMX web sites. The ASMX website "projects" don't have their own project files, but are detailed in the XML of the solution file itself.
The solution builds fine inside Visual Studio.
However, when I try to build on the command line with MSBuild, I am getting an error message. Here is my MSBuild command:
C:\> msbuild MySolution.sln /t:MyAsmxProject
All the dependent projects (mostly c# class libraries) are built as I would expect them to be. Lots of output to the cmd window in which msbuild is running, until we get to the following action by msbuild:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /MyAsmxProject
-p MyAsmxProject\ -u -f -d -fixednames Precompiled\MyAsmxProject\
The whole thing bombs out here with the following error:
ASPNETCOMPILER : error ASPCONFIG: Could not load the assembly.
The property 'assembly' must be a valid assembly.
[C:\My\Long\Path\MySolution\MyAsmxProject.metaproj]
Now at first I didn't know what a "metaproj" file was, and was unable to find that file, but I did understand it to be an intervening project file created internally so that msbuild could operate on solution files. I discovered that I could see the metaproj file if I set the environment variable:
set MSBuildEmitSolution=1
And then re-ran the msbuild command. I now have metaproj files for both my solution and for my asmx project, which would appear to be the one referenced in the error message above.
These are both pretty dense msbuild files, but neither one of them have an XML node (element) named "assembly" and neither one of them have any XML nodes with the attribute or property "assembly" applied to them.
So I am unclear what this error is saying and how to fix it. And doubly unclear as to why it crops up with msbuild, but not with visual studio.
Any insights or suggestions most appreciated.
Although I don't fully understand why, I have found a solution.
Namely, if I run the command window in which I am doing the msbuild as an administrator, I don't get this error. This is an acceptable solution for me.
However.... it would still be great to understand more specifically what the error means, and why being an adminstrator makes the difference.
I posted this on the Kobold2d forums but haven't received any replies yet. I'm hoping the larger audience here at SO can help.
I'm trying to get our Kobold2d project working with our Hudson CI server. I'd like to have a script that executes the proper command line build instructions using xcodebuild, but I'm running into a problem with any Kobold2d project.
As a test I created a Orthogonal-Tilemap template project and built/ran it in the xcode 4.4.1 gui successfully. Building the projects individually from the command line the Kobold2D-Libraries.xcodeproj reports a successful build (though I have no idea where any products are stored), but the tilemap project fails with the message:
ld: file not found: <path>/Kobold2D/Kobold2D-2.0.3/BuildTest/build/Release-iphoneos/libkobold2d-ios.a
The only information I can find on this message talks about errors from building in the xcode gui, which is not the problem.
I also tried having xcodebuild build the workspace file but that failed with multiple dependency errors.
Has anyone found a way to successfully build Kobold2d projects from the command line?
Thanks!
Actually I use Hudson to automate Kobold2D builds. Here's the build script for Hudson.
I can see from your path that you changed Xcode's default build locations (Advanced, next to Derived Data in Preferences -> Locations). There's one setting (legacy) that doesn't work at all with Kobold2D, and should actually open a browser window explaining the issue should you have used that setting.
I think your setting is "relative to project" or something similar. Try changing the build location to Xcode default (Unique) and try again. You can use a custom location for derived data if you want to.
In any case, if the output location path of build products ends up being somewhere in the app project folder (in this case: BuildTest) then ld won't be able to find dependencies because they're not all in the same folder. If you do require this you could add a pre-link step that copies the .a files to the correct location. But it's best to avoid this because it'll be prone to breaking.
My script includes
xcodebuild -workspace Bulge.xcworkspace -scheme Bulge-iOS -sdk ${sdk} archive || die "Archive failed"