<build type="nant">
<baseDirectory>D:\dotNetDelivery\Chapter6\</baseDirectory>
<buildArgs>-D:solution.stub=Library.Transformer -D:debug=false</buildArgs>
<buildFile>Build.Core.xml</buildFile>
<targetList>
<target>ci</target>
</targetList>
<buildTimeoutSeconds>300</buildTimeoutSeconds>
</build>
Here we call a target called ciin the Build.Core.Xmlfile. This target does not exist yet, and
is another change on the list for that file later on. Additionally, we will always pass through a
debugvalue of falsewhile operating under CI. Debug runs will be executed via the regular
NAnt command line.
Apart from a nantbuild type, other types are available. These include the VS .NET
builder—using a call to devenv.exeto perform the compilation—and a command-line builder
that allows the invocation of arbitrary functions—for example, through a.batfile—to perform
the build. 
As time moves on, it is likely that support will be added for other build tools such as
MSBuild, Microsoft’s own build tool.
labeller
A project can be configured with a specific labeling strategy as is shown in the labellerelement.
CCNet can also be enhanced to handle different labeling techniques. The defaultlabeller
labeler handles only a prefix and then the incremental build number that CCNet maintains else-
where. This is different from the NAnt versioning technique that we have used up to this point,
and so the build files will need to change to account for this. The script we will use is as follows:
<labeller type="defaultlabeller">
<prefix>1.0.</prefix>
</labeller>
Tasks
Next up are a number of tasks that can be run following a successful build. These tasks are run
sequentially. One example is a <nunit>task, which will perform unit testing as appropriate.
This is useful if you are using a builder that is not NAnt but still want to follow the CI process;
otherwise, it is probably superfluous.
Caution
Mixing up the responsibilities of CCNet and NAnt could cause problems.Moving the unit-test
functions into CCNet removes the ability to fully test the process outside the CCNet harness.I think it is
probably best to let CCNet handle the triggering and so on,and let NAnt perform the work.
CHAPTER 6 CONTINUOUS INTEGRATION
181
Pdf to jpg - Convert PDF to JPEG images in C#.net, ASP.NET MVC, WinForms, WPF project
How to convert PDF to JPEG using C#.NET PDF to JPEG conversion / converter library control SDK
changing pdf to jpg; to jpeg
Pdf to jpg - VB.NET PDF Convert to Jpeg SDK: Convert PDF to JPEG images in vb.net, ASP.NET MVC, WinForms, WPF project
Online Tutorial for PDF to JPEG (JPG) Conversion in VB.NET Image Application
.net convert pdf to jpg; convert pdf photo to jpg
The task that is of interest to us is the <merge>task for attaching the FxCop and NUnit
XML outputs to the build log of CCNet. This is easily done with a little matching, as shown
here. I probably could have just used a catchall *.xmlfilter, but it is possible I will use other
reports later on.
<tasks>
<merge>
<files>
<file>
D:\dotNetDelivery\BuildAreaCI\Reports\Etomic.Library.Transformer\*-results.xml
</file>            
<file>
D:\dotNetDelivery\BuildAreaCI\Reports\Etomic.Library.Transformer\fxcop.xml
</file>
</files>
</merge>
</tasks>
Publishers
Finally, once all work is complete, the build log is published in various ways. The usual
method is an xmllogger, which publishes the log to the CCNet web site and dashboards.
Thisis easily implemented in the following way:
<publishers>
<xmllogger />
</publishers>
Another useful publisher is the emailpublisher. It sends an email containing the styled
build log to interested parties. There are a few options for this publisher, but in general the
script will look something like this:
<email from="marc@etomic.co.uk" mailhost="smtp.etomic.co.uk" includeDetails="TRUE">
<projectUrl>http://localhost/ccnet</projectUrl>
<users>
<user name="Marc" group="buildmaster" address=marc@etomic.co.uk"/>
<user name="Developer" group="developers" ➥
address="developer@etomic.co.uk"/>
</users>
<groups>
<group name="developers" notification="change"/>
<group name="buildmaster" notification="always"/>
</groups>
</email>
This task implementation ensures that the buildmaster is always informed when a build is
performed regardless of its success or failure. The developers group, however, is only informed
when there has been a change in the build status—for example, a shift from success to failed,
or vice versa.
CHAPTER 6 ■ CONTINUOUS INTEGRATION
182
Online Convert Jpeg to PDF file. Best free online export Jpg image
Download Free Trial. Convert a JPG to PDF. Web Security. All your JPG and PDF files will be permanently erased from our servers after one hour.
best pdf to jpg converter online; change format from pdf to jpg
Online Convert PDF to Jpeg images. Best free online PDF JPEG
Download Free Trial. Convert a PDF File to JPG. Web Security. Your PDF and JPG files will be deleted from our servers an hour after the conversion.
convert pdf file into jpg format; convert multipage pdf to jpg
Note
This publisher has obvious utility but is usually difficult to maintain.If you operate in an environ-
ment with many systems and rotating pools of developers (in that agile way),then adding and removing
developer interests is a constant game.You may want to consider a blanket policy of “everybody gets
everything”and then rely on the developers to filter the unimportant stuff.We see some other options in
Chapter 9,too.
This completes the configuration settings we need for our projects. Because we already
have a set of functioning automated build scripts and because we have enforced certain stan-
dards—naming, organization, and so on—then the script for all three projects is essentially
identical. The most obvious differences are in details such as the interested developers for
theemail publisher, and whether we choose to use a multisource control for the dependent
projects.
Amending the Build.Core.Xml File
Before we look at the operation of CCNet, some changes need to be made to the build scripts
we have (the integration is not entirely seamless!).The changes are simple, though, and are
not needed in the specific build files, but just in the Build.Core.Xmlfile. The relevant parts of
this file are shown here, with the changes in bold:
<?xml version="1.0" encoding="utf-8" ?> 
<project name="Build.Core" default="help">
<description>Build file to perform core common functionality.</description>
<property name="nant.onfailure" value="fail"/>
<property name="company.name" value="Etomic"/>
<property name="solution.name" value="${company.name}.${solution.stub}"/>
<property name="core.directory"
value="D:\dotNetDelivery\BuildAreaCI"/>
<property name="core.source"
value="${core.directory}\Source\${solution.name}"/>
<property name="core.output"
value="${core.directory}\Output\${solution.name}"/>
<property name="core.docs"
value="${core.directory}\Docs\${solution.name}"/>
<property name="core.reports"
value="${core.directory}\Reports\${solution.name}"/>
<property name="core.distribution"
value="${core.directory}\Distribution\${solution.name}"/>
<property name="core.publish"
value="${core.directory}\Publish\${solution.name}"/>
<property name="vss.dbpath" value="D:\dotNetDelivery\VSS\srcsafe.ini"/>
CHAPTER 6 CONTINUOUS INTEGRATION
183
C# Image Convert: How to Convert Adobe PDF to Jpeg, Png, Bmp, &
String inputFilePath = @"C:\input.pdf"; String outputFilePath = @"C:\output.jpg"; // Convert PDF to jpg. C# sample code for PDF to jpg image conversion.
change file from pdf to jpg; change pdf to jpg on
C# Image Convert: How to Convert Tiff Image to Jpeg, Png, Bmp, &
RasterEdge.XDoc.PDF.dll. String inputFilePath = @"C:\input.tif"; String outputFilePath = @"C:\output.jpg"; // Convert tiff to jpg.
convert from pdf to jpg; convert pdf to 300 dpi jpg
<property name="vss.path" value="$/Solutions/${solution.name}/"/>
<sysinfo/>
In this section, I have changed around the folder organization so that differing output
types are arranged together. I have also arranged a new build area for CI. Because we are using
a web site to capture build logs and so on, it makes sense to use the Web to enable the pub-
lishing of the assets generated during the build. 
This organization allows me to create virtual directories under the CCNet dashboard
application mapped to the publish, documentation, and reports folders. When a new project
is added to the process, it will appear automatically. The virtual directories should be set to be
browsable, and the default document can be set if appropriate (for example, to default.aspx).
Figure 6-8 shows this configuration. 
Figure 6-8.Configuring virtual directories for published assets
With this configuration, the deploy scripts can be changed to obtain assets via the Web
rather than a file share. We will complete the work on the build script first, then look at the
deploy scripts.
<target name="go" description="Build Target" 
depends="clean, get, version1, version2, specific"/>
<target name="ci" description="CI Target" 
depends="clean, version1, version2, specific"/>
The next change is the addition of a target specifically for CI. The differing dependencies
are simple: using the CI target, NAnt does not need to get the source code, since CCNet will
behandling this work from now on. We maintain the gotarget so that we can run the script
CHAPTER 6 ■ CONTINUOUS INTEGRATION
184
JPEG to PDF Converter | Convert JPEG to PDF, Convert PDF to JPEG
similar software; Support a batch conversion of JPG to PDF with amazingly high speed; Get a compressed PDF file after conversion; Support
convert pdf to jpg c#; batch convert pdf to jpg online
JPG to JBIG2 Converter | Convert JPEG to JBIG2, Convert JBIG2 to
Image Converter Pro - JPEG to JBIG2 Converter. Convert JPEG (JPG) Images to, from JBIG2 Images on Windows.
changing pdf to jpg on; convert pdf to jpg batch
outside of CCNet. As you will have observed in the CCNet configuration, the citarget is called
from the nantbuild element.
<target name="clean" description="Clean up the build environment.">
<!--Do not delete core.source-->
<delete dir="${core.output}\" failonerror="false"/>
<delete dir="${core.docs}\" failonerror="false"/>
<delete dir="${core.reports}\" failonerror="false"/>
<delete dir="${core.distribution}\" failonerror="false"/>
<mkdir dir="${core.source}\" failonerror="false"/>
<mkdir dir="${core.output}\" failonerror="false"/>
<mkdir dir="${core.docs}\" failonerror="false"/>
<mkdir dir="${core.reports}\" failonerror="false"/>
<mkdir dir="${core.distribution}\" failonerror="false"/>
<mkdir dir="${core.publish}\" failonerror="false"/>
</target>
A simple but important change to the cleantarget is the removal of the deletion of the
source directory. As CCNet handles source code differently—it manages the removal of old
code automatically—it is unnecessary and can cause CCNet to be confused about changes
tothe code.
<target name="version1" description="Apply versioning to the source code files.">
<property name="sys.version" value="0.0.0.0"/>
<ifnot test="${debug}">
<property name="sys.version" value="${ccnet.label}.0"/>
</ifnot>
<!-- Rest of target snipped -->
</target>
Since versioning is now handled by CCNet, in terms of the build number, then the ver-
sioning statement is changed to remove the reliance on the NAnt <version>task. We can
delete the *.Build.Numberfiles as they are no longer required. As the labeler in CCNet only
handles prefixes, we need to add a suffix at this point to the ccnet.labelproperty to get the
correct number and format. The property ccnet.labelis passed through by CCNet as it
invokes NAnt. Other useful properties are due to be added too.
Note
A while back there was a useful discussion about these properties on the CCNet mailing list.The
addition of certain properties could assist with some of the problems identified earlier—for example,the
inability of NAnt to react to different types of incoming CCNet build requests.Keeping an eye on the CCNet
JIRA (issue tracking web site) is well worthwhile.
Those are all the changes required for the Build.Core.Xmlfile, and they are the only
changes needed overall to include the scripts generated in Chapter 5 into the CI process.
CHAPTER 6 CONTINUOUS INTEGRATION
185
JPG to GIF Converter | Convert JPEG to GIF, Convert GIF to JPG
Converter. Convert JPEG (JPG) Images to, from GIF Images on Windows. JPEG to GIF Converter can directly convert GIF files to JPG files.
conversion of pdf to jpg; convert pdf image to jpg
JPG to DICOM Converter | Convert JPEG to DICOM, Convert DICOM to
Image Converter Pro - JPEG to DICOM Converter. Convert JPEG (JPG) Images to, from DICOM Images on Windows.
.pdf to .jpg online; change pdf file to jpg
Amending the Deploy Scripts
As we mentioned earlier, we can adjust the deployment scripts to make use of the virtual
directories and web access to the published assets. This is quite straightforward; an example
isshown here:
<property name="core.publish"
value="http://localhost/ccnet/files/${solution.name}"/>
Thecore.publishproperty is now set to the location of the published assets on the web
dashboard site. We can then change the gettarget to obtain the assets via HTTP:
<target name="get" description="Grab the correct assets.">
<delete dir="${core.deploy}\" failonerror="false"/>
<mkdir dir="${core.deploy}\${sys.version}\"/>
<get 
src="${core.publish}/${solution.name}-Build-${sys.version}.zip"
dest="${core.deploy}\${solution.name}-Build-${sys.version}.zip" 
/>
<unzip 
zipfile="${core.deploy}\${solution.name}-Build-${sys.version}.zip" 
todir="${core.deploy}\${sys.version}\"
/>
</target>
Creating a Startup Script for the Server
A minor but useful action is to create a startup .batfile for the CCNet server. It should contain
something like the following command, and it should be located in the same folder as the
ccnet.configfile that we have generated. This allows the config file to be maintained some-
where other than where the server executable is located.
"D:/dotNetDelivery/Tools/CCNet/0.8/Server/CCnet.exe" -remoting:on ➥
-config:ccnet.config
Note
Although the server works with this setting,if it needs to use assets such as the XSL files—
forexample,when transforming the build log for the email publisher—it will look for the files relative to the
ccnet.configfile rather than the server application.So there are two options:copy the XSL files to the
same relative location as the config file,or run the config file from the default location.I have chosen the
former because of the need to maintain the cohesion of the source code for the book.
CHAPTER 6 ■ CONTINUOUS INTEGRATION
186
We are now in a position to run the server. This can be done by executing the batch file we
created earlier. If everything is okay, we will see a screen like the one in Figure 6-9.
Figure 6-9.The CCNet server console
The first time that you run the server it is likely that builds will be attempted for all of
theprojects since CCNet has no records of the projects. To avoid this, you could change the
triggertype to a scheduled type at some later point in time. This allows the server to run
without building. You can then selectively force-build the projects individually to ensure that
the process works.
Examining the Dashboard
Regardless of the method chosen to ensure that the scripts work, the server is now running,
which means the dashboard is available for use and examination. After a few builds, the dash-
board screen will likely look something like the one shown in Figure 6-10.
CHAPTER 6 CONTINUOUS INTEGRATION
187
Figure 6-10.The functional CCNet dashboard
In Figure 6-10 we can see that our three projects have been successfully built a number of
times. We can drill into the individual projects by clicking on the name link. The initial screen,
at the time of writing, has no details, but the formatted build log can be viewed by clicking on
the link for the desired build. Figure 6-11 demonstrates this output. 
Figure 6-11.A CCNet build log
CHAPTER 6 ■ CONTINUOUS INTEGRATION
188
Here the build log shows that the unit tests were successfully run, and lists any modifica-
tions (in this case none!) to the source code of the project, along with the reason the build was
run: in this case, it was forced. 
If we move back to the main screen for the dashboard, then we can force a build using
thebuttons to the right if desired. There is also another way of doing it, as we see in the next
section.
Examining the cctray application
cctrayis an application that sits in the system tray of a developer’s machine, as shown in
Figure 6-12.
Figure 6-12.The cctray application
cctraytakes advantage of the remoting interface of the CCNet server in the same way as
the dashboard and so can also be used to monitor the build status of projects and to force a
project build. The cctrayicon is green when the build is successful and red when it fails. The
settings for the application are simple: connect to the required CCNet server instance and
select a project for monitoring, as shown in Figure 6-13.
Figure 6-13.cctray settings
CHAPTER 6 CONTINUOUS INTEGRATION
189
Right-clicking on the cctrayicon and selecting the Force Build option will force the build
of the currently selected project for the CCNet server instance. During the interval of the
build, no other force build can be performed, and the icon for the build becomes yellow. At
the end of the build cycle, a balloon will appear from cctraynotifying you of success or fail-
ure, as shown in Figure 6-14.
Figure 6-14.A cctray notification
Tip
This small feature of the CCNet suite is a friendly way to introduce the development team to the prin-
ciples of CI or automated builds.
Examining the State File
When CCNet begins looking after a project, it maintains the information in a state file. This
will be called something on the order of <project>.stateand resembles the following:
<?xml version="1.0" encoding="utf-16"?>
<IntegrationResult xmlns:xsd=http://www.w3.org/2001/XMLSchema ➥
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Status>Success</Status>
<LastIntegrationStatus>Success</LastIntegrationStatus>
<ProjectName>Etomic.Transformer.Web</ProjectName>
<BuildCondition>IfModificationExists</BuildCondition>
<Label>1.0.3</Label>
<StartTime>2004-12-19T16:55:55.4036619-00:00</StartTime>
<EndTime>2004-12-19T16:56:14.4661619-00:00</EndTime>
<WorkingDirectory>
D:\dotNetDelivery\Chapter6\Etomic.Transformer.Web\WorkingDirectory
</WorkingDirectory>
</IntegrationResult>
This file ensures that the server can be restarted without losing any information. Ordinar-
ily there is no need to tamper with this file, but it is useful to know that it can be manipulated
to perform testing or to reset or modify a label, for example.
Testing the multi Source Control
During the configuration of the CCNet server, we set up both the Windows and web projects
tobe triggered on the basis of a deployment of the library assembly using the multisource
CHAPTER 6 ■ CONTINUOUS INTEGRATION
190
Documents you may be interested
Documents you may be interested