My .sln file has a website (and a few other web applications). The web applications get published to the _PublishedWebsites directory, but not the website. I am not using a custom build configuration. This happens in both Release and Debug mode.
Any ideas?
During the TFS build it checks the project file for Imports which it uses to define the build requirements. The Visual Studio 2010 import for web projects ($(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets) does not contain a definition for the outputting to *_PublishWebsites* as the Visual Studio 2009 one ($(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets) had.
To solve this you need to edit the web application target file on the build server to enable this functionality.
Additional information and assistance can be found at
http://social.msdn.microsoft.com/Forums/zh/tfsbuild/thread/0bd3b8de-0397-41f1-b43a-5ccdd04f9436
http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/559a53e1-2eeb-48e9-a95f-400154b3333f
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.
I am trying to get the most basic configuration of TFS 2012 up and running.
So far I installed the TFS server using the simplest option (the 1st option in the installer - the one that comes with a bundled SQL express),
I configured the build service (1 controller, 1 agent, both on the TFS machine).
My project consists of 2 parts: a C#/silverlight part, and a C++ part.
After adding the silverlight prerequisites the C# project builds correctly.
However I can't get the C++ project to build.
I guess I am missing a prerequisite since I am getting the following errors:
C:\Builds\1\proj1\Client\src\Code\Client\proj\main (VC11).vcxproj
(19): The imported project "C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\v110\Microsoft.Cpp.Default.props" was
not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
Indeed, the TFS server does not have a "C:\Program Files (x86)\MSBuild\Microsoft.Cpp" folder (while my dev machine has one).
I installed the windows SDK, but that didn't help.
I saw on some posts that I need to install VS 2012 on the build machine. Is that correct? will VS express do?
I have been banging my head on this for the last 2 days, and any help would be appreciated.
Installing Visual Studio on your build server seems like a strange thing to do, but having been around the TFS block a bit, I have found it to be the simplest way to manage build servers.
You can copy the files manually from your dev machine to your build server, but if an update to visual studio comes out, you will need to figure out what has changed and make sure you update all those files too. These files typically include Targets files and associated dlls.
Also with all the extensions and packages that are available now, it is just easier to load Visual Studio on your build server and install the required packages than try to work out what is needed to replicate the functionality.
This was made very clear to me recently when Microsoft released ASP.Net and Web Tools 2012.2. This altered the publishing pipeline for Web Sites and Web Projects and I needed to use this in my TFS build. It was so much easier to just be able to log onto my build server, load Visual Studio and download the new update.
I would definitely support installing Visual Studio on your build server.
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.
I've a MVC 4 application and runs well on my DEV Machine where I installed MVC 4 extension for VS 2010.
When deploying to the web server with IIS 7, do I need to install MVC 4 or should the dll included on my project is sufficient?
The reason I'm asking is we need to provide the requirement to infrastructure team.
Thanks.
You can run an MVC application without installing MVC on your server. There is something called deployable dependency in Visual studio. That will publish your MVC DLLs in your bin folder when you publish it.
from the msdn page,
This will add assemblies (DLL files) to a Web site project or Web application
project. When you deploy your Web site or application, the files are
included in the deployed project. This is useful if applications or
technologies that your project depends on are not already installed on
the server that will host your Web project. For example, you can use
this feature to deploy an ASP.NET MVC 3 Web application to a server
that does not have ASP.NET MVC 3 installed.
Right Click on Project and Select Add Deployable Dependency from the context menu
Select what all DLLs you want to be published
After clicking OK, You will see a new folder called _bin_deployableAssemblies. You can do normal Publishing procedure now and you will have the dlls in the bin folder of the publish output.
Check this post for more details http://haacked.com/archive/2011/05/25/bin-deploying-asp-net-mvc-3.aspx
You should have Visual Studio 2010 SP1. Otherwise it will not be shown in the context menu when you right click on the project to be published.
EDIT :
As of MVC4, all necessary assemblies to run an MVC application are automatically added to the bin directory, and any MVC4 application is bin-deployable (means you can run it in a server without explicitly installing MVC) . For this reason, the Include Deployable Assemblies dialog has been removed from Visual Studio 2012
You no longer have the option to "Add deployable dependencies" in Visual Studio 2012. So you'll have to do it manually, by bin deploying all the MVC assemblies:
Microsoft.Web.Infrastructure
System.Web.Helpers
System.Web.Mvc
System.Web.Razor
System.Web.WebPages
System.Web.WebPages.Deployment
System.Web.WebPages.Razor
A step by step guide is found here.
When u create a MVCx specific project in Visual Studio you will see lots of MVC.* references are added to your project and by default all of these reference property "Copy Local" is set as "True" means these references will be part of your final solution whenever you will deploy to. You can also verify that these MVC specific references are also part of your BIN folder.
Finally when you will package this solution and publish to a specific Web Server or to Windows Azure or use WebDeploy, all of these references will be part of your package also. And because these references are shipped in your package so where ever you will deploy the solution, all MVC specific references will be there and because of that you don't need to deploy MVC to those specific servers.
I would also like to add that any time when you add a specific reference to your project in Visual Studio, set its property "Copy Local" to TRUE so that reference will always be part of your final solution, and will save you from trouble in future.
You only need to have the dlls deployed into the bin of your project. For an example of how to prepare your web site for release check out the following blog post:
running-an-asp-net-mvc-3-app-on-a-web-server-that-doesn-t-have-asp-net-mvc-3-installed.aspx.
I have a large solution with 10+ web applications and 10+ console and windows service applications.
When building All.sln, in the drop location, i've got single folder with all console application dlls, and web application dlls mixed.
Also, i've got _PublishedWebsites folder, which contains nicely separated web applications in their own folders, ready to deploy.
How to get console applicaitons in their own folders, each with only necessary referenced dlls, just the way web applications are separated in _PublishedWebsites?
Looks like it's possible with custom 'master' msbuild file:
msbuild SLN and still get separate project outputs?, but how to achive the same with regular TFS 2010 build?
there's a NuGet package you can install that will do this.
see http://www.nuget.org/packages/publishedapplications