tags:

views:

689

answers:

7

Hello all,

I am trying to configure TeamCity 5.0 to run "Publish" target on one of my projects.

When I load the solution in VS 2008 and click publish on the project the website is being build nicely - files on server appearing by themselves etc. Yet when I run the sln file via TeamCity Sln2008 runner the TeamCity returns:

[Project "Portal.csproj" (Publish target(s)):] Skipping unpublishable project.

Has anyone had the same problem?

Filip

+1  A: 

Have you solved your problem? I also want to publish my ASP.NET site with TeamCity, but I can't.

Alexander Shapovalov
This is not an answer. This should be placed as a comment on the original question.
kzh
In my case I have to install .NET 3.5 to the webserver and it start working for me.
Alexander Shapovalov
+2  A: 

I have this same problem, here's what I've tried:

I have a solution file in Visual Studio 2010, committed to a Mercurial repository.

I have setup an FTP server for the root directory of the site to publish to, and publishing from within Visual Studio 2010 locally works nicely, it connects and uploads everything as expected, and the website works.

Now, I wanted to automate this on every push to the central Mercurial repository, and since I'm using TeamCity, I discovered that the field to specify the Target of the build, usually "Rebuild" can also take "Publish", so I specified "Rebuild;Publish", as per the documentation and help.

I have verified that after publishing in Visual Studio, and committing new files, a file named ProjectName.Publish.xml is accompanying my ProjectName.csproj file, and this file is pulled down into the server directory when TeamCity builds.

Yet, no publishing is done, and when I check the build log, it says:

[19:01:02]: [Project "Test.sln" (Rebuild;Publish target(s)):] Project "Test.UI.Web.csproj" (Publish target(s)):
[19:01:02]: [Project "Test.UI.Web.csproj" (Publish target(s)):] Skipping unpublishable project.

Exactly as the question here says.

Note that this is a development site, publishing just so that we can let more people test changes, so don't get into a discussion of whether this is actually a good idea or not.

Note: I do not care in which way the files are published, I just need the single TeamCity build-step to actually do it, so if anyone got a MSBuild-like solution that just sidesteps TeamCity, then I would be satisfied

Lasse V. Karlsen
I've started a bounty on this question to hopefully attract some attention to it.
Lasse V. Karlsen
We do just this with our builds. I have posted an an answer as to how to get the deployment to work by calling msbuild on a web project but if you are interested I can go into more detail on our build chain.
Bronumski
+2  A: 

Have you tried to execute Visual Studio directly, rather than relying on MSBuild to publish the project directly. MSBuild can't execute certain kinds of projects. I had a similar problem with getting MSI's built from within Team City. I'm taking a guess at the exact commandline settings to this, since I don't know your exact setup.

  <PropertyGroup>    
    <buildconfiguration>Release</buildconfiguration>
    <DevEnv>C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com</DevEnv>
  </PropertyGroup>
 <Exec Command="%22$(DevEnv)%22  /build $(buildconfiguration) $(teamcity_build_checkoutDir)\Test.sln /project Test.UI.Web.csproj"/>

If you're using the Team City solution runner as your build runner, you'll have to switch to MSBuild.

If you want to stay with the Team City runner, you could always try adding a project to your solution that will be the last one built, (or do it on the project that currently gets built last), and do the spawning trick as a post-build command line on the project.

FrederikB
I'll take a crack at this tonight and see how it works out. If I manages to get it working, I'll publish my exact steps related to TeamCity, for future reference. Initially when I read your post I was afraid I would then lose the ability to automatically run unit tests and code coverage as part of the build configuration in TeamCity, but switching to MSBuild doesn't remove those options. I think it did in an earlier version, perhaps that's why I haven't thought about experimenting more with MSBuild. Anyway, I'll test this. I suppose I need to ensure this only runs in TeamCity, and not locally.
Lasse V. Karlsen
Having visual studio or any other development application installed on a build agent can lead to lots of problems. You end up with assemblies in the GAC and other artifacts which would not normally be installed on a target environment.This results in tests passing on the build agent but your application fails on the target environment due to missing dependencies. If your build agent was clean this would be picked up earlier. Whilst there are always exceptions you should keep your build environment as clean as possible and keep everything relating to the build in source control.
Bronumski
I'm aware of that problem. The way we solve this in our environment is through a clean 'build' agent which uses msbuild to compile. That machine runs all our tests as well. Building MSI's, using Code analysis is done on a different build agent with VS.NET during a later build step. That should catch most of the problems. As a final safeguard, you could have some simple automated smoke tests that use the release that comes from the last step. None of this would be needed if some of this essential functionality was in MSbuild rather than VS.NET. If it's still a major concern, change tools.
FrederikB
Did you see my suggestion bellow about using Microsofts 'Microsoft.WebApplication.targets' msbuild targets?
Bronumski
Ah - missed that. Nice. In my case I'd still need a way to build the MSI. Had a root around and couldn't see anything under the bonnet that could be used to build the MSI .vdproj.
FrederikB
+4  A: 

You could create your own simple build file. For example:

<Project DefaultTargets="Build" ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"&gt;

       <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/>

       <PropertyGroup>
            <PackageFolder>C:\Builds\AppServer\Actual </PackageFolder>
             </PropertyGroup>

       <Target Name="Build" DependsOnTargets="BeforeBuild">

             <MSBuild Projects="TeamWork-AppServer.sln"
             Targets="Rebuild"
             Properties="Configuration=Debug;OutDir=$(PackageFolder)\;"></MSBuild>
       </Target>

.

Or you can use VS 2008 Web Deployment Project. Here is a great turtorial.

Martin Fabik
This is .NET 4.0 and Visual Studio 2010, are web deployment projects still available for the new versions of the tools? I was looking for those but couldn't find them. Anyway, now I have two suggestions to use MSBuild to do this, so I'll definitely look at that.
Lasse V. Karlsen
Yes,there is a version for .NET 4. Here you are http://blogs.msdn.com/b/webdevtools/archive/2010/05/26/visual-studio-2010-web-deployment-projects-rtw-available-now.aspx .And maybe have look at this http://microsoftpdc.com/Sessions/FT56
Martin Fabik
+1  A: 

Can TeamCity publish a Web project using the sln2008 build runner http://stackoverflow.com/questions/1162253/can-teamcity-publish-a-web-project-using-the-sln2008-build-runner

What type of project are you trying to publish?

http://social.msdn.microsoft.com/forums/en-US/msbuild/thread/7ec0d942-6354-41c3-9c97-7e7d1f461c29 Taken from above link:

   What I discovered is that "Shared-addins" are not publishable 
and are distinct and different from document and application level 
VSTO addins, which are deployable.
    When I rebuilt my application as an application level 
VSTO addin, the publish option was available.

http://www.automise.com/Default.aspx?tabid=53&amp;aft=9813 Taken from above link:

      Assuming you're using Visual Studio 2008, we're unable to execute the web site 
    publish feature from FinalBuilder as it's partially implemented by the VS IDE. 
    You'll need to use to the MSBuild action to compile the application and then 
    use one of the other actions (FTP, File Copy, etc) in FinalBuilder to perform 
    the deployment. Visual Studio 2010 has fixed this problem by performing the 
    entire publish using MSBuild, see this post for more info: 
http://www.finalbuilder.com/forums....&amp;afv=topic 

Two threads that might help

http://devnet.jetbrains.net/thread/280420;jsessionid=5E8948AE810FFFF251996D85E7EB3FE3

http://stackoverflow.com/questions/2774955/visual-studio-publish-project-from-command-line

Gage
+3  A: 

If it is a WebProject you can use the Microsoft.WebApplication.targets. Unless you have installed the windows SDK on your build agent you will need to copy the targets file into your source control and reference it from your web project by adding:

<Import Project="{path to your tools}\Microsoft.WebApplication.targets" />

You can find the targets file here (depending on your os):

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications

Now you just need to update your msbuild task to reference the right targets:

<MSBuild Projects="{path to your web project file}"
         Targets="Build;ResolveReferences;_CopyWebApplication"
         Properties="Configuration=Release;Architecture=Any;WebProjectOutputDir={your web root};OutDir={your web root}\bin\" />
Bronumski
+2  A: 

Here is how I modified the .csproj file for an ASP.NET MVC project to deploy via TeamCity 5.1.2. In the .csproj file, replace the AfterBuild target with this XML (If there are already commands in your existing AfterBuild, you will have to merge them into these targets):

<PropertyGroup>
    <DeployTarget>0</DeployTarget>
    <PublishTarget>0</PublishTarget>
    <PublishFolder>..\Deployment\YourWebsiteName</PublishFolder>
</PropertyGroup>
<Target Name="PublishProperties">
    <CreateProperty Value="$(PublishFolder)">
    <Output TaskParameter="Value" PropertyName="WebProjectOutputDir"/>
    </CreateProperty>
    <CreateProperty Value="$(PublishFolder)\bin\">
    <Output TaskParameter="Value" PropertyName="OutDir"/>
    </CreateProperty>
</Target>
<Target Name="WebPublish" DependsOnTargets="BeforeBuild;PublishProperties">
    <RemoveDir Directories="$(PublishFolder)"
            ContinueOnError="true" />
    <CallTarget Targets="ResolveReferences;_CopyWebApplication" />
</Target>
<Target Name="Deploy" DependsOnTargets="WebPublish">
    <CreateProperty Value="Path\To\Your\Server" Condition="$(DeployFolder) == ''">
    <Output TaskParameter="Value" PropertyName="DeployFolder"/>
    </CreateProperty>
    <RemoveDir Directories="$(DeployFolder)" Condition="$(CleanDeploy) == 1" />
    <ItemGroup>
    <DeploymentFiles Include="$(PublishFolder)\**\*.*" />
    </ItemGroup>
    <Copy SourceFiles="@(DeploymentFiles)"
        DestinationFolder="$(DeployFolder)\%(RecursiveDir)" />
</Target>
<Target Name="AfterBuild">
    <CallTarget Targets="WebPublish" Condition="$(PublishTarget) == 1" />
    <CallTarget Targets="Deploy" Condition="$(DeployTarget) == 1" />
</Target>

This script uses the $(PublishTarget) and $(DeployTarget) properties to trigger additional steps after your project is built. The PropertyGroup at the beginning sets the default values to 0, so the extra targets are not run. You can override the default in TeamCity by going to the Properties and Environment Variables page of your build configuration and adding System Properties names "PublishTarget" and "DeployTarget" and setting their value to 1.

The Publish target contains most of the magic. This makes a call to the Visual Studio _CopyWebApplication target to output the website to the PublishFolder. By default the publish folder is "..\Deployment\YourWebsiteName" relative to the project file, but this can also be overridden with a System Property. The Deploy target takes the files output by the Publish target and copies them to the DeployFolder. DeployFolder can be set with a System Property in TeamCity or you can replace the "Path\To\Your\Server" path in the Deploy target.

You could also skip the extra Deploy step by simply setting the PublishFolder to whatever your deployment destination is. This script depends on the "Microsoft.WebApplication.Build.Tasks.Dll" and "Microsoft.WebApplication.targets" files installed by Visual Studio, but you can simply copy the files from your developer workstation to the build server. The default location is "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications".

nslowes