I have this working as part of Startup.cs to validate that there are no missing configuration settings and this works as the app will fail to run if it's missing a setting, but I wondered if this can be added as a step or job as part of the pipeline before deploying to QA/UAT/Prod.
You could include a Unit Test that fails if any of your required configurations are missing.
Assuming you're running the Unit Tests as part of the build pipeline, if the test fails it should prevent deployment.
This question might help you achieve this.
Related
I am pretty new to CI/CD and mm currently struggling with getting VSTS to find my xUnit tests. My solution is a pure experiment, to try and isolate the problem and to learn. Before getting into my setup and what's been done so far, the result is this line in the VSTS build log:
Warning: No test is available in C:\agent\_work\1\s\Quotifier.Models.xUnit.Test\bin\Release\netcoreapp2.0\Quotifier.Models.xUnit.Test.dll. Make sure that installed test discoverers & executors, platform & framework version settings are appropriate and try again.
From having googled the message I interpret it as VSTS not being able to find an xUnit test adapter. Is that a correct assumption? Also, I see the terms "test adapter", "test runner" and "test explorer" alot. Are these terms the same thing? Having checked out this article it seems they are indeed the same thing. Can anyone clarify?
Now, for my setup ...
The xUnit test project is a .NET Core 2 class library referencing NUget packages xunit and xunit.runner.visualstudio (2.2.0). The test project is also referencing a shared class library called "Quotifier.Models" which contains the tested code.
To make it easier to diagnose I am running a local (on prem) build agent on my PC. This enables me to investigate the file structure.
The build step of my build definition was initially a "Visual Studio Build" that built the whole solution. I can see that the resulting binaries ends up in
C:\agent\_work\1\s\Quotifier.Models.xUnit.Test\bin\Release\netcoreapp2.0.
Among the binaries are also xunit.runner.visualstudio.dotnetcore.testadapter.dll. Is this the xUnit test adapter VSTS can't find?
More googling tells me that the typical place for the test adapter to be found is in the $(Build.SourcesDirectory)\packages folder and, so, that's what the test step's "Path to custom test adapters" should be set to. That gave me this log entry:
Warning: The path 'C:\agent\_work\1\s\packages' specified in the 'TestAdapterPath' does not contain any test adapters, provide a valid path and try again..
I also checked that local folder and, indeed, the xunit NUget packages does not end up in there. Can anyone guess as to why?
Assuming the xunit.runner.visualstudio.dotnetcore.testadapter.dll is indeed the test adapter VSTS is looking for, I thought I should try and help it a bit. So I created a seperate MSBuild step and specified the output path via the "MSBuild arguments":
/p:OutputPath="$(build.binariesdirectory)/$(BuildConfiguration)/test-assemblies".
I then set the test step's "Path to custom test adapters" property to point at that same folder. With that I'm back to the original warning in the log:
Warning: No test is available in C:\agent\_work\1\b\release\test-assemblies\Quotifier.Models.xUnit.Test.dll. Make sure that installed ... bla ... bla
Now, to summarize ...
running xUnit test projects out of the box doesn't work with VSTS
The xUnit NUget packages does not end up in the /**/packages folder
I am assuming the xunit.runner.visualstudio.dotnetcore.testadapter.dll is the test adapter needed. Is this assumtion correct?
I'm out of ideas for now so any hints, links or suggestions will be greatly appreciated.
Use "dotnet test" to run Your NetCore-UnitTests.
The task is called ".NET Core" and has a command dropdown where you select build/restore/test etc... You also need to add "NET Core Tool Installer" if you are using a hosted agent
And your xunit-packages are not supposed to end up in "packages"-directory. The netcore2 projects handle nuget-packages differently and will reference them from the local nuget-cache
I have created a new build definition for TFS 2010. After building my C# solution I would like it to execute a couple of unit tests. These unit tests require an XML input file, so I have a [DeploymentItem] attribute to the test methods which provides the relative path the XML files. If I run the unit tests from within Visual Studio they pass ok.
When the unit tests get run following a build (via my build definition), they fail with: "Microsoft.BizTalk.TestTools.BizTalkTestAssertFailException: Input file does not exist..."
It would be great if I could get to a trace of what the build agent was trying to do, to help with troubleshooting.
Does anyone know how to get such a trace output? I guess I could increase the verbosity of the trace output from the main solution under test but I don't think that would give me any indication of where the build agent was looking for the test input XML or why?
Thanks
Rob
I found it! Needed to click the "View Log" link from the screen that's displayed following the build. I had been looking at the default view of "View Summary"
I'm struggling to get web.config transformations working with automated builds.
We have a reasonably large solution, containing one ASP.NET web application and eight class libraries. We have three developers working on the project and, up to now, each has "published" the solution to a local folder then used file copy to deploy to a test server. I'm trying to put an automated build/deploy solution in place using TFS 2010.
I created a build definition and added a call to msdeploy.exe in the build process template, to get the application deployed to the test server. So far, so good!
I then tried to implement web.config transforms and I just can't get them to work. If I build and publish locally on my PC, the "publish" folder has the correct, transformed web.config file.
Using team build, the transformation just does not happen, and I just have the base web.config file.
I tried adding a post-build step in the web application's project file, as others have suggested, similar to:
<target name="AfterBuild">
<TransformXml Source="Web.generic.config"
Transform="$(ProjectConfigTransformFileName)"
Destination="Web.Config" />
</target>
but this fails beacuse the source web.config file has an "applicationSettings" section. I get the error
Could not find schema information for the element 'applicationSettings'.
I've seen suggstions around adding arguments to the MSBuild task in the build definition like
/t:TransformWebConfig /p:Configuration=Debug
But this falls over when the class library projects are built, presumably because they don't have a web.config file.
Any ideas? Like others, I thought this would "just work", but apparently not. This is the last part I need to get working and it's driving me mad. I'm not an msbuild expert, so plain and simple please!
Thanks in advance.
Doug
I just went through this. Our build was a bit more complicated in that we have 8 class libraries and 9 web applications in one solution. But the flow is the same.
First off get rid of your after build target. You won't need that.
You need to use the MSDeployPublish service. This will require that it be installed and configured properly on the destination server. Check the following links for info on this part:
Note that the server in question MUST be configured properly with the correct user rights. The following sites helped me get that properly set up.
http://william.jerla.me/post/2010/03/20/Configuring-MSDeploy-in-IIS-7.aspx
http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html
How can I get TFS2010 to run MSDEPLOY for me through MSBUILD?
The next part requires that your build definition have the correct MSBuild parameters set up to do the publish. Those parameters are entered in the Process > 3.Advanced > MS Build Arguments line of the build definition. Here's a hint:
(don't change the following for any reason)
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=False
/p:MSDeployPublishMethod=WMSVC
/p:SkipExtraFilesOnServer=True
/p:AllowUntrustedCertificate=True
(These control where it's going)
/p:MSDeployServiceUrl="https://testserver.domain:8172/msdeploy.axd"
/p:UserName=testserver\buildaccount
/p:Password=buildacctpassword
/p:DeployIisAppPath="MyApp - TESTING"
Obviously the user will have to be configured in IIS on the target server to be allowed access to that axd (see previous links). And the IisAppPath is the name of the website on the target server.
You won't have to do anything special for the config transformations as the build itself will take care of that for you. Just have the correct setting in the line at Process > 1. Required > Items to Build > Configurations To Build.
Instead of trying to do the deploy by adding tasks myself into the build process template, I followed advice in Vishal Joshi's blog post here.
Now the entire project is built and deployed and the web.config transformations work also. Brilliant!
I now have another problem to solve! The web application references web services and the build process results in an XmlSerializers dll. However, although this is built OK, it does not get deployed to the web host. I think this needs a new post!
Doug
I have an ASP.NET MVC application with a separate project added for tests. I know the plusses and minuses of using the connection to the database when running unit tests, and I still want to use it. Yet, every time when I run the tests with the NUnit tool, they all fail due to my Data Context being null. I heard something about having a separate config file for the tests assembly, but i am not sure whether I did it properly, or whether that works at all.
i think you should check this discussion here, it should be related as i was having the same problem.
and how i solve my problem was just to copy my web config content to the app config inside he test project and voila, database connection restore and all is fine in the land of mvc again.
How are you creating your data context? How is it used in your action? Typically, it will use the database referred to when you set up the classes in the designer so you'd get a context connected to what you used for the designer which is, arguably, not what you want for unit tests, thus you add an app.config file to your unit test project and change the connection string to your test database. It doesn't usually result in a null data context.
I suspect that your unit test is simply not touching the code that creates the data context before you invoke the action method. Without code though, it's really impossible to tell.
I've written an NUnit test project against an ASP.Net project. The code being tested cannot find the configuration values (in Web.config) when invoked from my test project. What is the right way to provide these configuration settings so my tests will run?
Take a look on NUnit's documentation about Configuration Files - it's pretty good explained how to handle your case.
You can create an app.config file for your test project. Just put the configuration values you need in here.