I have a web api project and I want have different web.config build when I switch to say "release" and build.
In the past for window services I used on the app.config SlowCheetah and when I would build it would build whatever was selected in the dropdown(ie debug/release).
I read something that web.configs don't need slowCheeta but when I use the dropdown, change to release and look in the bin folder it is not using the release web.config.
How can I make this work?
Bonus would be if I could do it on debugging as well.
Related
I've noticed that octopack is including the Roslyn folder under the bin folder for my web deployment. What would be the preferred method for excluding this from the build without affecting development. I considered a post build event in only the "release" solution config to delete it but wondered if there was a better way (and it doesn't need to be specific to octopus).
This folder is added by the Microsoft.CodeDom.Providers.DotNetCompilerPlatform nuget package. If you want C#6 support in Asp.Net (.cshtml or .aspx) files it needs to be there, because the roslyn's csc.exe from that folder is used to compile your views.
In order to be able to remove it (not deploy it), you'd need to precompile your web application with aspnet_compiler.exe
First post on Stack, so please be gentle!
We are just getting into Continuous Integration with TeamCity. We have setup a TeamCity project(s) that looks like so:
Solution Build (builds entire solution) - .Sln file
Debug to Dev Server (builds .csproj in Debug configuration and Deploys to test server using MSDeploy)
Release to Production (builds .csproj in Release configuration and Deploys to production server using MSDeploy)
Within our Umbraco Visual Studio project (which is a Web Application not the standard Website project type) we have the umbraco_client and umbraco folders excluded from the Project, primarily because they are already compiled and don't need to be re-compiled by our process. Both folders are however included in the SVN repo.
The problem we are experiencing is that because these two folders are excluded from the Visual Studio project, TeamCity does not deploy them.
So my question boils down to "how do you include folders in the TeamCity build package where the folders are in the SVN but excluded from the Visual Studio project?".
Any pointers would be really appreciated.
Thanks
dotdev
We've been using TeamCity for umbraco. This is what we've been doing recently on our internal dev servers:
/p:Configuration=Debug
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=OurDevServer/msdeployagentservice
/p:AllowUntrustedCertificate=True
/p:MSDeployPublishMethod=RemoteAgent
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath=umbraco_site
/p:IgnoreDeployManagedRuntimeVersion=True
/p:FilesToIncludeForPublish=AllFilesInProjectFolder
/p:SkipExtraFilesOnServer=True
/p:ExcludeFoldersFromDeployment="media;App_Data\Logs;App_Data\preview"
/p:IncludeSetAclProviderOnDestination=False
/p:AuthType=NTML /p:UserName=
They key to solving the problem you are having is
/p:FilesToIncludeForPublish=AllFilesInProjectFolder
By default, it is set to something like "AllFilesInProject". Combining FilesToIncludeForPublish with the ExcludeFoldersFromDeployment can give you some control over exactly what TeamCity attempts to deploy
I would suggest using an approach similar to the one described in this blog post: http://blog.iqit.dk/2013/11/using-package-restore-in-umbraco-projects
You don't mention nuget, so assuming you use a zip or web pi to setup Umbraco in your solution, but you should still be able to use the targets listed in msbuild or add to your web applications .csproj when building your solution. It would require that you have the Umbraco and Umbraco_client folders somewhere in Svn repo or on your build server in order to copy it in.
As an alternative I can also recommend that you download the UmbracoCms nuget as that contains an extension to the msdeploy pipeline that includes the two mentioned folders in an msdeploy zip package. But again also based on the nuget install and thus a standard location for the Umbraco folders.
Hope this helps.
I've based my TeamCity builds on Troy Hunt's excellent "You're Deploying it Wrong" series - which is an excellent step by step guide to integrating Visual Studio based projects and TeamCity. http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html
As to excluding the umbraco and umbraco_client folders from SVN; a complex Umbraco build will probably have changes in the Umbraco folder to the default build eg adding Umbraco Event Handlers, adding new Umbraco Sections, changes to back-office tabs. I don't think umbraco_client will change unless you get into changing rich text editors and so on - but it is possible. So I'm not sure that excluding those particular folders is correct. Excluding the media folder is often discussed as well - but it does make TeamCity config simpler if everything is there.
But to answer your question you could exclude them from the build and copy them onto your build server; then add a 'Command Line' runner build step that simply copies them back into place before the build step starts.
I usually add a source control change step that fires a rebuild and have two build steps in TeamCity for an Umbraco project. One is a 'Visual Studio (sln)' runner to check that the sln file has every reference and third party product set up correctly (this should eliminate the 'it works on my machine' issues); and the second is a 'MSBuild' runner that replicates the csproj build process. With the second build step with the right permissions (if your ports are open on the machine you're deploying to, or you're deploying to the same machine as you are on) you could test this in Visual Studio or DOS.
These two build steps should be able to deploy to the IIS website on a staging server; and if the right ports are open on your live or UAT server you could then add a third build step and deploy it onwards (if the first two build steps run properly).
I've got a Visual Studio 2010 solution that I would like to add a project to that only contains some command-line scripts. This project isn't meant to actually compile/build anything, but I want to be able to edit my scripts with the rest of the solution, and have TFS integration etc.
Unfortunately, in searching I get a lot of results for errors where builds don't happen, or other conditions where specific build targets are implemented. I simply want a non-build project in VS as a visual repository for the editor. I don't want to one-by-one include individual files in a solution folder.
In the build configuration manager (On the Menu, "Build", "Configuration Manager"), there is a "build" checkbox for each project. Uncheck it for your script project.
Could you make a content project, add your scripts to it, then change their properties to "Do not compile"?
I am using CruiseControl.Net for my continuous integration process. Using ccnet I build and publish my asp.net application into a server in Release mode. But I am not able to change debug="true" to debug="false" in my Web.Config during publishing. What can I do?
You might consider using a Web Deployment Project (WDP) which can be run as part of your visual studio build configuration. The WDP will handle things like toggling the debug setting and it change any environment-specific web.config settings as well. Here's a WDP tutorial.
If you are calling a msbuild script from ccnet you could use the XmlUpdate task from the MSBuild Community Tasks Project.
<XmlUpdate
XPath="/configuration/system.web/compilation/#debug"
XmlFileName="$(WebConfigFileFullPath)"
Value="false" />
I documented my build process here if you are interested.
Expanding on Tom Brothers' answer above, we use the <XmlMassUpdate> task in MSBuild Community Tasks to merge a deployment-specific web.config that contains multiple changes to apply to the base web.config to change the debug setting, connection strings, logging configuration, etc. So a web project contains web.config with the configuration necessary to run from the development machines. There's also web.Release.config file which contains only the changes that we need to apply to web.config to produce the configuration on the production web server.
Since the extra file only contains changes (deltas) to apply to web.config, it's not very big. Visual Studio ignores it during development, and CruiseControl.Net applies the changes to web.config when it gets deployed to the web server.
Can anyone shed some light on how to get Team Build 2010 beta 2 to push a SQL database project to the SQL server?
In VSTS 2008 you'd just add MSBuild commands with the targets attribute set to "deploy" in the TFSBuild.proj file, but I'm having a little trouble translating that to the new workflow based xaml thing that 2010 uses.
What I'm looking for is how to trigger the actual deployment of the databases themselves. It is already generating the deployment scripts just fine.
For anyone still looking for the answer, use an Invoke Process that uses vsdbcmd.exe:
http://msdn.microsoft.com/en-us/library/ff805001.aspx
Here is an example:
http://www.nablasoft.com/alkampfer/index.php/2009/10/06/deploy-a-database-project-with-tfs-build/
It may be that you are simply missing the DeployToDatabase=true
There is another solution to this problem if you don't need incremental database upgrade. So if recreating the database for each build is ok with you the following would also work.
Add a deploy target to Database Project file
Configure the deployment settings for ‘My project settings’. Those settings will then be used by the build server when building the solution. When building locally, the settings used will be the ones from ‘My isolated development environment’.
In the database project properties
Deploy Action needs to be ‘Create a deployment script (.sql) and deploy the database’; this will prevent the execution of the script, it will only create it.
Database project file
Modify the database project file (right-click database project, select Unload, right-click again, select Edit [ProjectName].dbproj)
from
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
To
<Project DefaultTargets="Build;Deploy" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
When the Build server builds the solution containing the database project, adding the default targets will also deploy the database. This build will use the Deploy settings selected for ‘My project settings’.
Pros
Easy to set up
Cons
Because the default target is changed to Build and Deploy, when a developer do a local Rebuild of the solution, it will also deploy the database (building only won't trigger the deployment)
The closest thing I've found so far is this post from Jim Lamb (the Team Foundation PM at Microsoft).
Here he talks vaguely about creating a custom proj file and modifying the default build process template to invoke the proj file.
He also talks about using the upgrade template, which I'd previously ignored. Apparently the upgrade template can be used to invoke a 2008 build definition. I'd rather not invoke and define the entire build based on the legacy proj file though, but at least it is an option.
Neither topic contains sufficient information for me to actually make the modifications necessary, but it does give me a reasonable starting point for some future experimentation.