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.
Related
I just started using TFS not to long ago and I ran into a slight issue. I have a class library project called EplanInterface.Addin. This class library project is used as a way to load functionality into a 3rd party program through their API. All of this is working fine but the issue comes into play here:
The Issue:
So the problem I am running into is that this Addin library is not referenced by any other projects but still needs to be output to my Drop folder within my TFS build. Typically to load the Addin into the 3rd party program I would copy the debug/release folder to the server and select/load the dll accordingly. My TFS build does not seem to grab the anything from the Addin though?
App.Config
Along with that I am using SlowCheetah to try and transform my app.config file resources correctly. Whatever solution provided I need to also figure out how to select a transform when doing the build configuration and output the dlls with the correct build configuration config file.
Build Definition
My build definition is the basic asp.net template they provide which works great for my web api and MVC projects. I guess I am unsure how to force it to also build the addin / output the dll files for my addin to reference?
Other Info:
TFS Version: 16.122.27102.1
Addin Project .Net Framework 4.5.2
Slow Cheetah Version: 3.2.26
You can simply add another build task to your pipeline to build the specific addin project and then have it output to the artifacts directory (as the default "Build Solution" task should already be doing).
The other option is to edit the solution file in Visual Studio and include the addin as a project dependency. You may still need to manage the binary output though.
This is a winform application.
All dlls, exe and some other extension files are copied to the StartupProject\bin through the post build events(VS post-build).
On TFS Server, the project has 2 subfolders: bin and src.(bin contains required dlls, but other extensions are missing -.png, .dat, .xslx).
On the server, the post build copied files appear under the StartupProject\bin, but they are not copied to TFSFolder\bin.
How can I force copy all the StartupProj/bin to the TFSFolder\bin?
Team Build use a different directory layouts from Visual Studio builds. All Binaries go in a single folder for any project built, so references are automatically solved and it is easy to copy the DLL to the final Drop folder.
You should use $(OutDir) MSBuild variable to properly reference the binaries directory in VS and TFS builds. See Is there a single MSBuild and TFSBuild variable that will point to where the binaries are? for some details.
If you need to use different scripts for desktop (VS) and server (TFS) builds, use the $(BuildingInsideVisualStudio) variable as explained in TFS 2010 Build Automation and post-build event.
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.
I've just setup a TFS (2012) server and now I'm trying to build the complete code (written in .NET 4.0 in VS 2010) via the TFS Build server. But in my solutions I have also a WCF RIA project which contains linked files because they are used somewhere else also and there is no possibility to add a reference to a general .NET binary in WCF/Silverlight.
Everything builds without any problem on my development machine but when I check it all in, create a standard build definition and run that build definition I get the following problem. The linked files have usings (UsingNamespace for example) to other projects that are also build by us and build before the WCF/Silverlight but the following error pops up while building through TFS Build server:
The type or namespace 'UsingNamespace' could not be found (are you
missing a using directive or an assembly reference?)'
Is there any solution for this problem that I looked over?
EDIT 1
Just tried to set the Copy to Output Directory propertie of the linked files to Copy Always but this still gives me the same error as I was expecting. The problem is that the linked file is placed somewhere that it can use the usings but the WCF RIA service cannot access/find that using.
EDIT 2
Just tried out my local test TFS where I can do what I want and there I made a build definition with just the solutions needed to make that the project with the linked files builds. This worked without any problem. Then I tried the same on our TFS server with a new build definition that has the same solutions as on my test TFS and here it did not work. The only difference that I know for sure is that my test TFS is TFS 2012 Update 1 and that my production TFS does not have the update 1 yet. I'll try to install it next week.
EDIT 3
I've just updated our production TFS to Update 1 but it is still not working with my temporary build definition which only contains the projects that are needed to build the silverlight application with the linked files. The 2 workspaces are the same on both server and the projects to build are also the same.
You need to specify the workspace information in the Build Definition for the build to use. The workspaces are what the build process copies from source control to the build server. If you don't have everything in the build server's workspace, it can't build properly.
The Source Control Folder in the workspace tab is the location of the files you need from TFS. The Build Agent Folder is a relative path from the build server's pre-defined base location. You'll usually use $(SourceDir)\Folder to specify the "Folder" that your build process needs.
This sounds like an $(Outdir) problem. A build definition in TFS automatically overrides the Bin folder. All Binaries are redirected to the bin folder upon compile. Sounds to me that you are using a mixture of project references and file references. The file references are probably what is causing your build failures.
Example if you compile in the same build the following solutions
Solution1.sln (TFS Build Pass)
project1.csproj
project2.csproj (references project 1)
Solution2.sln (TFS Build Failure)
project3.csproj (references binary output of project 1)
Expectations from TFS out of the box without customizing your workflow is that this simple build will fail. The reason is that in your development box all projects produce output to one destination while in a tfs build your projects will build to $(Outdir).
Some Things to try
Simple (best practice in my view)
Create 1 solution and use project references instead of file references.
Complex
Build using MSBuild project files
Modify your windows workflow to not override the $(Outdir)
Copy the binaries after a build is complete.
Best practice on Automating Builds
Build from command line
Build from cmd a NON vs2010 command line.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe FullpathtoSolutionFile.sln
Cheers!
Apparently there was just missing the WCF RIA services V1.0 SP2 on the TFS server. If that was installed the problem was solved.
I have a website, a windows service, and some shared class libraries in a single Visual Studio solution. I use Octopack on both the website and windows service, and on my machine these builds work as expected.
When using the TFS Build Server, the website nuget package is generated as expected, but the windows service nuget package contains all files from the website, as well as the service. E.g. it includes the _PublishedWebsites folder as well.
This is because TFS uses a single location to build projects.
What is the best way around this?
I know this question has since been closed, but I cam across this issue and solved it in a different way.
My solution is compromised of a number of websites and windows services and had the same issue of the OctoPack created nuget packages including all the solution assemblies from the 'pooled' output folder when building with Team Build. The reason the nuget packages get all the assemblies is OctoPack uses the outdir msbuild argument as the location to include assemblies from.
The way I got around it was to use the msbuild argument GenerateProjectSpecificOutputFolder=true. This instructs Team build to create a folder for each project in your output folder in the same way Visual Studio uses the bin folders under each project when building locally.
My build definition msbuild arguments looks like:
/p:GenerateProjectSpecificOutputFolder=true;RunOctoPack=true;OctoPackPublishPackageToFileShare=\\<NugetServer>
I currently just push the packages onto a shared folder but the OctoPackPublishPackageToHttp and OctoPackPublishApiKey parameters can also be used.
The benefit of this solution over the one above is you don't need to specify the files to include the nuget package.
Hope this helps someone.
I ended up using this nuget package to ensure the console app built to a seperate directory on the TFS server.
https://nuget.org/packages/PublishedApplications/2.1.0.0
I then had to specify in the nuspec file, which files should be included for the console app. e.g
This works and I can now deploy using Octopus deploy.
The downside of this apporach is that the PublishedApplications build only works on the TFS build server, so I can't build the project locally in release mode. Still looking on how to overcome this.