I am unfortunately stuck on TeamCity 9 but want to use C# 7 language features. This requires me to have the VS2017 tools available, but in TC 9 you can only select up to 2015. I have manually installed the VS2017 toolkit on the build server and it is all available in
C:\Program Files (x86)\MSBuild\15.0
However in TC, the highest VS you can select to build with is 2015, which points to
C:\Program Files (x86)\MSBuild\14.0
I want some way to override this so that by selecting VS2015 in TeamCity, it will actually be pointing to MsBuild in
C:\Program Files (x86)\MSBuild\15.0
Is this possible?
Check you agent properties in TeamCity web interface. Search for your path: C:\Program Files (x86)\MSBuild\14.0 and write somewhere all keys that have this path in it.
Then go to your agent installation directory and edit file: C:\Path\To\BuildAgent\conf\buildAgent.properties
Add all those keys with new path, something like (assuming you key is MSBuildTools14.0_x86_Path):
MSBuildTools14.0_x86_Path=C:\\Program Files (x86)\\MSBuild\\15.0
(keep in mind escaping slash \\)
Restart your agent, and check again build agent properties. All paths should be replaced and you should be good to go.
This answer is based on comments from this issue: https://youtrack.jetbrains.com/issue/TW-54222
Related
Hi I am banging my head for last few days.
Here is the situation ...
1. I have VSO account which maintains the TFS in cloud.
2. Installed a build server/agent on another machine. (Works fine)
3. Tried to build(XAML build) one solution using that server/controller.
4. Got an error saying ...
"The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk."
The build server and the agents are from TFS 2015 and the project is a Visual Studio 2015 project using framework 4.6. I was expecting "v14" folder for target files during build. Why it is trying to find things from "v11" folder ? And how do I solve this.
I know I can copy files to "v11" but I don't want to escape the facts. There should be a reason and a proper fix. Any help would be nice.
Several solutions for you to correct this error:
S1: Install MSBuild.Microsoft.VisualStudio.Web.targets from NuGet gallery via running the following command: Install-Package MSBuild.Microsoft.VisualStudio.Web.targets.
Then replace the following line in your .proj file
<Import Project="$(MSBuildBinPath)\Microsoft.WebApplication.targets" />
with
<Import Project="$..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0\tools\VSToolsPath\WebApplications" />
S2: Set the /p:VisualStudioVersion=12.0 MSBuild argument in the build definition.
S3: Copy the Microsoft.VisualStudio.Web.targets file to the C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications folder on the build agent machine.
S4: Install VS2012 on the TFS build agent machine just like Patrick mentioned above.
And related cases: Microsoft.WebApplication.targets and Microsoft.WebApplication.targets was not found, on the build server. What's your solution?
The WebApplications\Microsoft.WebApplication.targets (11.0) (which comes from VS2012) is referenced in your web application, so the Visual Studio 2012 should be installed on your build server to resolve this issue.
Be note that, to guarantee TFS build runs successful, you should make sure your build agent machine has the some environment as dev machine.
Did you restore a previous collection on TFS 2015 from a previous TFS version? Did your solution or any projects in your solution get created prior to VS2015?
I added into Solution(contains 30projects) Wix Installer, which is supposed to pack web service folder. Among files i want to pack is BIN file with plenty of dlls. On local with Release mode it works fine, however if i run TFS 2013 build definition over solution i get these:
C:\Builds\1\ABCD_02\WixInstaller\WSwixInstaller\filesToBeInstalled.wxs (97):
The system cannot find the file 'C:\Builds\1\ABCD_02\WixInstaller\WSwixInstaller\..\..\..\ABC WS\bin\ABC.Components.DataAccess.Lib.Utils.dll'.
I asked my colleage who administrate server and he told me that BIN folder isn't created in 'expected' location.
Now i don't have access to server and colleage is unreacheable, is here rule where binaries for all project/within solution are stored?
Update:
Somehow we overlook BIN folder - 'as configured' is and was set in definition however files still couldn't be found - problem was in build order(weirdly in VS2010 was correct) setting dependency wix project on target project helped - problem was that wix project was builded before target one.
Team Build creates uses a MsBuild parameter to redirect the build output of projects. If you need your Wix Installer to package up content that has been redirected, your installer script must be aware of this redirection happening.
The output structure of team build looks like
Build Agent Root
+- Unique build folder
+- src <- This is where your Wix project is placed
+- bin <- This is where Team Build redirects the project outputs to.
+- Test <- This is where Test Results are stored
This allows Team Build to figure out which outputs to copy to the drop location with a lot more accuracy, but it breaks any scripts that have hardcoded (or relative) paths to build outputs.
There is hope though, you can use the $(OutDir) or $(OutputPath) parameter to find the location Team Build has been configured to drop your binaries. You can use the '$(BuildingInsideVisualStudio)'=='' and/or '$(TeamBuildConstants)'=='' to detect whether your Wix Script runs in Visual Studio or in Team Build.
That way you can define multiple source locations for your Wix packages or to set the base directory to a certain value and use that variable in your wix scripts.
Or if you simply want your team build to match your bin structure when running in visual studio, set the 'output location' parameter in your build definition to 'as configured' - see this link for details:
http://blog.stangroome.com/2014/02/10/override-the-tfs-team-build-outdir-property-in-tfs-2013/
I also asked this question on the Orchard forum but no joy there yet. So here it is again...
https://orchard.codeplex.com/discussions/569444 Please read for a few more details.
IF the .NET 4/4.5 SDK came with a developer command prompt (like previous SDKs) then I would not be asking this question.
But since Orchard is build with .NET 4.5 I am getting build errors using the old SDK. It seems that my only option is to install Visual Studio Express on the build server.
I am doing that as we speak so at this point the question is purely academic but I am still curious.
EDIT
STILL NO JOY. Even after installing VS 2013 Express Web the vcvarsall.bat that usually configure the build environment is still not present. So this is no longer a curiosity question. The Express edition also cannot create my build environment. Help.
Seth
Here is my answer...copied and pasted from the forum.
This is a late answer. Bottom line is that I did eventually get our build server to build orchard projects. I am not sure if this is a complete answer or not as I should have answered as soon as I had it done. But I pretty sure this will work.
One other thing to note...It is quite possible that not all of these steps are required. I tried a lot of different things and it might be in the end some of the steps were not needed. It might also reflect a problem on our build server...especially the fact that I had to manually add registry entries.
But here it is without details.
Install the .NET Framework SDK for Windows 7.1.
http://www.microsoft.com/en-us/download/details.aspx?id=8279
Install the .NET 4.5 Full
http://www.microsoft.com/en-us/download/details.aspx?id=30653
Install Visual Studio 2013 Express for Web
http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
Install the Visual Studio 2013 Build Tools
http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
Finally, even after that...it didn't work until I added the following registry keys. I would attach the .reg file but I don't see how.
Save the lines between the lines into a fixBuild.reg file. Then double click...
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VC7]
"FrameworkDir32"="C:\Windows\Microsoft.NET\Framework\"
"FrameworkDir64"="C:\Windows\Microsoft.NET\Framework64"
"11.0"="C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\"
"FrameworkVer32"="v4.0.30319"
"FrameworkVer64"="v4.0.30319"
"12.0"="C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\"
Finally, to actually do the build, I created a batch file that does the build.
Save the lines between the lines into a doBuild.cmd file. Be sure to place this in the root of the source download...then double click to build...
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat"
msbuild /t:FastBuild Orchard.proj
The first line gets your environment ready. The second build the project using the FastBuild target in the Orchard.proj file. You can read that file if you want to try other build targets.
******* EDIT
There is one thing I forgot to mention. And that is that one thing you have to do to get this to work is that you have to edit some CSPROJ files because the command line build fails with errors like these...
\Orchard\src\Orchard.Web\Modules\CKEditor\CKEditor.csproj(337,6): error : "None" element name for include "Placement.info" should be "Content".
\Orchard\src\Orchard.Web\Modules\Orchard.Tokens\Tests\Orchard.Tokens.Tests.csproj(82,6): error : "None" element name for include "app.config" sh
\Orchard\src\Orchard.Web\Modules\TinyMceDeluxe\TinyMceDeluxe.csproj(377,6): error : "None" element name for include "app.config" should be "Cont
\Orchard\src\Orchard.Web\Modules\Upgrade\Upgrade.csproj(156,6): error : "None" element name for include "app.config" should be "Content". [C:\Us
\Orchard\src\Orchard.Web\Themes\Themes.csproj(280,6): error : "None" element name for include "Upward\Views\Content-Story.Detail.cshtml" should
The fix is to do exactly what the error indicates. Open the csproj files and search/replace "
Also, some of the projects reference app.config files that do not exist in source. You also have to remove those references. I usually just delete the content node entirely or the group entirely.
Seth
When using DefaultTemplate from Visual Sturdio 2012 (and TFS 2012 server), the PDB files are included in build directory. I do not want them.
Is there a way not to generate those files during build process?
Or
How can I delete those files?
I found this thread about deletion but seems a bit strange (no delete activity?)
There also is this answer but does not involve XAML template.
Thanks in advance for your help.
PDB files hold debug information on your code and its not advised to disable them, they are valid output hence deployment shouldn't be messing with them.
You can disable their generation in Visual Studio project Properties> Build > Advanced > Debug Info = none.
If you absolutely want them gone then disable them for build specific configuration (relaese etc.)
The build server by default does whatever the Solution (sln) tells it to. That by default is to do a "Debug" build and that created the PDB's. You can tell the Build to do a "Release" build that will not by default create any PDB's...
Figure: Adding a Build Configuration
I would however recommend against it as the PDB's contain information that you need even in production systems. Consider for a moment that you have a DLL in production and the customer is encountering a problem. You get them to create an InteliTrace log so that you can debug it locally (or they let you debug on their environment) and suddenly you are trying to debug without Visual Studio understanding the relationship between the Executable and the Source Code. So no debug...
Since I was unable to find building option to disable PDB file generation, I delete them afterwards.
There is no easy way to delete files. I did:
use a FindMatchingFiles Activity with wildcard *.pdb, which returns
a full path to pdb files
use a Foreach loop
call a DotNet method in the loop for each file with the InvokeMethod Activity,
with target type System.IO.File and method being "Delete"
In the previous version (Visual Studio 2010)
When we build /release, it was not generating PDBs, the PDB files are created when we only build with /debug:full or /debug:pdbonly, we use /debug:pdbonly if we want to generate PDBs for a release build that we do not want to be debuggable.
This is not the case in Visual Studio 2012, I checked it and I found it generated PDBs in both, /debug and /release
There is no documentation for Visuals Studio 2012.
I just downloaded TeamCity 7 today and decided to get it up and running for my Azure solution. I am not trying to do anything fancy (yet) and started with a very basic command line build:
msbuild /t:Publish /p:Configuration=Release;TargetProfile=Production;PublishDir=S:\HoursTracker\Deployments
This builds successfully and produces a package that looks like this*:
I then attempted to configure TeamCity in an identical fashion:
This builds successfully and produces a package that looks like this*:
What I don't understand is why there is such a huge discrepancy in the size of the MVC project. Publishing directly from Visual Studio produces the exact same result as my MSBuild command so I'm convinced that TeamCity is the odd man out. Since I assume TeamCity is not broken, can someone please educate me on how to properly configure it so that I get the expected output?
*I have renamed the package files with .zip so that the details were viewable for this post.
Ming's answer helped me solve the mystery. After inspecting the contents of the zip files, I discovered the difference was that my MSBuild package contained bin and obj folders and the TeamCity package did not.
After making this discovery, I realized that I could specify multiple targets to MSBuild and prepended "Clean" to my targets switch like so:
msbuild /t:Clean;Publish /p:Configuration=Release;TargetProfile=Production;PublishDir=S:\HoursTracker\Deployments
As expected, this removed those folders. So apparently, TeamCity specifies "Clean" implicitly for you. Mystery solved.
Windows Azure packages may be larger than we expect. You can rename the cssx file to zip and you will find out what’s inside the package. In addition to the web application’s usual files, there’re a bunch of Windows Azure files. For example, if you enable diagnostics, you will see a diagnostics folder, where you’ll find files used by Windows Azure diagnostics runtime.
Best Regards,
Ming Xu.
Why you specified x64 for msbuild runner? Try selecting tools version as well. You have not specified /p:Platform parameter. Does publish task involve rebuild?
TeamCity starts msbuild with number of /p: parameters taken from " properties and environment variables " section, plus some well-known parameters like configuration name or project name.