I am setting up a Continuous Integration server.
I have one issue that doesn't seem to be mentioned in the tutorials.
I have a ASP.net Web Application that I need to compile and them publish.
My Problem is that I seem to be able to compile the app but when I attempt to use a buildPublisher this copies every thing including .svn files & folders and ms CS files.
I am using an MSBuild task to compile my source. I tried setting my MSBuild Output Directory to directory but this didn't seem to have any effect.
What am I not understanding?
Thanks
You're probably looking for the _CopyWebApplication directive:
http://blogs.msdn.com/nmoreau/archive/2007/01/26/deploying-web-application-projects.aspx
We use CruiseControl.NET to deploy our ASP.NET applications to our test servers for the QA department so this is indeed possible.
In each project we created an additional build configuration called 'Deployer' which is identical to the Debug configuration with the exception of building an additional Web Deployment Project. So by running MSBuild in the Deployer configuration we can generate our compiled output in a known location.
We then use NAnt to perform a simple copy operation to the required location, i.e. into a folder where our IIS server is configured to look for the applications.
I know you don't mention NAnt in your question but it's well worth getting familiar with it if you want to get the most out of CCNet.
I'm not at work at the moment but if this makes any sense and you want some additional information then let me know and I'll pull some more information together.
Hope this helps
Are your bin or obj folders checked into svn? if so that would contribute or possibly cause this issue.
Because those folders shouldn't have any svn folders/files
You can configure SVN to call the .svn folders _svn instead.
Set the SVN_ASP_DOT_NET_HACK environment variable.
Related
I've got an MVC 5 project stored in Git. I've installed TeamCity 9.1.7 (build 37573) on our build server and I've set it up to successfully perform a build when a developer checks in code to Git. My goal is to deploy the MVC application using MS Web Deploy if the build is successful. I've seen a number of tutorials that suggest using a web deploy package, but these tutorials are six or more years old. Is this still the preferred method for deploying a successful TeamCity build to IIS?
Further, we've added the web.config file to gitignore for a number of reasons. Git houses as Web.config.base that developers will copy to their own web.config file as a starting point. A developer will copy the web.config.base file to web.config when they first pull down the project. I've tried to set up a command line task in TeamCity to xcopy the web.config.base file to web.config
Working Directory: (left blank)
Command: xcopy MyMVCProject\Web.config.base MyMVCProject\Web.config
This build step fails with exit code 4 at all times. I've set the TeamCity build agent service to run as a local administrator. I've tried this as straight command text as above, as a cmd or bat file, and with a variety of different path styles, going so far as to use the TeamCity working directory variable, excluding the MyMVCProject from the path, including the MyMVCSolution in the path, etc. Any ideas as to why the xcopy would fail?
This is the same problem I was facing.
But at last, we put the master web.config file on the server where TeamCity is installed.
Then once the Project gets deployed , I replaced the web.config file with the web.config file which is alreay present on server.
So there will be no conflict in the web.cofig file
You just need to add one more build step after the Web deploy step.
In that you can use Xcopy and you can replaced you web.config file
Hope this will work
WebDeploy is still a great option for deploying ASP.NET web applications. Its even used with the brand new ASP.NET Core framework. We don't use TC but do you WebDeploy/MSDeploy extensively at work to deploy 50+ applications.
Regarding your config setup, I've never seen this approach. We use Parameterization to handle config changes per environment (local dev included). If you're worried about security of the config values, you could secure your SetParameter files which have the sensitive info and include the web.config in source control with default or placeholder values.
http://www.dotnetcatch.com/2014/09/08/parameterizationpreview-visual-studio-extension/
So I have this pretty huge solution with many projects, few of them use dlls from other projects in this solution, some projects copy files to other directories after build is performed. (as post build events)
when I build the solution locally on my machine, everything is great and working, but when i configure a build, and build it on build server (we use TFS) something goes wrong and i get a an error when i try to load one of the applications in this solution. (the error does not give me much data on what went wrong)
so before i sit to debug all of this. does anybody know how can i smartly manage all the build actions that are performed locally and via build server and see the deltas?
I would like to be able to build the solution exactly the same on build server as i do on my machine (with directory structure, post build events..etc)
thanks a lot
The generally accepted way to do what you're after is to use NuGet for managing your assembly references. You can publish your dependent assemblies into NuGet as part of a continuous delivery process, then reference (and update!) those dependencies in the solutions that consume them as necessary.
This removes ambiguity ("What version of Foo.dll is Project X using?") and reduces runtime errors ("Why is Project X using Foo.dll 3.0? It was never tested with 3.0! It needs to run with 2.7!").
I work with a solution that has a lot of projects in it. I created a new build configuration to speed up working with it.
To speed up compiling, I set most of the projects not to build in my new build configuration.
To speed up debugging, I set most of the projects to build for release in my new build configuration.
This is great, until I have to check in a change to the project file, or get the latest from someone else's changes to the project file. It is painful to merge the changes, or shelve and unshelve them constantly.
Is it possible to store my build configuration in a separate file? Ideas for workarounds welcome.
To answer the question directly: no you cannot store your config in a seperate file. Unless that seperate files is also a solution file of course. But there are some workarounds, all stored locally on your machine (too long for a comment so I'm posting an answer anyway):
I set most of the projects not to build in my new build configuration
just build them once, then unload the projects so they will not be built again. These settings are stored in the .suo file.
if you insist on keeping a seperate build configuration: ask the team if it's ok to push it into the source control, maybe others can benefit from it as well?
or write a script to transfrom the original solution file into one having our build config. That can be as simple as applying a patch, which you should keep up-to-date
To speed up debugging, I set most of the projects to build for release
write a script to delete the pdb files of those projects
for C++: add all namespaces of those projects to the natstepfilter file
I'm just looking at streamlining the nuget packages that are coming out of my build system and I'm stuck on how to only package the files that are required.
I have several configurations sharing a Root VCS checkout. I have a configuration that runs a debug build with unit tests. I also have a release configuration that does a release build, this configuration then also uses the TeamCity OctoPack plugin to create the nuget packages.
What I want to achieve is the building of nuget packages that don't contain the *.pdb and *.xml documentation files as these aren't required for the release deployment.
I've looked through this page on the OD site:
http://docs.octopusdeploy.com/display/OD/Using+OctoPack
And according to this page OctoPack should only package up the required files by default. I'm not entirely clear on how or what needs to be done to get around this problem as it doesn't appear to be working as described.
It seems that one solution would be to provide a nuspec file for the projects I'm looking to deply but I'm also wondering if there is something I'm missing before I head off down that route.
I also have some MEF plugins that are copied in post build events and these aren't included in the nuget packages when in fact they are needed for the application to run. I think I need to get explicit with a nuspec file but would like to confirm this.
What is the simplest way of achieving what I need?
Assuming you're running the later versions of OctoPack, in your release build you can set a system parameter system.DebugType = None which will get passed to the OctoPack build scripts and prevent the PDB's being created.
This simply overrides the setting defined in your csproj msbuild file (assuming C#), so you can use it wherever you want to prevent PDB's being created at the build configuration level (not just OctoPack). I generally prefer this approach as it prevents side-effects in your build from changes by developers in the project file.
As for the xml files, I haven't actually tried this, but you can try a similar approach and create a system parameter system.DocumentationFile = "" to blank out the output.
If you really want to make sure that the files have been removed there are a couple of ways you can do this. Modify your deployment process to:
Execute your own custom PowerShell script in that removes the files
Include a script module from the Octopus Library to the same. Check out the File System - Clean Directory from the Octopus Library
Ok, I know this is not a programming question.. but I'm sure its related to improving productivity of programmer.
I am trying to use CruiseControl http://cruisecontrol.sourceforge.net/ to implement continuous integration in our work flow. Each developer has separate machine to develop with.. with one centralized db server. We work mostly with Visual Studio to develop asp.net applications. And we have a centralized SVN server on the same system we're having db server.
Now I'm trying to integrate Cruise Control, but not sure what is the best way. I am particularly not able to decide...
In solution file path, do we need to pass a local path? So, in that case should we copy a one copy of project source code on server to execute? Or is there any better automated way to achieve this? Can we use SVN URL in solution file path...?
I'm sure there is must be a way to do this fully automated, but how?
In the project build node you will need to define the local path for the build server and the SVN URL so CruiseControl can grab the code from the centralized SVN server. You can use NANT or MSBuild plugin to define specific configurations for the build server to avoid mis configuration with the server. Below is an example of the ccnet.config file that need to be defined in the build server
<project name="Calculator-Service">
<schedule type="schedule" sleepSeconds="15"/>
<modificationDelaySeconds>2</modificationDelaySeconds>
<sourcecontrol type="svn">
<trunkUrl>svn://svn.mycompany.com/myfirstproject/trunk</trunkUrl>
<workingDirectory>C:\ccnetexamples\eci\working\service</workingDirectory>
</sourcecontrol>
<build type="nant">
<executable>C:\ccnetexamples\eci\working\service\tools\nant\nant.exe</executable>
<baseDirectory>C:\ccnetexamples\eci\working\service</baseDirectory>
<buildFile>nant.build</buildFile>
<targetList>
<target>ci</target>
</targetList>
<buildTimeoutSeconds>300</buildTimeoutSeconds>
</build>
<publishers>
<xmllogger>
<logDir>..\web-service\log</logDir>
</xmllogger>
</publishers>
</project>
look at
http://www.cruisecontrolnet.org/projects/ccnet/wiki/Configuration
There is a step by step guide for Build Server Scenarios.
with build script and ccnet.config examples.
IMNO, the best way to think of CC.NET is a "super fancy msbuild.exe" executor.
Write a msbuild (.proj) and put the majority of your logic in it.
Including "pull code down from svn and place it in this local directory"
Then you cc.net task will pull down this .proj file....and then use the msbuild.exe task to execute that .proj file.
Since you only have a very small amount of logic in the cc.net proprietary tasks, if you pick another CI tool, its not a hard transition.