I have a solution in VS2010 and it has three project, two of these projects have web config file, the projects have web config transformation for each environment (dev, test and prod).
At the process for TFS build option, I have the at the MSBuild Arguments : /p:DeployOnBuild=True
Everything looks good, the drop folder, the zip files and all structure for the final deployment. The issue I am facing the web config for test and prod is not created correctly after the final deployment, I could see at the drop folders the file projectName.SetParameters.xml, it contains the values for development when the build has been QUEUE for Test and Prod. One of the project has the correct web config (test and prod) but the other project has always the dev webconfig.
Is it a bug in the MS Build? What am I missing in the build parameters?
When I create a build deployment package the web config transformation creates the correct web config file, no issues with this process, but I do not want to use build deployment package to deploy my solution.
Any help will be appreciated.
Thank you.
In your Build Definition you probably defined the Configurations to use. Part of that also defines something like Any CPU or x86. As it turns out the solution the Platform "Any CPU" has a space where in the project files the Platform Any CPU does not have a space.
I found the best way to get around this was to leave the Platform blank and only put in the configuration name. VS will pop up a warning letting you know that there is data missing, you can just hit "Yes" to save it anyways. Alternatively you can just type in your configurations like the following |Release,|Debug.
The pattern is [PlatformName]|[ConfigurationName],[PlatformName]|[ConfigurationName],...
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.
We're pretty new to TeamCity at work. We have a build & deployment pckage setup which is using MSBuild/MSDeploy to ship changes to our web servers. However, we have a few issues (apologies for putting a few questions on the same post). For clarification our solutions looks like so:
Project Folder
WebApp (includes .csproj file. Includes a folder called "media" - this folder is not in SVN)
Libraries (includes referenced assemblies)
Our issues:
There is a specific folder within the Libraries folder that must be copied into the bin directory after build (because of an assembly redirect). We have always used a PostBuild event, however this doesnt work in TeamCity.
The folder "media" within the WebApp folder is not included in SVN. When the TeamCity package is executed it deletes this folder. I would like to prevent TeamCity from deleting just this folder.
When we run the TeamCity task, we get an ERROR_FILE_IN_USE error for one of the files teamcity is trying to delete during the sync task. I have read about using the app_offline.htm file to combat this - but quite how Im not sure.
I'm going to guess that some of these settings can be command line parameters in the msbuild job - I think it would be better to store these in the csproj file rather than just in teamcity if it is possible?
thanks in advance
Al
A few questions on the information provided
Can you clarify what you mean by post-build command doesnt work? Does it fail or does it just not do what you expect?
How have you setup your post-build command? does it reference specific filepaths? TeamCity executes MSBuild in the same was as you could from the command line or from visual studio.
Regarding the MSDeploy folder issue, you can configure MSDeploy with a Skip Action, here's a link to another post describing how to do this
Prevent MSDeploy (selectively) from deleting folders on target IIS server
Because MSDeploy is trying to deploy into a folder being used by IIS you are also seeing the file locking issue. There are two solutions
1. Add a teamcity step to stop IIS (using PowerShell) before deploying. This will cause downtime.
2. Deploy to a different folder and then switch IIS to point to your new folder. This is a much better solution as you also have roll back.
A much easier solution to all of this is to use a Deployment Tool such as Octopus Deploy to deploy your application. You can learn more about Octopus Deploy at http://octopusdeploy.com/
I am trying to set different artifact paths configuration wise. e.g
In general settings of teamcity I am specifying following artifact paths:
testing\obj\Deploy-Dev\package
testing\obj\Deploy-Test\package
testing\obj\Deploy-Live\package
But when I am publishing a site using the following:
/M /P:Configuration=%env.Configuration% /P:DeployOnBuild=True/P:DeployTarget=MSDeployPublish /P:MsDeployServiceUrl=%env.TargetServer%/MsDeployAgentService /P:DeployiisAppPath=%env.IISPath% /P:MSDeployPublishMethod=RemoteAgent /P:CreatePackageOnPublish=True /P:Username=%env.username% /P:Password=%env.password%
In this step I am using only 1 configuration. I am assuming that by specifying these artifact paths. it will also transform the web configs according to specified configuration. But it is only transforming the one specified while actually packaging.
Any idea how to have web configs transformed in all packages as well.
I am not sure if I fully understand your question but here is what I think that you are asking. "How can I create a web package which has all the web.config transforms required so that I can publish the same package to multiple different environments?"
Unfortunately the way that packaging works is that the web.config is transformed using the web.config transform of the build configuration which is being built. Then the transformed web.config file makes it into the package. The transform files are not packaged.
I do realize that it's important to create a single package and publish that to different locations. We were not able to build the features into the box but I have created a NuGet package, PackageWeb, which can help in this case. I have a 5 minute video posted at http://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspx which you can take a look at. I am fairly certain that it will help in your scenario. FYI the code for package-web is open source at https://github.com/sayedihashimi/package-web. We do have some known issues. If you do end up using this please do let me know.
Try setting a environment variable for your teamcity artifact path.
testing\obj\%env.Configuration%\package
Troy Hunter -You're deploying it wrong! TeamCity, Subversion & Web Deploy part 5: Web Deploy with TeamCity
Artifact paths do not affect build\packaging process anyhow. They just provide ability to keep some files\folders available after build for further access.
If you want to produce 3 different packages, you will need to specify 3 corresponding build steps in your configuration and get rid of '%env.Configuration%'.
I just downloaded TeamCity 7 today and decided to get it up and running for my Azure solution. I am not trying to do anything fancy (yet) and started with a very basic command line build:
msbuild /t:Publish /p:Configuration=Release;TargetProfile=Production;PublishDir=S:\HoursTracker\Deployments
This builds successfully and produces a package that looks like this*:
I then attempted to configure TeamCity in an identical fashion:
This builds successfully and produces a package that looks like this*:
What I don't understand is why there is such a huge discrepancy in the size of the MVC project. Publishing directly from Visual Studio produces the exact same result as my MSBuild command so I'm convinced that TeamCity is the odd man out. Since I assume TeamCity is not broken, can someone please educate me on how to properly configure it so that I get the expected output?
*I have renamed the package files with .zip so that the details were viewable for this post.
Ming's answer helped me solve the mystery. After inspecting the contents of the zip files, I discovered the difference was that my MSBuild package contained bin and obj folders and the TeamCity package did not.
After making this discovery, I realized that I could specify multiple targets to MSBuild and prepended "Clean" to my targets switch like so:
msbuild /t:Clean;Publish /p:Configuration=Release;TargetProfile=Production;PublishDir=S:\HoursTracker\Deployments
As expected, this removed those folders. So apparently, TeamCity specifies "Clean" implicitly for you. Mystery solved.
Windows Azure packages may be larger than we expect. You can rename the cssx file to zip and you will find out what’s inside the package. In addition to the web application’s usual files, there’re a bunch of Windows Azure files. For example, if you enable diagnostics, you will see a diagnostics folder, where you’ll find files used by Windows Azure diagnostics runtime.
Best Regards,
Ming Xu.
Why you specified x64 for msbuild runner? Try selecting tools version as well. You have not specified /p:Platform parameter. Does publish task involve rebuild?
TeamCity starts msbuild with number of /p: parameters taken from " properties and environment variables " section, plus some well-known parameters like configuration name or project name.
I've got a fairly large MVC2 project in TFS which gets built automatically on checkin (Continuous Integration)
At present, the fully built version is dumped on a network share on our dev IIS server. \\Server\wwwrootLatest
TFS of course creates lots of sub-folders since it's just doing a build, it isn't even aware that it's drop directory is a wwwroot.
This means that to actually USE the build, we need to go and manually create an IIS App which points at the appropriate directory - which defeats the whole object of the exercise.
When we do a manual publish to that server, we use "File System" as the method and just overwrite the files in the UNC share \\Server\wwwroot
(When publishing to other environments, we use full-on MSDeploy.)
What I'd like to do is convince TFS to do a "File system" publish after the build completes and duplicate what we do on a manual publish eg:
Drop directory is \\Server\Build which would result in something like \\Server\Build\Project\Date.Rev\
After that is complete, we want it to publish to \\Server\wwwrootLatest - we can then set up the App once which will always contain the latest version but will still have a full history if required.
The only examples I've been able to find use MSBuild commands in the build definition (fine) but all use MSDeploy to do a full-on publish. I'm not sure how to automate what I want to do
Any help appreciated.
In your drop folder a folder named _PublishedWebsites is generated automatically. It contains files you need to put in wwwroot. You can use CopyDirectory build activity to copy them automatically.