We just upgraded to TFS2015 (onsite) and I'm trying to set up a build that will do the same thing as my xaml builds but I can't seem to get the same files built. Here's a picture of the xaml output directory that I use to publish the site. To get this I navigate to the build folder then drill down to the _PublishedWebsites\BOTWSitecoreWeb folder:
Here's a picture of the solution explorer:
So as you can see BOTWSitecoreWeb is my startup project and it forms the basis for the website. So to publish this website I simply copy the folder: _PublishedWebsites\BOTWSitecoreWeb to my IIS directory. Here's what it looks like using the xaml build:
And if I drill down into the TFS2015 build output folder into the Drops/Source/sc/Website folder I get this, which has many more files and folders than what I'm expecting:
So my question is how can I get the same output that I currently get from my xaml builds from a TFS2015 build?
The bin folder has the same number of files, so that's a good start. Here's the bin folder from the xaml build:
And here's the bin folder from the TFS 2015 build. Notice that they both have 57 files, which I assume is a good thing!
Thanks in advance for any insight you can provide!
Ben
Update your build definition to below:
Add /p:DeployOnBuild=true /p:OutDir="$(build.artifactstagingdirectory)\\" arguments in Visual Studio Build step:
Change "Path to Publish" of "Publish Build Artifacts" task to "$(build.artifactstagingdirectory)_PublishedWebsites\ProjectName":
Save the build definition and queue a build, now you should get the same files published in drop folder like XAML build.
vNext build and XAML build, it's totally different technology. There won't be any automated ways of converting.
The new builds are based on a different architecture and run on a
completely different system.
So your situation is predictable, it's very hard to achieve a 100% conversion. Copy the folder in vNext will copy everything under the folder by default. Seems there are some customization during the copy or published in your XAML build which will return the result as above picture.
If you have heavily customized XAML builds and custom activities, you
can continue using those builds until you are ready to port your
business logic into scripts that can run in the new builds.
And you could also take a look at these series of articles how to upgrade from XAML to Build 2015 with minimal changes.
Related
I am trying to exclude certain files/folders from deployment of a web project in Visual Studio Online to an Azure website.
The web project has a Content folder with CSS, JS, build scripts and so on, which are only necessary for development, once deployed to Azure the CSS and JS is loaded from a CDN. Currently the build from VSO is copying all those files to the webroot in Azure, which is unnecessary and a potential security issue in case of the build scripts.
Now I know this can be prevented by setting the build action of a file to None, but this a very tedious solution because there is a lot of development going on, new files get added all the time and it is easy to forget this setting.
First I tried setting the Content folder to Cloaked in the build definitions source settings, but this only causes VSO to not download this folder on build, msbuild will still complain that those files are missing.
Is there a way to tell msbuild to ignore the whole Content folder? I already tried adding /p:ExcludeFoldersFromDeployment="Content" as a msbuild argument in the build definition, and also tried the solutions in here How to get Visual Studio 'Publish' functionality to include files from post build event?, but nothing is working.
I was studying msbuild log files and came up with a solution that is good enough for us to work with.
The first thing I learned was that I cannot prevent msbuild from copying files with build action Content to the output directory, at least not without changing the Microsoft.WebApplication.targets file, which I didn't want to do and am not even sure is possible with VSO build.
Anyway because of this we cannot set the source settings of our Content folder to Cloaked in the build definition, since this will cause the build to fail.
What we ended up doing was described in this answer: https://stackoverflow.com/a/3140349/1230302
So by adding the ExcludeFoldersFromDeployment statement to the .csproj file, the Content folder is excluded from the webroot.
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
<OutputPath>bin\</OutputPath>
<ExcludeFoldersFromDeployment>Content</ExcludeFoldersFromDeployment>
</PropertyGroup>
It is not an ideal solution, but at least this way nothing gets deployed if a developer forgets to set the build action to None.
The built in continuous delivery options are designed for convenience. Of you need something custom, like skipping deployment of files that have not changed, then you will need to write something yourself.
You can easily call PowerShell to complete any task from the build process.
If you'd like to customize your build as part of the VSO build system, you can just override your BuildTemplate.xaml file.
Visual Studio Build uses Windows Workflow (xaml) to make a workflow on what the build is supposed to do. You can edit this file and do any modifications to the directory structure before or after the build.
Here is an example.
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 am newbie to TFS.
I am trying to automate process of build upon checking in the code in TFS.
I setup a Controller and an Agent. I created a new build definition and set a "build" and "drop" folder on c:.
I check in the code, expecting to see the generated dll files in "drop" folders. There's none, just "logs" folder. The "binaries" folder in "build" folder is also empty. Apparently the binaries are not being generated at all. How can I have MSBuild to generate the dll files?
They are generated when I compile the website locally on my development machine under "bin\" folder. The solution is comprised of two separate projects: "core" and "web" where "core" is referenced within "web".
Any thoughts?
What is the Summary showing of your build that ran? Or are there errors in your build? You can check the log of the build by opening the build in Visual Studio and then click View Log.
We have a very large solution (some 300+) projects and we are trying to build it via MSBuild on TFS2010.
We can build it via MSBuild on all out development machines, and are in the process of adopting TFS.
The structure of our code is like so:
bin\Client
bin\Server
Framework\ClientFramework.csproj
Modules\Module1\Project1
Modules\Module2\Project2
etc.
Each project has a relative OutputPath which builds the code to the bin Client or Server directory. So for example, Project1.csproj has an OutputPath of "..\..\bin\Client".
We seem to be having a problem that in TFS MSBuild the OutDir is set to a Fixed Path:
C:\Builds\MyProject\Binaries\
So things are getting confusing when resolving the relative OutputPath on top of the OutDir
ClientFramework goes to C:\Builds\MyProject\Binaries\..\bin\Client
Project1 goes to C:\Builds\MyProject\Binaries\..\..\bin\Client
etc.
We also have some Post build events that copy some 3rd Party dll's to the bin folders, these paths cannot be resolved properly either.
I think the solution we are after is to build everything to our existing bin\Client, bin\Server structure and then move the Folders from bin to Binaries.
Any ideas on how to accomplish this or how we should be working, are appreciated, but updating our existing projects might prove problematic, as it all works with VS, developer command line builds and with CC.net.
Since this is first link that pops up with a Google search of "TFS OutDir", I must provide a newer solution. I spent an entire day playing around with OutDir, OutputPath, and overriding them with TeamBuildOutDir. A better solution is to set the MSBuild property GenerateProjectSpecificOutputFolder. It comes with .NET 4.5. More info here: http://blog.codeassassin.com/2012/05/10/override-the-tfs-team-build-outdir-property-net-4-5/
I found the answer on MSDN : http://msdn.microsoft.com/en-us/library/ff977206.aspx
I am trying to update an application that was developed a couple of months ago on VB of Visual Studio 2005.
The "Build output path:" for the project is pointing to a folder in which I collected a few executables related to my activity, BinDir/. It is just next to the project's folder ProjName/ on my disk.
Contrary to the past, when I build my project now, the .exe is created in the ProjName/obj/Debug folder, instead of being directed to the BinDir/Debug folder.
In the IDE's Output tab (while building), the path of the generated executable appears correctly, but in reality it is located somewhere else.
Why is it so?
UPDATE: Something very peculiar is going on my computer today... A couple of hours later I tried again and now it seems like the executable is created in both places. The obj/ version is just redundant now.
What you describe seeing in the Update is what usually happens with Visual Basic builds in Visual Studio 2005. The build creates the executable in an intermediate directory (obj\debug) and then copies the executable from there to the final build output directory (bindir\debug)
With the usual minimal logging turned on, if you examine the build output, you should see the vbc command include the switch /out:obj\Debug\yourproject.exe which tells the compiler to create the executable in the obj\debug fdirectory. Then you should see the file get moved to the build output yourproject -> C:\TestPrograms\Vb.net\yourproject\bin\Debug\yourproject.exe
If you use Tools | Options | Projects and Solutions | Build and Run to set the "MSBuild project build output verbosity" property to "Detailed" you can see a lot more activity against the obj\debug directory and then see the various project output files being copied from that intermediate directory to the build output directory.
The macros $(Targetdir) and $(IntermediateOutputPath) can be used to access these two directories as can be seen using a build event like this...
echo target: $(Targetdir)
echo intermediate: $(IntermediateOutputPath)
In the original question, it sounds like the copy from intermediate to build output either failed or was not attempted leaving you with only one copy of the exe in the intermediate directory.
It's too late to go back and look now but typically the build output window will tell you more about why the copy failed.