I have a drop folder created by TFS build which contains all the produced artifacts:
.dll \ .config \ .pdb files from all projects
_PublishedWebsites folder
*.msi files produces by Wix projects
All I really care about is *.msi files as everything I deploy is in them.
How can I specify for the TFS build not to bother with all the other files in the Drop folder?
I know I can customize the build to delete files after the solution build, but maybe there is a clever way of disabling them at all?
Personally I use named platforms such as Application and Setup in my SLNs so that when TFS archives the drop folder one class of files goes into one directory structure and another class of files goes into another. This way it's easy to find the MSI and it's also easy to see what the application code looked like before then. (Perhaps the contents of a web.config or an HTML that was added to the application sln but not the installer sln.
IF you want to suppress the application sln from archiving you have to look at that. It's not an MSI / WiX thing.
If you are using TFS 2013 (or VSO) you can easily have a PowerShell executed post build to do whatever clean up and rearranging you need.
Note: The build used the files in the root to do testing, code analysis, test impact analysis, and other automatic actions. Make sure that you only remove files after all of the checks. A better idea is to leave the files be and just push theb*.msi files to a "/_PublishedApplications/* folder.
There is a PublishedApplication Nuget package that can make this easyer. Take a look...
If you are using TFS 2010/2012 you can use the "TFS Community Build Tools" to call PowerShell and do other things.
Related
I am using TFS 2015 for creating builds of application. I am able to create build template for web application as web application have both .sln and .proj.
But for Websites, I only have .sln file and no .proj.
How can I create Build definition in TFS 2015 for website having only .sln file?
As #Cece said, the answer is yes, you can run the MSBuild on the server without a .csproj.
I am assuming that your project is not running on the final version of the .Net Framework. In your case I suggest you to make this change
https://stackoverflow.com/a/42493822/819153
Then you should copy all the files from the PrecompiledWeb folder, and there you should find your .sln
Sometimes there are vb/cs projects that I have seen that they do not come with a project file, csproj or vbproject. They run with the .NET Framework 2.0. For those, you can create a build definition just to compile the .sln, but when you deploy the application, you need to copy the entire PrecompiledWeb folder to the IIS folder on your server. Try to add the task that has the option copy and publish and put all the changes to your server.
Check the privilege of the folder where you want to put the files, and be sure that the agent that is running the builds on the TFS has access READ/WRITE access to the server folder.
In your case, please check the .sln file, inside of it you should have a TargetPath, by default is PrecompiledWeb, but sometimes when you run the msbuild on the tfs you end with an error saying that the PrecompiledWeb can't be on the same tree of your solution, what you need to do then is putting a level up of your solution folder
Debug.AspNetCompiler.TargetPath = "..\..\PrecompiledWeb\YourProject"
Then on your CopyTask you need to change the CopyRoot directory, if you made any transformation before your build step to the webconfig, those transformations will be reflected on the PrecomiledWeb\YourProject. All the files in that folder should be deployed to the server folder path.
Lets say that you have this structure in your Branch
Branch/MyProject, then after you compile the source code on the TFS, your precompiled folder will be stored at the same level of your project on the agents folder. Please see the picture below to get the idea how to copy the files from the PrecompiledWeb.
The answer is Yes. You can create a build definition for a WebSite project by specifying the .sln file.
In my solution I have a basic ASP.NET MVC website and a Wix Project. To identify the files that need installed I'm using Heat (a Wix component) to index the build output. This is part of a post-build event. It works perfectly on my local machine when building in Visual Studio 2015.
My problem occurs when checked-in and the CI (TFS Build) builds it. The differences are:
The contents of the bin folder is placed directly in the build folder
The rest of the website is placed under a new _PublishedWebsites folder
This means many of the references get broken. For example when dropping the _PublishedWebsites folder into IIS breaks (as .net cannot locate the contents of Bin)
After much research on the subject, and many attempts to pass MSBuild parameters, I'm reaching the end of my efforts.
Is there a way for a build in TFS to leave file locations intact without copying and creating new folders?
If not what is the recommended way to get a deployment ready site (in a single folder) from TFS?
Adding a Copy Files task to copy bin folder to $(build.artifactstagingdirectory)\_PublishedWebsites, check the screenshot below:
How can I set tfs build on agent to use one location for following files?
I have couple files that are run on after build of specific project.
files:
SomeFile.exe
RequiredDll.exe
I am using it for creating custom setups files, that is done from SomeFile.exe.
Now every time I have project that I want to run the actions, I need to copy files above into the project, which I know is wrong.
Is there any other way?
You can put these files in a common location within Source Control. Then in your build configuration you can map that common folder to a working folder for the build.
This is named slightly differently in the different versions of Visual Studio. In all versions it is found when editing a build configuration.
Visual Studio 2008 / 2010
Workspace
Visual Studio 2012
Source Settings
This allows you to map a source control folder to the Build Agents working build folder. You will then be able to access the same exe's in all your builds and they will only be in Source Control once.
A common practice is to have a Team Project dedicated to build artifacts. Then in your mappings you have something like this:
StatusSource Control FolderBuild Agent Folder
Active$/BuildProject/lib $(SourceDir)\BuildArtifacts
I have a bunch of external dlls I use in multiple projects. These dlls are referenced by these projects and everything compiles fine.
Now I am trying to get a Team Foundation Server build going for my projects. When I run the build, it complains that it can't find the needed files. How do I get TFS to find the needed files?
I was thinking I could use the copydirectory windows workflow function in a custom build template but I'm not sure if this is the right way to do things. Also, if I do use copydirectory, how do I reference directories that reside on TFS rather than on the file system? And where do I copy the files to?
Try this:(if using 2010)
At the Workspaces tab you can map the folder that has all the DLLs you want, just make sure you reference the assemblies in your project appropriately.
For instance, if your project is referring to the assemblies one level UP, before the project root folder, you may set the workspace like below:
$\Team Project\src -> $(BuildDirectory)\src
$\Team Project\dlls -> $(BuildDirectory)
Something like that should solve your issue.
There's also a way to do it in VS2010 build: You should add a copy command to the prebuild step for the project (select the project -> Properties -> Build Events).
If you want to use the windows workflow - template method, refer to this guide: http://blogs.msdn.com/b/buckh/archive/2010/01/21/deep-dive-on-windows-workflow-4-0-activities.aspx
The packages created by a TFS 2010 Build only contain our Sources, not the binaries. When this is (automatically) deployed to IIS, the site does not run because it is missing DLLs that are created during the build process.
We have a Web Project created in VS2010. If I select "Build Deployment Package" from a right click in VS we get a zip file in the obj\Release\Package folder that contains the fully build site.
However, if ask our TFS build process to create the package by adding "/p:CreatePackageOnPublish=true /p:DeployOnBuild=true" to the MSBuild arguments (as advised in amongst other places here) we get an zip file in _PublishedWebsites\_Package\.zip that only contains the sources.
My best guess is that the CopyAllFilesToSingleFolderForPackage is picking up the files from the wrong place.
I notice a similar issue asked here - TFS 2010 and creating a package - although his workaround in not appropriate in many cases, I'd guess.
My concern is that this is using a built-in, but poorly documented feature of MSBuild/TFS so when it doesn't work you're a little in the wilderness.
It seems that deployOnBuild runs some "package"-like target on each of the projects. If you have built the projects into a separate directory (which the default TFS 2010 build does by default) the packaging won't pick up the compiled files.
One solution is to get rid of the custom output folder for the MSBuild Command within the TFS build workflow. This will cause the compiled files to be located in-situ and be included in the package.
Now the rest of the TFS workflow is require some changes because it'll be expecting to transfer the files from the output directory, and they won't be there.