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
Related
Windows 10
Visual Studio 2017
TeamCity 2017.1.2
GitHub
I'm working with a VS solution that locally behaves as expected. Main-project has some package dependencies. Test-project has project-ref to main project. VS local compile succeeds. Main-project refs + dependencies are copied to MyProject/bin/debug; test-project refs + dependencies are copied to MyProject.Tests/bin/debug; ReSharper local run of tests succeeds.
However my TC project has problems running tests.
My build-config steps are : pull from GitHub , run Visual Studio (sln) build , trigger NUnit.ConsoleRunner to run tests vs built assembly - which throws a file not found error (can't find package dependency assembly ) that perhaps indicate the build steps needs to save as artifact the dependent assembly and copy it to the test output dir.
However looking at the agent work dir I find the dependency assembly present in both the main-project and the test-project :
C:\TeamCity\buildAgent\work\64f706c42d79250c\{main-project}\bin\Debug\{dependency}.dll
and
C:\TeamCity\buildAgent\work\64f706c42d79250c\{tests-project}\bin\Debug\{dependency}.dll
which indicates that VS build step copied {dependency}.dll into bin as expected.
So why can't NUnit find it ?
[19:27:48][Step 5/5] MyProject.dll
[19:27:48][MyProject.dll] MyProject.UnitTests.MyTest
[19:27:49][MyProject.UnitTests.MyTest] System.IO.FileNotFoundException : Could not load file or assembly 'MyProjectDependency, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
[19:27:49]
[MyProject.UnitTests.MyTest] at ReferencingCode()
at MyProject.MyClass.Answer() in C:\TeamCity\buildAgent\work\64f706c42d79250c\MyProject\MyClass.cs:line 9
at MyProject.UnitTests.MyTest() in C:\TeamCity\buildAgent\work\64f706c42d79250c\MyProject\UnitTests.cs:line 10
[19:27:51][Step 5/5] Failed tests detected
I'm wondering if the output dirs are different for the VS Build and NUnit steps ? But my agent work dir is identical to my local VS solution dir - so where would TC be locating the NUnit work dir ?
It looks as if you have two completely separate output directories, one under the test project and one under the main project. Your tests, of course, are run in the directory that contains the test assembly.
The output messages seem to say that the main assembly is being copied into the test assembly directory - the reference from the test project must call for a local copy. We can tell that because the test assembly and the main assembly both have entries in your stack trace. The dependent assembly, however, is probably not referenced by your tests, and so does not get copied. At least that's how I read it - verify by looking at the directory contents.
You could solve this by using the same output directory for everything, but that would probably involve changing the directory structure you are using. A simple fix is to add a reference to the dependent assembly to your test project and set local copy true.
For your tests to run, locally or in TeamCity, your test project must have a project reference to the project you are testing. It does not work any other way. How else would it know what to test? So check your references in the test project, and make sure the output is the same place when the build runs as "Debug" and "Release".
On a side note, letting TC do the actual build and test is fine for simple stuff but it's very hard to troubleshoot. I recommend you build a PowerShell script with PSake and create a "Test" task. That way you can run the script locally and TeamCity can use the same script you are running locally.
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!
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.
Normally when a Developer compiles a certain mixed C++/C# solution locally on their machine at our company, they employ the use of a .vssettings configuration file. One of the things included in this config file is reference to various directory paths for Lib and Include files.
However, our buildAgent machines (using TeamCity) are set up to be sterile, and have the bare minimum installed on them required to build any given solution/project. This means the above exampled mixed C++/C# project wont have access to the IDE's configuration where things like include search paths were set. TC accounts for this by allowing you to set all sorts of variables for any given buildConfiguration (or even by buildAgent)....
But how do I get an Include search path to WORK in TC? I'm copying down from Source Control (Perforce) a copy local of what I want Included (1), and then trying to define an Environment Variable (2) -- and yet TC fails the build (3).
I'm sure I have something configured wrong, but for the life of me cant figure out what!
Any help would be most appreciated,
blong
(1) VSC Client Mapping - Perforce
//depot/OpenSource/Boost-1.33.0/boost/... //team-city-agent/OpenSource/boost/...
(2) buildConfig Environment Variable definition
env.Include = %system.teamcity.build.checkoutDir%\OpenSource
(3) TC build log snippet
[16:57:39]: [Project "xxx.sln" (Build target(s)):] e:\buildagent\work\ef1853a454da9d94\xxx\rowsbase.cpp(5, 0): error C1083: Cannot open include file: 'boost/dynamic_bitset.hpp': No such file or directory
First, you should try to compile the solution yourself with msbuild or vcbuild on the command line, because TeamCity will do something similar. If necessary, add msbuild folder to the Path system variable. Then open the command line and type:
msbuild.exe YourSolution.sln
or
msbuild.exe YourSolution.sln /p:Configuration=Release
depending whether you want to do so in debug or release mode. This should give the same C1083 errors.
Here's the fix:
Add the path of the directories you need to add an environment variable (in fact, system variable) that I suggest you call INCLUDE.
Open the file VCProjectEngine.dll.config.xml in folder .../Microsoft Visual Studio 9.0/VC/vcpackages/.
Add the INCLUDE system variable to the include line. To me it came to replacing:
Include="$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSdkDir)\include;$(FrameworkSDKDir)include"
with:
Include="$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSdkDir)\include;$(FrameworkSDKDir)include;$(INCLUDE)"
Test it works: Open a new command line (need to after you change environment variables for them to be taken into account) and try to build your solution as shown above. This has worked for me to build C++ solutions with files that #include .
Now let's have it work in TeamCity too. You can run a TC build at this point to see whether it does, but it didn't for me. Go to the "Properties and environment variables" of your TC build configuration, and add an environment variable named INCLUDE with value the same path(s) as in the INCLUDE system variable above.
Now this should work. Hope it helps.
Setting the Build Agent Service to run as a non "local System" account fixed my problem.
I ran into a problem were my C++ projects would build in Visual Studio on the build agent, but they failed when built through TC. The build agent is running windows and agent is running as a service (TeamCity Build Agent Service). The problem was that the service was being run as "Local System" instead of the user that configured Visual Studio. I change service so it would log on as the "build" user and everything worked fine.
I wrote a Nant script that executes MSBUILD.exe to compile a project on my dev machine. On my dev machine, the projects builds its output to bin\x86\Release and my Nant script zips up the contents of that directory. I then commit everything to SVN and let TeamCity run the Nant script that executes MSBUILD.exe to compile the project and zip the output, but the output is created in bin\Release and the zip file is empty because it looks in bin\x86\Release. Why does this happen?
When I make changes to the configuration and platform in VS.NET 2008, I do not see the project file light up as being changed. Are these settings stored in the project file, solution file, or user configuration file and therefore not carried over to the build server?
Quick fix: You can use the flag /property:OutDir=bin\x86\Release
You would have to find root cause of this. Probably configuration is incorrect. You can change configuration explicitly to something like /p:Configuration=Release
Are you sure ${project.config} point to the same place in both local and TeamCity environments?
The agent are not always running with the sem environment variables as the local machine. So I would start out to check all properties and see where they point in the local machine as well as TeamCity.
As for the /p:Configuration=${project.config}, you can only have one configuration running but you can specify more properties with ; between them:
/p:Configuration=${project.config};OutDir=bin\x86\Release