Just trying TeamCity for our applications, however, when we try to build the project it fails as the projects are built out of order, causing a crash and it failing to continue.
I have manually run MSBuild against the solution file and it runs correctly. Is there any extra configuration we could have missed when setting up the server?
Related
I am new to TeamCity and difficulties building Visual studio 2013 soln testing on win 7 .My Plan is to make TeamCity automate build & deployment on committing to svn server with 2 builds. 1-Build -> Build xyz.sln file with 2 web application projects -> proj1 & proj2 . 2-Publish -> If 1-Build is Successful then publish proj2 web application project to test & prod server (2 servers). I did the setup of svn trunk on TeamCity which has xyz.soln file and connection tested successfully. When I tried to build the configuration with my xyz.soln
Build Step :
When I tried to run the build it was giving: Warning: No enabled compatible agents for this build configuration. Please register a build agent or tweak build configuration requirements.
Followed this -> http://www.danmusk.com/how-to-build-asp-net-applications-in-teamcity-with-msbuild-tools-2013-and-net-framework-4-5-sdk/
Installed MSBuild separately and confirmed
MSBuild Tools 2013 -> C:\Program Files (x86)\MSBuild\12.0\Bin
also .Net framework ->
windows SDK ->
https://teamcity-support.jetbrains.com/hc/en-us/community/posts/206843275-Unmet-requirements-MSBuildTools12-0-x86-Path-exists
Any help would be great? Need to fix this Issue badly .
If you installed the appropriate MSBuild Tools, you likely just need to restart the build agent so it can re-register with the current set of capabilities.
To illustrate how this works, you can first look at the Build Configuration's Agent Requirements:
In this example, you can see the build needs MSBuildTools12.0_x86_Path defined (as well as some .NET framework stuff).
Over on the Agent's parameters, under Agents->[Agent1]->Agent Parameters->Configuration Parameters, you can see a list like this:
In my case, the value is present so it's considered a 'compatible agent'.
How do these settings get on the agent? Well, when the agent starts up it checks all these things to see what it's capable of and includes them in this big list of Configuration Parameters.
Therefore, if you install something like MSBuild Tools, you'll need to restart the agent... it runs as a service, so just go to the services panel on the agent box and restart it.
Apologies for the nubbery, but I'm having a real pain getting NUnit to run on my Mac. The overall goal is to have Jenkins on our Mac build server build our Xamarin project and run the relevant tests to the .sln file.
I've got NUnit-Console installed and invoking correctly on the mac. However, whenever I pass it /relative/path/to/solution.sln (or .csproj, we don't have a .nunit or built .dll), NUnit finds the the .sln file correctly, however it then throws this error: Could not find file "/relative/path/to/solution\TestProject.csproj".
The .csproj is there, but NUnit seems to want to append a backslash instead of a forward slash. Is there some config option I've missed for this?
Ok so it doesn't look like you can configure NUnit-Console to not do this. If anyone reads this and is looking for a work around, you just need to get your built files from their location, onto a location that Nunit-console running on windows can access.
For my particular use case with Jenkins as the build manager, I've set the project to build on our MAC server, then as a post build action added 'Archive for Clone Workspace SCM'. I've then setup another project called [ProjectName]Tests, which has the other project targeted in 'Source Code Management' > 'Clone Workspace'.
The test project then has my relevant calls to nunit-console as a Windows batch script and everything works as expected!
Hope this helps save others some time if they hit the same issue!
on my CI server running TeamCity 8.0 I have a build configuration whose last steps are the creation and the push of a new version of a NuGet package.
I wonder if there is a way to inhibit these two steps if the current build is a personal one.
Any clue?
There's an environmental variable thats exposed in teamcity that can tell you if this is a personal build BUILD_IS_PERSONAL :
See http://confluence.jetbrains.com/display/TCD7/Predefined+Build+Parameters
E.g. using the msbuild runner (you just need to supply the nuget path)
<Project DefaultTargets="Pack" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Pack" Condition="$(BUILD_IS_PERSONAL)!='True'">
<Message Text="Personal: $(BUILD_IS_PERSONAL)"/>
<Exec Command="$(NUGETPATH)\nuget pack $(NugetProject)"/>
</Target>
</Project>
Alternatively, you could halt the condition of build steps using an extra build step. thereby making them conditional:
Add an extra build step that uses the powershell-
if (([environment]::GetEnvironmentVariable("BUILD_IS_PERSONAL","Process")) -eq "True")
{
throw
}
On each build step there is the option:Execute step
If you choose the option "If all previous build successfully" then the step will be passed
If you choose: "Even if some of the previous build steps failed" it will execute.
TeamCity 2020.1 has added support for conditional build steps, and there is a quick shortcut to skip the build step for personal builds.
You could create a new build configuration - leaving out those 2 steps. Then - install the TeamCity Visual Studio plugin (assuming you are using VS) and then run a personal build, choosing the build configuration you'd like to use.
Similar to Jordan's response I think the best approach is to separate compilation from packaging / deployment build configurations. In fact if you use Octopus to deploy then you have to keep the TeamCity Octopus deployment steps in a separate build configuration from the compilation as the NuGet feed doesn't get populated until after the build configuration has been completed successfully.
If make your packaging / deployment build configuration a dependency of the compilation build configuration and set the build trigger to only trigger after a successful build of the compilation build configuration, then it will not trigger after a personal build even if that is successful : -
This way you are always calling the same build configuration for compilation, whether via Developers on VS using the AddIn or Release Team via the Web UI
Hope this helps
We have a similar issue where we only wanted to build-and-deploy our local Apache Maven repository when it has changed.
One possible solution: If your build step is a Command Line (or can be), create a tiny shell script to decide if these step should be run or not.
I use CMake generated solution for Visual Studio 2010.
In my solution I have several lib projects and one exe project.
For Debug build configuration I use output names like lib1_d.lib, lib2_d.lib etc...
For Release build configuration I use lib1.lib, lib2.lib ...
thanks to CMake I have one extra build configuration I use - RelWithDebugInfo. I use same output names for this build configuration as for Release.
Now here is the problem:
Assuming everything is cleaned.
I hit F5 (run / start debugging) RelWithDebugInfo. All project are built (exe is depending on them) and project runs successfully.
I switch to Release and hit F5 again. All project are built and project runs successfully. (libraries in output directory are overwritten)
I switch back to RelWithDebugInfo and hit F5. VS quickly goes through and gives All outputs are up-to-date. ... Build succeeded. And DOES NOT overwrite lib files in output directory. So application crashes because it uses libraries for other build configuration.
This problem occurs for both ordering Release->RelWithDebugInfo and RelWithDebugInfo->Release
I haven't find a solution, how to add other prefix to RelWithDebugLibraries my SO question
Is there a way, to force Visual Studio 2010 to always overwrite outputs? Preferably by some flag which I can provide from CMake.
The VS build system solves this problem by using different build directories for different configurations. By default, 32-bit Debug output goes to the Debug directory, Release output goes to the Release directory, 64-bit Debug output goes to x64\Debug directory, etcetera. This way different configurations never step on each other's output files.
Looks to me like the mistake you made with your added RelwithDebugInfo configuration is that you didn't modify the output file names. So the build system sees an up-to-date output file from another configuration and doesn't think it necessary to rebuild them.
Coming up with variations of build output file names does get to be impractical once you go past two, do consider the VS-way to do this.
We have a TFS build definition set up where we pass the following extra MSBuild arguments in:
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir="\\server\build";AutoParameterizationWebConfigConnectionStrings=false
This has been detailed elsewhere as a way to have the published files copied to a specific location instead of generating a deploy package.
This unfortunately does not work on our build server, however if I run the exact same msbuild command line as called by TFS on my dev machine then it works perfectly and copies the output files to the location.
I have checked the log file and there is no errors, it just seems to completely skip the publish/deploy step.
Done building target "_BuiltWebOutputGroupOutput" in project "xyz.csproj".
Target "PrepareForRun" in file "c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets" from project "C:\Builds\2\xyz\xyz build\Sources\xyz.Web\xyz.Web.csproj" (target "CoreBuild" depends on it):
whereas on my local machine, after _BuiltWebOutputGroupOutput target is run the package target runs and deploys the files correctly.
I have tried using different paths and even setting the properties in the project file but it seems to make no difference. My local solution and project files are the same as in the repository that the TFS build is using. Is there something config related on our build server or with the build agent that would cause the packaging target not to run?
I was having a similar problem today and found a fix so it maybe worth a look for you. Here