I've created a build definition for my coded ui test. I'm not seeing the TestResults folder with the Out folder that is created. My test is failing because these folder are not being created before I start the test. In the Out folder there are files that my test use. After the test fails, I see the command prompt window on the screen by DTAExecuti8onhost.exe with the strings for the texts Results File: with the path of the results folder but when i go to look for this i dont see the folder or the file of the test results file ending in .trx?
My questions is where in the build definition process do i need to set this or do i need to change my code so i'm not looking in the out folder. I'd rather not change my code but will if this cannot be done. Or my last thinking is do i need to change my build step or add another step for this to occur.
Here is my build definition process.
Get sources
NuGet restore
Build solution
Copy Files to:
Copy files from
Deploy TestAgent on :
Run Tests
Publish Artifacts :
Thanks in advance.
Related
Trying to deploy a multi-project app to azure using pipelines. After trying various combinations (pipeline log is showing about 75/80 runs in the last couple of days), it looks like the problem is with the Dockerfile by Visual Studio 2019 or with the Azure Pipeline somewhere.
Here's what I've narrowed it down to:
Project A-
create a vs asp.net core webapp project, say test1sp,
select the checkbox which says create solution and project in the same folder,
select docker support (I selected Linux) or add it later
no code added, the boilerplate code runs fine as-is
add it to GitHub
create a project/pipeline in azure, source Github, I use the classic editor without YAML
create a docker build/push task and setup, I choose the most basic options, subscriptions, etc.
build works great, I also added a deploy to app service task and it deploys to the app service
Project B - my project is called demo8
Same as project A, except for step #2 - do NOT select create solution and project in the same folder. Follow the rest of the steps and now you should get this error.
Step 7/17 : COPY ["demo8/demo8.csproj", "demo8/"]
...
...
##[error]COPY failed: file not found in build context or excluded by .dockerignore: stat demo8/demo8.csproj: file does not exist
It works fine on localhost/docker. So, I'm guessing maybe vs2019 uses some more tolerant implementation to patch it over. Or, there's a problem with azure's implementation or something else?
I am relatively new to Dockerfile editing and see lots of detailed/complex scenarios, hopefully, someone can shed some light on how to get it working?
Here's a screenshot of the project files/structure:
UPDATE -
Moving the Dockerfile to the solution folder in project B makes it work in azure BUT
then it does NOT work in Visual Studio, no debugging, etc.
make a copy of Dockerfile in project & parent folders ( + keep in sync )
BUT if your solution has multiple projects like mine then
you have to name the Dockerfile different to have unique names in the parent folder
and modify the pipelines to use respective file names
Posting it here in case it helps someone.
The code in the Dockerfile must have the relative path to the folder level that the Dockerfile is in.
Tow ways to solve the problem. One is the change the code in the Dockerfile, for the project B, you can change the COPY code like this:
COPY ["demo8.csproj", "demo8/"]
Another way is to move the Dockerfile to the path that matches your COPY code. But in this way, it may affect other codes in your Dockerfile.
And you'd better plan your projects in different folders and create the Dockerfile for each project in different folders.
I just ran into this problem with a default console app in VS2022. I fixed it by changin the "Build context" parameter in the ADO build pipeline's Docker "build and push" step from the default of ** to **/.. so that the working directory was the solution folder, which matches VS (AFAIK).
Similar to #Josh's answer above -- I explicitly set
buildContext: '$(Build.SourcesDirectory)'
in the Docker task in the Azure Pipelines YML file, and it worked like a charm.
Something for the Azure pipelines template maintainer(s) to look into perhaps?
I've added several images to the wwroot/images folder for an asp.net core MVC project. They are included and displaying just fine locally, however when they are published through the AzureDevOps pipeline the images aren't appearing.
I've looked at the wwroot in Kudu and determined that the files aren't in the images directory in Azure, and I looked in the build command line results in AzureDevOps and I can see that the copy command for those images isn't being run during the MSBuild, but the original banner.svg images from the base project template are being copied.
I did a search files and saw that there was a file called project.assets.json which has include statements for the original images, but not the images I've added to the project. I suspect that the issue lies with the new images not being added to the project.assets.json file. This file appears to be auto generated though. I've verfieid that the new images have a build action of "Content" and I've even tried setting to copy always but to no avail. I'm thinking there is something else I need to do to get those files to be included in the project.assets.json on build.
Anyone know how to get new images to be added and recognized through the build script in Azure DevOps?
More than likely it’s your csproj file not having the right element to include those files in publish. Try doing a dot net publish locally and see if the files show up in the output directory . If they do then you only need to run that same.net publish command at the same commit. If they do not, then you need to update your CS project file to include those files , then retry dotnet publish locally to verify issue was resolved
I figured out that if you add the images to the wwroot folder, they are added to your local wwroot but never added to the wwroot folder that's in source control. I went and added the images that were missing to the wwroot/images folder in source control and check them in. Afterwards the publish went through without issue. I tried copy/pasting to the images folder and going right click > add > existing item and both did not recognize the add operation as a pending change in source. Not sure if this is a bug in VS or what.
When using the Visual Studio Test task in Release Management, the release always returns:
No test assemblies found matching the pattern
currently Test Assembly is set to: **\*test*.dll;-:**\obj\**
I have tried multiple defaults like $(System.DefaultWorkingDirectory), etc.
The documentation I've been able to find is either not current with the existing layout of tasks, (such as the Publish Build Artifacts screen no longer containing the Contents box), is for the on premise Visual Studio 2015, or related specifically to the Build.
I've read and attempted the following:
https://msdn.microsoft.com/Library/vs/alm/Release/getting-started/deploy-to-azure
https://msdn.microsoft.com/Library/vs/alm/Release/author-release-definition/understanding-tasks
https://msdn.microsoft.com/en-us/library/gg265783.aspx#Activity_RunTests
http://blogs.msdn.com/b/visualstudioalm/archive/2015/07/31/dev-test-in-azure-and-deploy-to-production-on-premises.aspx
http://blogs.msdn.com/b/visualstudioalm/archive/2015/05/29/testing-in-continuous-integration-and-continuous-deployment-workflows.aspx
UPDATE:
I added a step to the build to Copy and Publish the test.dlls. They are now located. They all fail, due to missing other code, but they are located.
UPDATE II:
My 3_Run_Tests.log file contains the following clues:
Error calling Initialization method for test class ... To run tests that interact with the desktop, you must set up the test agent to run as an interactive process.
Test Run deployment issue: The assembly or module ... directly or indirectly referenced by the test container ... was not found.
Because of the above, I am going to accept #eddie-msft's answer.
You need to make sure that the complied file of the project which you'd like to test is also been copied and published to the same path with Test Assembly. The test will fail if only Test Assembly is copied.
I assume you are working on a C# project, in the step to copy test assembly, you can set the copy content as this:
**\YourTestProjectName\bin\$(BuildConfiguration)
I have been having a similar issue. Multiple projects in build and the test file would not be found.
No test assemblies found matching the pattern *test*.dll;-:\obj**
Fix: added additional build step "build solution" and "Copy Files to". This build was pointed to VS solution file with automated test. "Copy Files to" was left at default
In CC project config file I have many MSBuild tasks. Each task is used to build one solution.
Problem is that this requires maintenance if this CC config file each time when new project is added to / deleted from repository.
My idea is to pass to the CC dynamic list of solutions that should be build and execute build one by one as it is done now with "static / old fashion" maintenance of config file.
Does anyone prepare already such configuration?
Presuming you have something akin to the following:
On disk:
./solution1.sln
./solution2.sln
./solutionN.sln
And a single ccnet project:
Msbuild task -> solution1.sln
Msbuild task -> solution1.sln
Msbuild task -> solutionN.sln
What you are asking for is ccnet to react to what is outside of its environment. This isn't possible, however it would be possible to get another tool to do so.
Possible options:
1. Custom Msbuild project
Create a specific msbuild project which finds and invokes msbuild on all solution files it finds. Call msbuild on this project alone. It should be possible to do this with vanilla msbuild, see https://msdn.microsoft.com/en-us/library/z7f65y0d.aspx
2. Batch files
Find all files, and for each file execute msbuild. Ensure the output is logged to an XML file (msbuild switch - I believe) and merge in the result in the publishers section.
See How to do something to each file in a directory with a batch script
3. Single solution
Create a single solution, which contains all the projects from all solutions (1 to N) and call msbuild on this once.
This solution file would be need to be updated each time a new project comes along however.
Build Server: TFS 2012 with Update 4.
I am using chained configurations to apply web.config transformations. I have two solution configurations, Debug and Release.
I have three publish profiles for my web application, DEV, UAT and PROD.
In my buid server, I have set it to use the "Release" configuration and added the following to the MSBuild arguments:
/p:DeployOnBuild=true;PublishProfile=UAT
The build completes without any failures, but it never copies any output to the drop folder. The drop folder should contain a _PublishedWebsites folder, but instead it only contains a log folder with the log files in it.
When comparing the log files for the builds that were working before with the non-working builds, I see that all the logs where it copies files are completely missing.
My publish profiles are set to use "file system" publish, not web deploy. Not sure if that makes a difference or not. I have tried changing the publish profiles to use the same directory that is the drop folder on the build server but all that happens is that it ends up erasing that folder and all of its contents.
I'd like to point out that if I remove the "PublishProfile=UAT" from the msbuild arguments, it works as expected and both logs and the _PublishedWebsites folder are copied to the drop folder.
In addition, I know that it is doing the things from the publish profile because I can see these actions in the log file. It's just not doing the extra step where it copies all the files to the drop folder.
Ideas?
Did you set Copy Output to Drop Folder to true and entered a path for This build copies output files to a drop folder?
Did you set Solution Specific Build Outputs to false?
Does it work with the default platform and configuration (remove the Release)?
Try a diagnostic build (Verbosity=Diagnostic) and check the outputs of Copy Files to Drop Location sequence in the build log.