VSoft Technologies BlogsVSoft Technologies Blogs - posts about our products and software development.https://www.finalbuilder.com/resources/blogsIntroducing Continua CI Version 1.9.1 Betahttps://www.finalbuilder.com/resources/blogs/postid/835/introducing-continua-ci-version-191-beta.NET,Continua CI,Delphi,DeploymentWed, 01 May 2019 07:00:08 GMT<p>This new <a href="/downloads/continuaci/continua-ci-version-history-v191" target="_blank">beta release</a> includes substantial improvements to the expressions engine including new several expressions objects and functions. We have also made some updates to the stage editor, implemented automatic report generation for some reporting actions, and added several new deployment actions providing support for Docker, Azure, SQL packages, File Transfer and SSH.</p> <p>Continue reading for details of all the new features.</p> <ul> <li><a href="#expressions-engine">Enhanced expressions engine</a></li> <li><a href="#stage-editor-changes">Stage editor changes</a></li> <li><a href="#deployment-actions">New premium deployment actions</a></li> <li><a href="#other-actions">Other new and updated actions</a></li> <li><a href="#automatic-reporting">Automatic reporting</a></li> </ul> <h2><a name="expressions-engine">Enhanced expressions engine</a> <a class="up-link" href="#" title="Go to top"><img src="/images/up-icn.png" /></a></h2> <p>The expression engine in Continua CI evaluates expression objects and variables denoted with $ and % characters. It also provides auto-completion suggestions when typing such expressions into expression fields. This has now been overhauled to include function return types, chaining of functions, nesting functions as function parameters, selection and filtering of collections and many improvements to expression parsing. We have added several new functions, objects and collections to give access to more values and allow you to manipulate those values.</p> <p><img alt="Expression in Set Variable action list categories" src="/blogimages/daves/v1.9.1/SetVariableAction.png" /></p> <p>You can now, for example, use the following expression to get the time that the penultimate build stage finished;</p> <pre class="brush:javascript;toolbar:false;gutter:false;"> $Build.Stages.Item($Build.Stages.Count.Decrement()$).Finished.ToLongTimeString()$</pre> <p>combine the result of multiple flags by chaining functions, as in this expression;</p> <pre class="brush:plain;toolbar:false;gutter:false;"> $Build.HasErroredStages.Or($Build.HasFailedStages$).Or($Build.HasWarnings$)$</pre> <p>or use the following expression to get the comment of the first build changeset in the build containing the word 'merge' (ignoring case):</p> <pre class="brush:plain;toolbar:false;gutter:false;"> $Source.SuperFancyRepo.Changesets.First(Comment, Contains, "merge", true).Comment$</pre> <p>We have also included functions to get the value of a variable as a type, allowing you to use properties or functions on the variable value.</p> <p>You can, for example, now use the following expression to get the abbreviated day of the week from a variable entered using a DateTime prompt;</p> <pre class="brush:javascript;toolbar:false;gutter:false;"> $Utils.GetDateTime(%DateTimeTest%).DayOfWeek.Substring(0, 3)$</pre> <p>use expressions to do some more complex maths on a Numeric variable;</p> <pre class="brush:plain;toolbar:false;gutter:false;"> $Utils.GetNumber(%NumberTest%).Floor().Modulus(10).Multiply(100)$</pre> <p>or get the first selected value in a checkbox select variable with this expression:</p> <pre class="brush:plain;toolbar:false;gutter:false;"> $Utils.GetString(%CheckboxSelectTest%).SplitWithQuotes(",").First()$</pre> <p>You can see a full list of available expression objects, collection and functions on the <a href="https://wiki.finalbuilder.com/x/C4DmAQ">Expression Objects page</a> of the documentation.</p> <p>Auto-completion has also been revamped so show more information in the suggestions list. A list of parameters with types is now shown for each for each function. Descriptions are also displayed on mouse over for each object, collection and function in the suggestions list. We have also removed some annoying quirks with expression auto-completion where the cursor would end up in the wrong place or end characters would be added in the wrong place.</p> <h2><a name="stage-editor-changes">Stage editor changes</a> <a class="up-link" href="#" title="Go to top"><img src="/images/up-icn.png" /></a></h2> <p>As Continua CI matures, the number of actions (and categories) has increased. This can make it more difficult to find the action you need. We have therefore redesigned the action list.</p> <p>The list of categories has been pulled up into a drop down menu with all actions listed below by default.</p> <p><img alt="Action list categories" src="/blogimages/daves/v1.9.1/ActionListCategories.png" /></p> <p>The filtering of actions using the search box is now fuzzier, using partial and keyword matches.</p> <p><img alt="Action list search" src="/blogimages/daves/v1.9.1/ActionListSearch.png" /></p> <p>Stage buttons now resize (up to a maximum) to fit the stage name. If you stage names are short, this means you can fit more stages into your browser width. If your stage names are long, then the text will no longer escape the stage borders. Really long stage names which do not fit the maximum stage button size will now be truncated.</p> <p><img alt="Stages" src="/blogimages/daves/v1.9.1/Stages.png" /></p> <p>All actions now include a Validate button to allow you to check that all fields have valid values before saving.</p> <h2><a name="deployment-actions">New premium deployment actions</a> <a class="up-link" href="#" title="Go to top"><img src="/images/up-icn.png" /></a></h2> <p>We have added a set of premium actions which can be used for deploying the results of your build. The following actions can only be used if you have purchased one or more concurrent build licenses.</p> <p><b>File Transfer action:</b> This allows you to upload files to a remote server via FTP, FTPS and SFTP. <a href="https://wiki.finalbuilder.com/x/GADc" target="_blank" title="Further information on File Transfer action"><img src="/images/info.png" /></a></p> <p><b>SSH Run Script action:</b> This can be used to run a script or list of commands on an SSH server. <a href="https://wiki.finalbuilder.com/x/KIAJAQ" target="_blank" title="Further information on SSH Run Script action"><img src="/images/info.png" /></a></p> <p><b>Azure actions:</b> Several new actions are available to allow you to deploy web apps, function apps, files and blobs to Azure. <a href="https://wiki.finalbuilder.com/x/OwBJAg" target="_blank" title="Further information on Azure actions"><img src="/images/info.png" /></a></p> <p><img alt="Azure actions" src="/blogimages/daves/v1.9.1/AzureActions.png" /></p> <ul class="horizontal"> <li>Create Azure Resource Group</li> <li>Delete Azure Resource Group</li> </ul> <ul class="horizontal"> <li>Create Azure App Service Plan</li> <li>Delete Azure App Service Plan</li> </ul> <ul class="horizontal"> <li>Create Azure Web App</li> <li>Deploy Azure Web App</li> <li>Upload Azure Web App</li> <li>Control Azure Web App</li> <li>Delete Azure Web App</li> </ul> <ul class="horizontal"> <li>Create Azure Function</li> <li>Deploy Azure Function</li> <li>Delete Azure Function</li> </ul> <ul class="horizontal"> <li>Create Azure Storage Account</li> <li>Get Azure Storage Account Keys</li> <li>Delete Azure Storage Account</li> </ul> <ul class="horizontal"> <li>Create Azure Storage Container</li> <li>Delete Azure Storage Container</li> </ul> <ul class="horizontal"> <li>Upload Azure Blob</li> <li>Delete Azure Blob</li> </ul> <ul class="horizontal"> <li>Create Azure File Share</li> <li>Delete Azure File Share</li> </ul> <ul class="horizontal"> <li>Create Azure Directory</li> <li>Delete Azure Directory</li> </ul> <ul class="horizontal"> <li>Upload Azure File</li> <li>Delete Azure File</li> </ul> <p><b></b></p> <p><b>Docker actions:</b> These new actions are available to allow you to build, deploy and manage Docker containers. <a href="https://wiki.finalbuilder.com/x/AwAPAg" target="_blank" title="Further information on Docker actions"><img src="/images/info.png" /></a></p> <ul class="horizontal"> <li>Docker Build</li> <li>Docker Command</li> <li>Docker Commit</li> <li>Docker Inspect</li> <li>Docker Pull</li> <li>Docker Push</li> <li>Docker Run</li> <li>Docker Stop</li> <li>Docker Tag</li> </ul> <p><b></b></p> <p><b>SQL Package actions:</b> These new actions allow you to create, update and export SQL Server database schemas and table data. <a href="https://wiki.finalbuilder.com/x/PwBJAg" target="_blank" title="Further information on SQL Package actions"><img src="/images/info.png" /></a></p> <ul class="horizontal"> <li>SQL Package Export</li> <li>SQL Package Extract</li> <li>SQL Package Import</li> <li>SQL Package Publish</li> <li>SQL Package Script</li> </ul> <h2><a name="other-actions">Other new and updated actions</a> <a class="up-link" href="#" title="Go to top"><img src="/images/up-icn.png" /></a></h2> <p><b>Extent Reports:</b> Wrapper for the Extent Reports CLI for reporting on NUnit results. <a href="https://wiki.finalbuilder.com/x/3oE6Ag" target="_blank" title="Further information on Extent Reports action"><img src="/images/info.png" /></a></p> <p><b>ReportGenerator:</b> Updated to include all the latest command line options. <a href="https://wiki.finalbuilder.com/x/WQMZ" target="_blank" title="Further information on ReportGenerator action"><img src="/images/info.png" /></a></p> <p><b>Rename Directory:</b> Does what it says on the tin.. <a href="https://wiki.finalbuilder.com/x/BgAxAg" target="_blank" title="Further information on Rename Directory action"><img src="/images/info.png" /></a></p> <h2><a name="automatic-reporting">Automatic reporting</a> <a class="up-link" href="#" title="Go to top"><img src="/images/up-icn.png" /></a></h2> <p>Currently, there are a few steps to configure when setting up a report. You have to ensure that the report files are included in the Workspace Rules and that the report is defined in the Reports section of the configuration wizard. Furthermore, it's also recommended to include the report files in the artifact rules so that you can control when they are cleaned up.</p> <p>To simplify this process, we have added a new option to automatically register the report with the server to actions which generate reports (FinalBuilder, ReportGenerator and the new Extent Reports action). Ticking this option shows a new tab where you can enter the name, description and run order of the report. When a stage completes, any report files generated by actions where this option is turned on, will automatically be copied to the server workspace. The main report file will be registered as a report and all report files will be registered as artifacts.</p> <p><img alt="FinalBuilder automatic report option" src="/blogimages/daves/v1.9.1/FinalBuilderAutomaticReport.png" /></p> <p>Download the installers for Continua CI v1.9.1 Beta from the <a href="/downloads/continuaci" target="_blank">Downloads</a> page</p> <style type="text/css">ul.horizontal { overflow: auto; margin: 10px 0 0 0; } ul.horizontal li { float: left; margin-left: 2em } .syntaxhighlighter { background-color: #eee !important; margin-top: 0 !important; padding: 10px; outline-style: dashed; outline-width: 1px; outline-color: #666; width: 97% !important; } .syntaxhighlighter .line.alt2 { background-color: #eee !important; } .syntaxhighlighter table td.code { overflow-y: hidden !important; } .syntaxhighlighter .plain, .syntaxhighlighter .plain a { color: #639099 !important; } h1 { margin-bottom: 0.6em !important; } .up-link { float: right } </style> 835Introducing Continua CI Version 1.9https://www.finalbuilder.com/resources/blogs/postid/782/introducing-continua-ci-version-19.NET,Continua CI,Delphi,General,Web Development,WindowsTue, 14 Aug 2018 13:47:08 GMT<p><img alt="" src="/blogimages/dave/ContinuaCIWizardImageSmall.png" style="border-width: 0px; border-style: solid; margin-right: 5px; margin-left: 5px; width: 55px; height: 55px;" /></p> <p>Version 1.9 is now out of beta and available as a stable release. Thank you to those of you who have already tried out the beta - especially those who reported issues.</p> <p>This version brings major changes to the notifications system. We redesigned it using a common architecture, that makes it much easier to add new notification publisher types. Where previously, only email, XMPP and private message notifications were available, there are now publishers for Slack, Teams, Hipchat and Stride. And we can now add more (let us know what you need).</p> <p><img alt="" src="/blogimages/dave/PublisherTypes.png" style="width: 626px; height: 399px; display: block; margin-left: auto; margin-right: auto; " /></p> <p>We are no longer limited to one publisher of each type. You may, for example, have different email servers for different teams on your company. You can set up two email publishers, one for each server, and set up subscriptions so that notifications from different projects go to different email servers. Likewise for different Slack workspaces, Teams channel connectors and so on.</p> <p>We have also improved the XMPP publisher to support sending notifications to rooms. Subscriptions have been improved, allowing you to specify a room and/or channel for this and other publishers.</p> <p><img alt="" src="/blogimages/dave/Subscription.png" style="display: block; margin-left: auto; margin-right: auto; width: 625px; height: 733px;" /></p> <p>User preferences have been updated allowing each user to specify a recipient id, username or channel per publisher.</p> <p><img alt="" src="/blogimages/dave/UserPreferences.png" style="width: 726px; height: 751px; display: block; margin-left: auto; margin-right: auto; box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19);" /></p> <p>You can see some metrics on the throughput of each publisher (number of messages on queue, messages sent per second, average send time, etc.) on the Publishers page in the Administration area. This also shows real-time counts of any errors occurring while sending messages and also any messages waiting on a retry queue due to rate limiting or service outages. This allows you to know when you need to upgrade rate limits or make other service changes.</p> <p><img alt="" src="/blogimages/dave/PublisherMetrics.png" style="width: 990px; height: 306px; display: block; margin-left: auto; margin-right: auto; box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19);" /></p> <p>The Templates page has been updated. Templates are now divided into a tab per publisher. The list of available variables for each event type has been moved to a expandable side panel.</p> <p><img alt="" src="/blogimages/dave/NotificationTemplates.png" style="width: 564px; height: 707px; display: block; margin-left: auto; margin-right: auto; box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19);" /></p> <p>This release is built on .Net Framework version 4.7.2, which has allowed us to upgrade a number of third party libraries, including the database ORM and PostgreSQL drivers. This has noticeably improved performance, as well as providing us with a richer platform to build future features on. The setup wizard will prompt for you to install .Net Framework version 4.7.2, before continuing with the installation.</p> <p><img alt="" src="/blogimages/dave/InstallerFrameworkRequirement.PNG" style="width: 503px; height: 391px; display: block; margin-left: auto; margin-right: auto;" /></p> <p>Note that applications running on .Net 4.7.2 do not run on versions of Windows prior to Windows Server 2008R2 and Windows 7 SP1. We are also dropping the 32-bit server installer. This is mainly to reduce testing overheads. We will still be releasing 32-bit agents for those who are using 16-bit compilers.</p> <p>We will continue to provide bug fixes to Continua CI version 1.8.1 for while to give you time to migrate from older platforms.</p> <p> </p> <p> </p> 782Continua CI Roadmap 2018https://www.finalbuilder.com/resources/blogs/postid/776/continua-ci-roadmap-2018.NET,Continua CI,Delphi,Web DevelopmentMon, 18 Jun 2018 14:49:38 GMT<p>I'm not usually one for publishing roadmaps, mostly because I don't like to promise something and not deliver. That said, we've had a few people ask recently what is happening with Continua CI. </p> <div style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;"><strong><span style="color:#e74c3c;">Disclaimer - nothing I write here is set in stone, our plans may change.</span></strong></div> <p><br /> A few weeks ago, I wrote up a "roadmap" for Continua CI on the whiteboard in our office. Continua CI 1.8.x has been out for some time, but we have been working on 2.x for quite a while. The length of time it is taking to get some features out is a cause of frustration in the office, that lead to a lengthy team discussion, the result was a "new plan". </p> <p>One of the reasons we had been holding features back for 2.x, is they required a change in the system requirements. Many of the third party libraries we use have dropped .net 4.0 support, so we were stuck on old versions. So rather than wait for 2.0 we will release 1.9 on .net 4.7.2. This will allow us to release some new features while we continue working on 2.0, and to take in some bug fixes from third party libraries.</p> <p>This is "The Plan" :</p> <style type="text/css">.featureTable { border: 1px solid #0071c5; border-collapse: collapse; width:100%; margin-left: auto; margin-right: auto; font-size: 14px; } .featureTable thead { background-color : #0071c5; color : White; } .featureTable td { border: 1px solid #0071c5; padding : 5px; } </style> <table align="center" cellpadding="0" cellspacing="0" class="featureTable"> <thead> <tr> <td style="width: 70px;">Version</td> <td style="width: 130px;">.NET Framework</td> <td style="width: 70px">x86/x64</td> <td style="width: 170px;">Min OS Version</td> <td style="width: 70px">UI</td> <td>Features</td> </tr> </thead> <tbody> <tr> <td>1.8.x</td> <td>4.0</td> <td>both</td> <td>Windows Server 2003R2</td> <td>MVC 4</td> <td> </td> </tr> <tr> <td>1.9.0</td> <td>4.7.2</td> <td>x64</td> <td>Windows Server 2008R2</td> <td>MVC 5</td> <td>New Notifications types</td> </tr> <tr> <td>1.9.1</td> <td>4.7.2</td> <td>x64</td> <td>Windows Server 2008R2</td> <td>MVC 5</td> <td>Deployment Actions</td> </tr> <tr> <td>1.9.2</td> <td>4.7.2</td> <td>x64</td> <td>Windows Server 2008R2</td> <td>MVC 5</td> <td>Import/Export</td> </tr> <tr> <td>2.0.0</td> <td>netcore 2.1</td> <td>x64</td> <td>Windows Server 2012</td> <td>MVC 6</td> <td>New Architecture</td> </tr> <tr> <td>3.0.0</td> <td>netcore x.x</td> <td>x64</td> <td>Windows Server 2012</td> <td>TBA</td> <td>New User Interface</td> </tr> </tbody> </table> <p> </p> <p>Let's break down this plan.</p> <h2>1.9.0 Release</h2> <p>The 1.9 Release will built on .net 4.7.2, which allowed us to take updates to a number of third party libraries, most notably NHibernate and Npgsql (postgress driver). These two libraries factor heavily in the performance improvements we see in 1.9.0. </p> <p>The major new feature in 1.9.0 will be a completely redesigned notifications architecture. In 1.8, notifications are quite limited, offering only email, xmpp and private messages. There was very little shared infrastructure between the notification types, so adding new notification types was not simple. You could only use 1 mail server and 1 xmpp server.</p> <p>In 1.9.0, notifications are implemented as plugins*, using a common architecture that made it much easier add new notification types. You can also define multiple notification publishers of the same type, so different projects can use different email servers for example.</p> <p>Notification Types :  Private message, Email, XMPP, Slack, Hipchat, Stride. More will follow in subsequent updates (let us know what you need).</p> <p>*We probably won't publish this api for others to use just yet, as it will be changing for 2.0 due to differences between the .net framework and .net core.</p> <p>If you are running Continua CI on a 32-bit machine, then start planning your migration. Supporting both x86/x64 is no longer feasable, and dropping x86 support simplifies a lot of things for us (like updating bundled tools etc).  We will continue supporting 1.8.x for a while, but only with bug or security fixes. The minimum OS version will be the same as for the .Net Framework 4.7.2 - since Windows Server 2003R2 is out of support these days, it makes sense for us to drop support for it. </p> <h2>1.9.1 Release</h2> <p>Deployment focused actions.  <br /> <br />   - AWS S3 Get/Put<br />   - Azure Blob Upload, Publish, Cloud Rest Service, Web Deploy<br />   - Docker Build Image, Push Image, Run Command, Run Image<br />   - File Transfer (FTP, FTPS, SFTP)<br />   - SSH Action<br />   - SQL Package Export, Package Extract, Package Import, Package Publish<br />   - SSH Run Script<br />   - Web Deploy</p> <p>These actions are all mostly completed, but are waiting on some other (UI) changes to make them easier to use. We'll provide more detail about these when they closer release.</p> <p><strong>Note</strong> : These actions will only be available to licensed customers, not in the free Solo Edition.</p> <h2>1.9.2 Release</h2> <p>One of the most requested features in Continua CI, is the ability to Export and Import Continua CI Projects and Configurations. This might be for moving from a proof of concept server to a production server, or simply to be able to make small changes, and import configurations into other projects. The file format will be YAML.</p> <h2>Continua CI 2.0 Release - .net core.</h2> <p>We originally planned to target .net framework 4.7 with Continua CI 2.0, but with .net core improving significantly with netcore 2.0 and 2.1, the time is right to port to .net core. The most obvious reason to target .net core is cross platform. This is something we have wanted to do for some time, and even explored with mono, but were never able to get things working in a satisfactory manner. It's our hope that .net core will deliver on it's cross platform promise, but for now it's a significant amount of work just to target .net core. So that said, our plans for Continua CI 2.0 is to get it up and running on .net core on <strong>Windows only</strong>, without losing any functionality or features. During the port we are taking note of what our Windows dependencies are for future reference. </p> <p>The current (1.8.x) architecture looks like this :</p> <p><strong><span style="font-family:Courier New,Courier,monospace;">Browser <----> IIS(Asp.net with MVC)<--(WCF)-->Service <--(WCF)-->Agent(s)</span></strong></p> <p>With .net core, it's possible to host asp.net in a service process, and that is what we have chosen to do. This cuts out the WCF layer between IIS and the service. .net core doesn't have WCF server support, and to be honest I'm not all that cut up about it ;) That said, we still need a replacement for WCF for communication between the agents and the server. We're currently evaluating few options for this.</p> <p>Continua CI 2.0  architecture currently looks like this :</p> <p><strong><span style="font-family:Courier New,Courier,monospace;">Browser <----> Service(hosting asp.net core 2.1/mvc)<--(TBD)--> Agent(s)</span></strong></p> <p>The current state of the port is that most of the code has been ported, the communication between the agents and the server is still being worked on, and none of the UI has been ported. We do have asp.net core and mvc running in the service. There are significant differences between asp.net/mvc and asp.net core/mvc, so we're still working through this, I expect it will take a month or so to go through and resolve the issues, then we can move on to new features. </p> <h3>Continua CI 2.0 - new features.</h3> <p>Rest API. This is something we had been working on for a while, but on the .net framework using self hosted Nancy (in the service, running on a separate port from IIS). Once we made the decision to port to .net core, we chose to just use asp.net rather than Nancy. Fortunately we were able to use much of what was already done with nancy on asp.net core (models, services etc) and we're currently working on this right now..</p> <p>Other features - TBA</p> <h2>Continua CI 3.0 - A new UI</h2> <p>Asp.net MVC has served us well over the years, but it relies on a bunch of jQuery code to make the UI usable, and I'll be honest, no one here likes working with jQuery! Even though we ported much of the javascript to typescript, it's still hard to create complex UI's using jQuery. The Stage Editor is a good example of this, even with some reasonably well structured javascript, it's still very hard to work on without breaking it. The UI is currently based on Bootstrap 3.0, with a ton of customisations. Of course Bootstrap 4.0 completely breaks things so we're stuck on 3.0 for now.<br /> <br /> So it's time to change tack and use an SPA framework. We've done proof of concepts with Angular and React, and will likely look at Vue before making a decision - right now I'm leaning towards React. Creating a new user interface is a large chunk of work, so work will start on this soon (it's dependent on the rest api). We're likely to look at improving usability and consistency in the UI, and perhaps a styling refresh. </p> <p>Linux & MacOS Agents - with .net core running on these platforms, this is now a possibility. We looked at this several times before with Mono, but the api coverage or behavor left a lot to be desired. We do still have some windows specific stuff to rework in our agent code, and Actions will need to filtered by platform but this is all quite doable.</p> <h2>Summing up</h2> <p>We're making a big effort here to get features out more frequently, but you will notice I haven't put any timeframe on releases outlined above, they will be released when ready. We expect a 1.9.0 Beta to be out in the next week or so (currently testing the installer, upgrades etc), and we'll blog when that happens (with more details about the new notifications features). Note that it's highly likely there will be other releases in between the ones outlined above, with bug fixes and other minor new features as per usual. We have a backlog of feature requests to work from, many of which are high priorities, so we're never short of things to do (and we welcome feature requests). </p> 776Continua CI and TLS 1.2https://www.finalbuilder.com/resources/blogs/postid/761/continua-ci-and-tls-12.NET,Continua CI,Delphi,WindowsFri, 23 Feb 2018 09:24:09 GMT<p>SSL standards are changing, and older SSL/TSL protocols are slowly being deprecated, or even turned off by some services. This post shows how to enable TLS 1.2 support in Continua CI.</p> <p>Yesterday, we started getting reports that the Github Status event handler, and the Github Status action in Continua CI had stopped working.</p> <p>Sure enough, in our testing here we were able to confirm the case. While testing this under the debugger, the error we were seeing was rather strange : "The request was aborted: Could not create SSL/TLS secure channel.". </p> <p>After some research, we found this error was due to being unable to negotiate a common protocol between the client and the server.</p> <p>Now Continua CI 1.x is built with .NET 4.0 (v2 will be on 4.7.1) - we know that .NET 4.0 doesn't support TLS 1.2, and a quick check of the github api server using <a href="https://www.ssllabs.com/ssltest/" target="_blank">SSLLabs</a> shows that they now only support TLS 1.2.</p> <p style="text-align: center;"> <img alt="" src="/blogimages/vincent/continua-tls/github-ssllabs.png" width="987" height="279" /> </p> <br /> <p> I wondered if this was announced by github - turns out they did announce this 3 weeks ago :</p> <p> <a href="https://github.com/blog/2498-weak-cryptographic-standards-removal-notice" target="_blank">Weak cryptographic standards removal notice</a> </p> <p>and yesterday they permanently disabled TLS 1.0 and 1.1</p> <p> <a href="https://github.com/blog/2507-weak-cryptographic-standards-removed" target="_blank">Weak cryptographic standards removed</a> </p> <p>Anyway, back to Continua CI. The good news is that there is a way to enable TLS 1.2 support in Continua CI. Note that this only works when running on Windows Server 2008 or later (Server 2003 does not support TLS 1.2 at all, and we will be dropping support for it with v2).</p> <p>1) Install .Net Framework 4.5 or later - since all 4.x frameworks effectively replace 4.0 - 4.5 has support for TLS 1.2</p> <p>2) Edit %ProgramFiles%\VSoft Technologies\ContinuaCI\Server\Continua.Server.Service.exe.config on the server and %ProgramFiles%\VSoft Technologies\ContinuaCI Agent\Continua.Agent.Service.exe.config on each agent - add the following line in <strong>appSettings</strong> section :</p> <pre class="brush:xml; toolbar:false;"> &lt;add key="Continua.Service.SecurityProtocolType" value="Tls|Tls11|Tls12" /&gt; </pre> Note that the key supports the following values: Ssl2|Ssl3|Tls|Tls11|Tls12|Default<br /> <p> Default = Ssl3|Tls<br /> Multiple protocols can be separated with |<br /> The value "Tls|Tls11|Tls12" will allow Continua CI to work with services that do not support or have not enabled TLS 1.2, and with services that only support TLS 1.2 .</p> <p>3) Open Regedit and add the following value to : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 : SchUseStrongCrypto type DWORD value 1</p> <p>4) Restart the Server and Agent Services.</p> <p>5) You may need to restart your server(s) for the registry change to take effect.</p> <p>One last note : This change also effects the communication between the Continua CI Server and agents, if you make the change on the server, make sure you make a compatible change on the agents.</p>761Continuous Integration with FinalBuilderhttps://www.finalbuilder.com/resources/blogs/postid/755/continuous-integration-with-finalbuilder.NET,Continua CI,Delphi,FinalBuilderWed, 20 Sep 2017 13:49:00 GMT<p>In this post, I'm going to look at how to structure a FinalBuilder project so that it will run on your dev machine, or on your Continua CI Server without modification. This allows the best of both worlds, develop and debug your build process on your development machine, and then later run it on your CI server.</p> <p>I'm going to assume you are familiar with FinalBuilder to speed this along.</p> <h3>Version Control</h3> <p>The very first thing we need to do is add our FinalBuilder project to our version control system. This will ensure that the Continua CI agent will be able to access the projects.</p> <p>We typically create a Build folder in each repository that has our FinalBuilder projects, installer scripts etc. Make sure you save your projects in uncompressed format (ie, .fbp8 for FinalBuilder 8), as that will make it possible to diff project file changes using your usual diff tool (we use Beyond Compare 4).</p> <p>So in a typical repository, you might have a folder structure that looks something like this :</p> <pre> \Build \Src \Docs \Help \Tools \Output </pre> <p>Note the Output folder is ignored by our version control system (via .gitignore or .hgignore for example). Don't forget to add ignores for the finalbuilder log file as you don't want to commit that to the repo.</p> <p>This is the file structure I'll be using as the example in this post.</p> <h3>Build Workspace</h3> <p>Continua CI runs each build in a separate, clean build workspace folder. The reason for this is to allow multiple builds of the same configuration to be run concurrently (for example, building different branches at the same time). This means our folder structure above will be rooted differently for each build. So to deal with this, we will define some FinalBuilder Project Variables.</p> <h3>FinalBuilder Variables</h3> <p> </p> <p style="text-align: center;"><img alt="FinalBuilder Project Variables" src="/blogimages/vincent/ci-with-fb/fb-project-variables.png" /></p> <!-- <table width="250px" style="text-align:left;border-collapse:collapse;"> <tr style="border-bottom: 1px solid #777"> <th width="30%">Name</th> <th width="20%">Type</th> <th width="40%">Default Value</th> <th width="10%">Macro</th> </tr> <tr> <td>REPO</td> <td>string</td> <td>..</td> <td>no</td> </tr> <tr> <td>WORKSPACE</td> <td>string</td> <td>..</td> <td>no</td> </tr> <tr> <td>BUILD</td> <td>string</td> <td>%REPO%\Build</td> <td>yes</td> </tr> <tr> <td>SOURCE</td> <td>string</td> <td>%REPO%\Src</td> <td>yes</td> </tr> <tr> <td>LIBS</td> <td>string</td> <td>%REPO%\Libs</td> <td>yes</td> </tr> <tr> <td>OUTPUT</td> <td>string</td> <td>%WORKSPACE%\Output</td> <td>yes</td> </tr> <tr> <td>DOCS</td> <td>string</td> <td>%REPO%\Docs</td> <td>yes</td> </tr> <tr> <td>HELP</td> <td>string</td> <td>%REPO%\Help</td> <td>yes</td> </tr> <tr> <td>TOOLS</td> <td>string</td> <td>%REPO%\Tools</td> <td>yes</td> </tr> </table> --> <p> </p> <p> </p> <p>You can of course modify these variables to suite your needs. The REPO variable has a default value of "..", we will use the Path Manipulation action to expand that relative path when our build starts, using the FBPROJECTDIR variable as the base path. This will give us the root folder of our repository, which we can then use as the basis for other path variables.</p> <p> </p> <p><strong>Side Note:</strong> FinalBuilder does not support using unrooted relative paths. The best practice is to fully expand the relative path before using it. Relative paths need to be relative to something, and in windows that is typically the Current Directory for the process, however this is not viable in a multi-threaded application. Rooted relative paths (e.g "%SOURCE%\.." ) will work in most cases, however some windows api functions do not support relative paths at all.</p> <p>The WORKSPACE variable will have the path to the Continua CI build workspace folder. Depending on how your repository and <a href="http://wiki.finalbuilder.com/display/continua/Repository+Rules">repository rules</a> are structured, this might be different.</p> <h3>Repository Rules</h3> <p>Continua CI configurations can have multiple <a href="http://wiki.finalbuilder.com/display/continua/Repositories">Repositories</a> assigned to them, for example when building FinalBuilder, we have mulitple repos on the configuration, one for our source and three others for libraries. On our dev machines, we use symlinks to map the libs folder into our main repo's path, so we end up with :</p> <pre> MainRepo\Src MainRepo\Libs <- symlink to LibsRepo\ </pre> <p>This makes it easier to deal with search paths in Delphi, as we can just use simple relative paths. With .Net, working with libraries is so much simpler due to package managers like nuget or packet.</p> <p>At the start of a Continua CI Stage, the source code is exported from the Repository Cache (a Mercurial repo) for each repository associated with the Configuration. How and what gets exported is controlled by the Repository Rules for that Stage.</p> <p>The default rules looks like this :</p> <pre> $Source$ >> Source </pre> <p>This will export all associated repos to a folder structure like this</p> <pre> workspace\source\repo1 workspace\source\repo2 </pre> <p>In this example, I'm going to change the rules to mirror the folder structure on our dev machines :</p> <p style="text-align: center;"><img alt="Repository Rules" src="/blogimages/vincent/ci-with-fb/repo-rules.png" /></p> <p>This results in the following folder structure :</p> <pre> workspace\build workspace\src workspace\libs </pre> <p>Note that you can also use rules to limit which parts of the repository are exported to the workspace, so, for example, if you have files in the repository that are not needed for the build process, you can avoid exporting them and save some time (I/O is usually the biggest overhead) using exclusion rules.</p> <p>Getting back to our FinalBuilder variables, we can see from the above folder structure, that our WORKSPACE variable will have the same value as the REPO variable. If your folder structure is different then you will need to adjust accordingly.</p> <h3>Continua CI Stage Actions</h3> <p>Ok, so now we have a basic FinalBuilder project, and Repository Rules set up to export our source to the build workspace, now it's time to call FinalBuilder. Continua CI has a FinalBuilder Action for doing just that.</p> <p style="text-align: center;"><img alt="Continua CI - FinalBuilder Action" src="/blogimages/vincent/ci-with-fb/fbaction.png" /></p> <p>We need to tell the action where our FinalBuilder project file lives. This needs to be anchored by the workspace folder, e.g $Workspace$\Build\FB\FinalBuilderBuild.fbp8</p> <p>In the Variables tab, we will check the "Automatically apply Continua CI variable values to matching FinalBuilder variables." Option. If you want to send any protected Continua variables (ie passwords, api keys etc) to FinalBuilder, then check the "Save sensitive variable values to context XML file for use by FinalBuilder." option as well. Lastly, on the Environment Variables tab, we are passing some environment variables that are used in delphi search paths to FinalBuilder.</p> <p style="text-align: center;"><img alt="Continua CI - FinalBuilder Action" src="/blogimages/vincent/ci-with-fb/fbaction-variables.png" /></p> <p>We also set some environment variables that are needed for our build process, Continua CI makes this painless.</p> <p style="text-align: center;"><img alt="Continua CI - Set Environment Variables" src="/blogimages/vincent/ci-with-fb/fbaction-env.png" /></p> <h3>FinalBuilder Project</h3> <p>Remember that we want to be able to run the project on our dev machine and from Continua CI. So some logic is required to make sure it behaves the same way in both environments.</p> <p>I added some targets to the project, Init, Build and Test.</p> <p>The Init target is a dependency of the Default target, so it will always run first. This is where we initialise the variables, detect if the project is running from Continua CI or not, and set version info. We also create the Output folder here.</p> <p style="text-align: center;"><img alt="FinalBuilder - Init Target" src="/blogimages/vincent/ci-with-fb/fb-init-target.png" /></p> <p>Back in the Default target, we call the Build and Test targets. This is wrapped in a try/finally block and we export the FinalBuilder log file to %OUTPUT%\BuildLog.html in the finally section. We can register this file as an artifact and create a report definition in Continua CI to make it easy to view in the Continua CI UI. I've covered this before in an <a href="/resources/blogs/adding-custom-reports-to-continua-ci-build-results">earlier blog post</a>, so I won't cover it here.</p> <p style="text-align: center;"><img alt="FinalBuilder - Init Target" src="/blogimages/vincent/ci-with-fb/fb-default-target.png" /></p> <p>Note that you don't have to do the whole build/test/deploy all in one FinalBuilder project. When building FinalBuilder, we do the build & test in one project, and the deploy in another that is called from the Deploy stage. This avoids the temptation to deploy from a developer workstation!</p> <p>When we build Continua CI (on Continua CI of course), we have separate Build, Obfuscate, Test, Package & Deploy Stages that use different FinalBuilder projects. This allows us to run different parts of the build process on different agent machines. The .net obfuscation tool we use is very expensive, so we only have a single license which is installed on one agent machine, so the obfuscation stage will only run on that agent machine (vm). Continua CI selects the best agent based on agent properties and the Stages Agent Requirements. I'll cover this in more detail in another blog post.</p> <p>I have added this example project to the <a href="https://github.com/VSoftTechnologies/FinalBuilder.Examples">Examples repository on GitHub</a>.</p> 755Continuous Integration Server performancehttps://www.finalbuilder.com/resources/blogs/postid/754/continuous-integration-server-performance.NET,Continua CI,Delphi,FinalBuilder,Git,Mercurial,Web DevelopmentMon, 11 Sep 2017 14:31:58 GMT<p>Continuous Integration Servers are often underspecified when it comes to hardware. In the early days of Automated Builds, the build server was quite often that old pc in the corner of the office, or an old server in the data center that no one else wanted. Developers weren't doing many builds per day, so it worked, it was probably slow but that didn't seem to matter much.</p> <p>Fast forward 20 years, and the Continuous Integration Server is now a critical service. The volume and frequency of builds has increased dramatically and a slow CI server can be a real problem in an environment where we want fast feedback on that code we just committed (even though it "worked on my machine"). Continuous Deployment only adds to the workload of the CI server.&nbsp; </p> <p>In this post, I'm going to cover off some ideas to hopefully improve the performance of your CI server. I'm not going to cover compilation, unit tests etc. (which can be where a lot of the time is spent). Instead, I'll focus on the environment, machine configuration and some settings on your Continua CI configurations.</p> <h2>Hardware Requirements</h2> <p>It's impossible to provide hard and fast specs for hardware or virtual machines, as it varies greatly depending on the expected load.</p> <p>There are a bunch of things you can tweak that may improve performance. I will touch on some key points for virtual hosts, but I'm not going to go too deep into tuning virtual hosts, that's not my area of expertise. Of course, dedicated physical machines would be the ideal, but these days, even if you do get dedicated hardware for CI/CD, it's most likely going to be as a virtual host (hyper-v or vmware) rather than an OS installed on bare metal (do companies still provision a single os on bare metal servers these days?). Virtualisation brings in a whole bunch of benefits, but it also brings with it some limitations that cannot be ignored.</p> <p>Continuous Integration environments are mostly I/O bound and Continua CI is no different in that regard. So let's look at the various resources used by CI/CD.</p> <h3>CPU</h3> <p>It's unlikely that CPU will be a limiting factor in the performance of your CI server, unless you are running other CPU intensive tasks on your server. If that's the case, then move your CI server to dedicated hardware, or at least a dedicated virtual host. </p> <p>At a minimum you should have at least 2 cores on the server. On our production server, which is a virtual machine (on Hyper-V 2012R2) with 4 virtual cores and dynamic RAM, the Windows resource monitor shows that average CPU usage usually sits around 2% when idle (no running builds, measured on the guest OS using resource monitor on the Continua Server Service). With 10 concurrent builds running, the Continua CI server service was using around 6% cpu.</p> <p>Adding another 4 cores made very little difference. The Hyper-V host machine, which is also running a bunch of agent VM's, has plenty of CPU capacity, with the average CPU usage round 5-7%. Cutting down the number of cores to 2 did make a slight difference, with the VM showing slightly higher CPU usage, however no discernible difference in build times.</p> <p> This is obviously not very scientific, but it did demonstrate (well to me at least) that CPU is not the limiting factor. I set the server VM back to 4 cores and left it at that. Our Hyper-V host machines are a few years old now, and have 7200 rpm SAS hard drives (in Raid 10) rather than SSD's (they were still too expensive when we bought the machines).</p> <p>On a Continua CI Agent, we recommend at least 2 cpu cores, and limit the concurrent builds running on the agent to 1 per core. This isn't a hard and fast rule, just a convention we adhere to here (based on some performance testing). You may want to add extra cores depending on what compilers or tools you are running during your build process. The only way to know if this is needed is to monitor cpu on the agent machine while a build is running.</p> <h3>I/O</h3> <p>The most used resources are disk read/write and network read/write. Poor I/O performance will really slow down your builds.</p> <h4>Disk</h4> <p>It goes without saying, but use the fastest disks you have available to you. If you can afford it, new generation nvme/pcie SSD's are the way to go. They are still quite expensive for larger capacities though. At the very least, use a separate disk for the operating system and software installation, and another disk for your Continua CI Server's share folder (or the agents workspace folder on agent machines). This is where most of the I/O happens during builds. This recommendation applies whether running on dedicated hardware or in a virtual machine.</p> <p> If you are running the server and agent machines on the same virtual host (as we do for our production environment) then this is very important to get right. Poor I/O performance in virtualised environments is not uncommon - having agents and the server fighting for a slice of the same I/O pie is not a good idea.<br /> <br /> On the agent machines, good disk performance is critical. When a build is started on the agent, the first thing it does is create a workspace folder. It then exports the source code from the repository cache(s) (Mercurial repo which was cloned from the server) to that folder, using the repository rules (more on this later). This workspace initialisation phase can be very slow if you have poor I/O performance.</p> <h4>Network</h4> <p>Continua CI uses networking to transfer files, repository changes etc between the server and the agents. Poor network performance will impact on build initialisation times (updating the agents repo cache, build workspace) and on build completion times (transferring workspace changes back to the server). Logging between the agent and the server will also be impacted by poor network performance.</p> <p>By default, Continua CI uses SMB to transfer files, source code (repository caches) between the server and the agents. When the server's share folder is not accessible by SMB, Continua CI will try to use SSH/SFTP (Continua CI installs it own specialised SSH service). In high latency networks (for example if the agent is remote from the server), SSH/SFTP may perform better than SMB.</p> <p>You can force an agent to use SSH/SFTP by setting the agents ServerFileTransport.ForceSSH property to true.</p> <h3>Database</h3> <p>Continua CI supports PostgreSQL (the default) or Microsoft SQL Server. If you chose to use MSSQL, we recommend running it on a separate well specified machine. MSSQL is quite heavy in it's use of RAM and disk I/O - it's best run on a machine that has been tuned to run it properly. I'm not going to go into that here, that's a whole other topic on an area that I'm definitely not an expert.</p> <p>The PostgreSQL database server that is installed by default (unless you select otherwise) with Continua CI is much more more frugal when it comes to resources. On our main Continua CI server, PostgreSQL typically using around 60MB of ram. Contrast that with SQL Server running on my dev machine, not used or touched for weeks and it's using 800MB! PostgreSQL can also be tuned, we have tried to provision it with sensible defaults that strike a balance between performance and resource usage. If you need to tune PostgreSQL, then we recommend installing your own PostgreSQL instance and pointing Continua CI at it.</p> <p>Currently the Continua CI installer doesn't provide any options for the database install location (C:\ProgramData\VSoft\ContinuaCI\PostgreSQLDB ), this is something we are looking at for a future release, that will make it possible to put the database on it's own drive. For now, it's possible to move the database to another location by using a symlink, we have a few customers who have done this successfully. Contact support if you need help with this.</p> <h2>Virtualisation Tips</h2> <h3>Virtual CPU Cores</h3> <p>In a virtual environment, it's very important not to overload your virtual host. Note that there is a difference between overloading and over allocating virtual cores. It's a common practice to allocate more virtual cores across the virtual machines than there are physical/logical cores (logical when HyperThreading is enabled), but this has to be done with the knowledge and understanding of the load on the host machine. Overloading happens when so many cores are allocated and in use that the hypervisor is unable to schedule a core to a virtual machine when needed. This results in pauses and poor performance.</p> <p>In a clustered environment this is even more important, because when a cluster node dies, or is removed for upgrades etc, virtual machines will move to another node in the cluster - if that node is already overloaded then you will soon start hearing the complaints from users!</p> <p>The best explanation I have found on how hypervisors allocate cores is this article - <a href="https://www.altaro.com/hyper-v/hyper-v-virtual-cpus-explained/">https://www.altaro.com/hyper-v/hyper-v-virtual-cpus-explained/</a> - it's Hyper-V specific (we use Hyper-V here) but much of the information also applies to VMWare.</p> <h3>Virtual Disks</h3> <p>When creating separate virtual disk volumes for your virtual machines, try to put those virtual drives on different physical drives, so they are not competing for the same I/O. Use fixed size virtual disks.</p> <h2>Continua CI Configuration Tuning</h2> <p>Continua CI is not immune to performance problems, we're always working to make it faster and consume less resources. There are however a few things that can be tuned in Continua CI to improve performance.</p> <h3>Repository Branch Settings</h3> <p>Use specific branch patterns to narrow down the number of repository files and folders which are monitored and downloaded. With repositories which use folder-based branches, such as Subversion and TFS, consider moving old branches to a separate archive folder in your repository which will not match the branch patterns. Note that you can use more than one Continua CI repository per actual repository. Some users will have multiple projects in one repository, but only need to build a single one for each configuration. Make use of relative paths, where supported by your repository type, to limit your repository to a single project folder. This can significantly speed up repository initialisation and changeset updating. </p> <h3>Repository Polling</h3> <p>Continua CI polls repositories periodically to detect new commits. Each time this occurs, Continua CI invokes the command line client for that repo, and parses the output of that process. Some clients use a surprising amount of CPU. The git client, for example, uses around 8% CPU per instance on our production server while checking for commits. Most of the time, these processes only run for a very short amount of time (when no changes are detected), however if you have a lot of repositories, these small cpu spikes can add up.</p> <p> There are a couple of options to keep this under control.</p> <p> 1) Set the appropriate polling interval for your repositories. If changes to a repository occur infrequently, then there's no point polling frequently.</p> <p>2) Set the Server property Server.RepoMonitor.MaxCheckers property. This controls how many version control client processes are spawned concurrently, the default (5) is quite conservative so you should only need to lower this on a very low spec system. If you have plenty of spare CPU capacity, then you can increase this value, however if you do then monitor CPU usage to make sure you don't overload the server.</p> <p>3) Manual polling, using post commit hooks. This reduces CPU usage on the server, by only polling for repository changes when requested and has the added benefit of reducing the load on your version control server. This does take some setting up, and depends very much on the capabilities of your version control system. I'll take a look at post commit hooks in a future blog post.</p> <h3>Repository Path Filtering</h3> <p>Repository Path Filtering is an option on all repository types, with the exception of Mercurial (*I'll explain why shortly). What this filtering does is allow you to limit which files get added to the server's repository cache. This filtering has a few benefits, less disk space used on the server and the agents, less network I/O when transferring the changes from the server to the agent, and less I/O when checking out the source into the build workspace.</p> <p>A typical use case for these rules is when you have files in your repository that rarely change and are not needed for the build process (design docs, deployment notes etc). No point adding them to the repo cache if you don't use them.</p> <p>Changes to these rules won't affect files that are already in the repository cache, but it will avoid committing changes to those filtered out files to the repo cache. The best bang for buck with these filters will come if the repository is reset (the cache is rebuilt, so filtered out files are never committed to the cache), however that can be an expensive operation, so unlike other repository settings, changing these rules will not force a reset.</p> <p>* These filters don't apply to Mercurial repositories, as we use Mercurial for our repository cache. When you point Continua CI at a Mercurial repository, it just clones it to the server (repo cache), and then clones it to the agents (repo cache) without any modifcations.</p> <h3>Repository Rules</h3> <p>Each Stage has a settings tab called Repository Rules. These rules apply when checking out the source from the agent's repository cache(s) to the build workspace. Only check out the source you need, this will improve performance. If a stage doesn't need the source at all (for example, it's only working with artifacts from previous stages), then just blank out the Repository Rules field.</p> <p>Don't leave logging of the repository rules turned on unless you are debugging the rules. Logging the files exported to the workspace can be a real performance killer.</p> <h3>Workspace Rules</h3> <p>Similar to Repository Rules, these rules control which files are transferred between the server and agent's build workspace folders, and back again. Only transfer files back to the server's workspace that you actually need, like build artifacts, reports etc. </p> <p>Don't leave logging of the workspace rules turned on unless you are debugging the rules. Logging the files transferred can be a real performance killer.</p> <h3>Actions</h3> <p>Avoid logging too much information. For example, verbose logging on MSBuild should be avoided unless debugging build issues. Output logged from actions is queued and sent back to the server to be written to the build log, this causes high network and disk I/O.</p> <h3>Disk Space</h3> <p>Disk space is quite often at a premium (especially with SSD's), and it's important to keep on top of it. This is where the Clean up Policies come into play. Continua CI allows you to specify a global clean up policy for both the server and the agents, however it can be overridden at the Project or Configuration level. The clean up policy controls how long to keep old builds and their associated workspaces around. The clean up policy is highly configurable - use it to keep control over disk space. Bear in mind that the work of cleaning up old builds is quite I/O and database intensive, so be sure to schedule it to run during a quite period</p> <h3>Anti-virus Software</h3> <p>Anti-virus software can be a major performance killer, and in instances, an application killer. If I had a dollar for every time anti-virus software turned out to be the cause of a problem with Continua CI or FinalBuilder, well that would be some serious beer money at least!</p> <p>If you have anti-virus software installed on your server or agents, be sure to add exclusions from real-time scanning for the server's share folder, and the agent's workspace folder. Add scheduled scans on those folders instead. Also, when using the bundled PostgreSQL database, add an exclusion for C:\ProgramData\VSoft\ContinuaCI\PostgreSQLDB &nbsp;- otherwise you may experience database corruption.</p> <p>You should also consider adding an exclusions for the hg.exe in the "C:\Program Files\VSoft Technologies\ContinuaCI Agent\hg" folder. We found in testing that this will speed up the processing of the repostiory rules substantially (testing with windows defender). </p> <h3>Version Control Clients</h3> <p>Avoid installing tools like TortoiseSVN or ToirtoiseHG on your server or agent machines as these programs do background indexing (for icon overlays) and can also cause file/folder access issues.</p> <h2>Wrapping Up</h2> <p>I intend to revise this post as I learn more about performance tuning, especially in a virtual environment. If you have any techniques or tweaks that helped speed up your CI Server please feel free to share them with us (and fellow users).</p>754Visual Studio 2017 15.3 Update issueshttps://www.finalbuilder.com/resources/blogs/postid/751/visual-studio-2017-153-update-issues.NET,Continua CI,FinalBuilderThu, 17 Aug 2017 10:37:26 GMT<span style="color: #ff0000;"><strong>Update 25 Sept 2017 :</strong>&nbsp;Microsoft have closed our bug report with a Wont Fix status.. seems they are too busy with other things.<br /> </span><br /> The recent Visual Studio 2017 Update (also known as VS 15.3) &nbsp;introduced a problem with command line compilation when the Lightweight Solution Load feature is enabled for the solution.&nbsp;<br /> <br /> If you are using devenv (ie you have the Use MSBuild option unchecked in FinalBuilder), and have the action set to Rebuild... be aware that while the action will succeed, nothing actually gets compiled! <br /> Just to be clear, this is <strong>not</strong> a FinalBuilder (or Continua CI) problem :<br /> <br /> <div class="reCodeBlock" style="border: 1px solid #7f9db9; overflow-y: auto;"> <div style="background-color: #ffffff;"><span style="margin-left: 0px !important;"><code style="color: #000000;">"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.com" /rebuild "Release|Any CPU" ConsoleApps.sln</code></span></div> <div style="background-color: #f8f8f8;"><span style="margin-left: 0px !important;">&nbsp;</span></div> <div style="background-color: #ffffff;"><span style="margin-left: 0px !important;"><code style="color: #000000;">Microsoft Visual Studio 2017 Version 15.0.26730.3.</code></span></div> <div style="background-color: #f8f8f8;"><span style="margin-left: 0px !important;"><code style="color: #000000;">Copyright (C) Microsoft Corp. All rights reserved.</code></span></div> <div style="background-color: #ffffff;"><span style="margin-left: 0px !important;"><code style="color: #000000;">========== Rebuild All: 0 succeeded, 0 failed, 0 skipped ==========</code></span></div> </div> <br /> Turning off Lightweight Solution Load on the solution (don't forget to save the solution) results in proper compilation :<br /> <br /> <div class="reCodeBlock" style="border: 1px solid #7f9db9; overflow-y: auto;"> <div style="background-color: #ffffff;"><span style="margin-left: 0px !important;"><code style="color: #000000;">"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.com" /rebuild "Release|Any CPU" ConsoleApps.sln</code></span></div> <div style="background-color: #f8f8f8;"><span style="margin-left: 0px !important;">&nbsp;</span></div> <div style="background-color: #ffffff;"><span style="margin-left: 0px !important;"><code style="color: #000000;">Microsoft Visual Studio 2017 Version 15.0.26730.3.</code></span></div> <div style="background-color: #f8f8f8;"><span style="margin-left: 0px !important;"><code style="color: #000000;">Copyright (C) Microsoft Corp. All rights reserved.</code></span></div> <div style="background-color: #ffffff;"><span style="margin-left: 0px !important;"><code style="color: #000000;">1&gt;------ Rebuild All started: Project: ConsoleApps1, Configuration: Release Any CPU ------</code></span></div> <div style="background-color: #f8f8f8;"><span style="margin-left: 0px !important;"><code style="color: #000000;">2&gt;------ Rebuild All started: Project: ConsoleApp2, Configuration: Release Any CPU ------</code></span></div> <div style="background-color: #ffffff;"><span style="margin-left: 0px !important;"><code style="color: #000000;">3&gt;------ Rebuild All started: Project: ConsoleApp3, Configuration: Release Any CPU ------</code></span></div> <div style="background-color: #f8f8f8;"><span style="margin-left: 0px !important;"><code style="color: #000000;">4&gt;------ Rebuild All started: Project: ConsoleApp4, Configuration: Release Any CPU ------</code></span></div> <div style="background-color: #ffffff;"><span style="margin-left: 0px !important;"><code style="color: #000000;">1&gt;&nbsp; ConsoleApps1 -&gt; C:\Users\vincent.OFFICE\Documents\Visual Studio 2017\Projects\ConsoleApps\ConsoleApps1\bin\Release\ConsoleApps1.exe</code></span></div> <div style="background-color: #f8f8f8;"><span style="margin-left: 0px !important;"><code style="color: #000000;">2&gt;&nbsp; ConsoleApp2 -&gt; C:\Users\vincent.OFFICE\Documents\Visual Studio 2017\Projects\ConsoleApps\ConsoleApp2\bin\Release\ConsoleApp2.exe</code></span></div> <div style="background-color: #ffffff;"><span style="margin-left: 0px !important;"><code style="color: #000000;">3&gt;&nbsp; ConsoleApp3 -&gt; C:\Users\vincent.OFFICE\Documents\Visual Studio 2017\Projects\ConsoleApps\ConsoleApp3\bin\Release\ConsoleApp3.exe</code></span></div> <div style="background-color: #f8f8f8;"><span style="margin-left: 0px !important;"><code style="color: #000000;">4&gt;&nbsp; ConsoleApp4 -&gt; C:\Users\vincent.OFFICE\Documents\Visual Studio 2017\Projects\ConsoleApps\ConsoleApp4\bin\Release\ConsoleApp4.exe</code></span></div> <div style="background-color: #ffffff;"><span style="margin-left: 0px !important;"><code style="color: #000000;">========== Rebuild All: 4 succeeded, 0 failed, 0 skipped ==========</code></span></div> </div> <br /> MSBuild is not affected by this bug (<a href="https://developercommunity.visualstudio.com/content/problem/96511/visual-studo-153-devenv-rebuild-does-nothing-when.html">reported to Microsoft here</a>). Unless you have a very good reason for using devenv to compile visual studio solutions these days, just use MSBuild. <br /> <br /> &nbsp;<br />751Visual Studio 2017 RC Supporthttps://www.finalbuilder.com/resources/blogs/postid/749/visual-studio-2017-rc-support.NET,Continua CI,Delphi,FinalBuilderTue, 22 Nov 2016 14:44:36 GMTToday we released updates to <a href="https://www.finalbuilder.com/downloads/finalbuilder" target="_blank">FinalBuilder (8.0.0.2007)</a> and <a href="https://www.finalbuilder.com/downloads/continuaci" target="_blank">Continua CI (1.8.1.185)</a> which add support for Visual Studio 2017 RC.&nbsp;<br /> <br /> There were a few issues we found with Visual Studio 2017 Release Candidate. The first was, unlike every other previous version of Visual Studio, 2017 RC does not write any useful information to the registry that allows us to reliably find out where it was installed to. So at the moment, we just check the default install locations :<br /> <br /> On 64 bit windows :<br /> <br /> C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE<br /> C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE<br /> C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE<br /> <br /> on 32 bit windows (do people still use it?) :<br /> <br /> C:\Program Files\Microsoft Visual Studio\2017\Community\Common7\IDE\Common7\IDE<br /> C:\Program Files\Microsoft Visual Studio\2017\Professional\Common7\IDE<br /> C:\Program Files\Microsoft Visual Studio\2017\Enterprise\Common7\IDE<br /> <br /> Yes, each edition now installs into different folders.&nbsp;<br /> <br /> As a work around for those who don't install in the default location, you can set environment variables &nbsp;<strong>MSBuild15Path</strong> (for MSBuild) and&nbsp; <strong>VisualStudio2017Path</strong>&nbsp;for Visual Studio, if we don't find VS/MSBuild in the default locations, we'll check for those environment variables. &nbsp;<br /> <br /> Another issue we found is that when building with devenv.com (ie the visual studio command line, rather than msbuild), builds take a looooong time.. it appears to hang after building, and it also seems to randomly fail with windows error&nbsp;80131623 (FatalExecutionEngineError). This has nothing to do with FinalBuilder or Continua CI, it happens on the command line as well. I have reported these issues to microsoft, hopefully they will resolve them before release. On the MSBuild Action in FinalBuilder, we were not able to get the list of targets for a dotnet core project. This is still being investigated, we do still hope to resolve this eventually.&nbsp;<br /> <br /> Note, since this work was done against a Release Candidate, things may change between now and the VS2017 RTM release (microsoft seem to have redifined what a release candidate is lately!). If you find any issues let us know.<br /> <br /> BTW, TFS 2017 support is currently being worked on for both FinalBuilder and Continua CI. We should have a VSO FinalBuilder build task available in the marketplace soon (it's close). However, getting our xaml builds working with TFS2017 is proving challenging (just like previous releases), there is no doco and it's deprecated (good riddance) and visual studio won't load our projects.. stay tuned.749.NET 4.6.1, WCF and self signed X509 certificateshttps://www.finalbuilder.com/resources/blogs/postid/746/net-461-wcf-and-self-signed-x509-certificates.NET,Continua CISat, 14 May 2016 14:34:50 GMTWe have been working on moving Continua CI to .net 4.6.1 for a future release, and during this conversion (so far, mostly just updating nuget packages),&nbsp; we discovered an issue that turned out to be caused by a change to .net certificate validation. <br /> <br /> If you use self signed X509 certificates and target the .net framework 4.6.1 then you are in some fun, especially if you used makecert to generate the certificate. There is a change in behaviour in the way certificates are validated, which will leave you pulling you hair out for hours. The error you may encounter will look something like this :&nbsp;<br /> <br /> "The Identity check failed for the outgoing message. The remote endpoint did not provide a domain name system (DNS) claim and therefore did not satisfied DNS identity 'localhost'. This may be caused by lack of DNS or CN name in the remote endpoint X.509 certificate's distinguished name."<br /> <br /> If you google the error message, you will find plenty of references to using&nbsp; a DnsEndpointIdentity, only in our case, we were already doing exactly as the answers on stackoverflow were suggesting! Since we were migrating from .net 4.0 to .net 4.6.1, I started looking for info on the changes in each version of the .net framework. Eventually, I came across this page :<br /> <br /> <a class="moz-txt-link-freetext" href="https://msdn.microsoft.com/en-us/library/mt620030%28v=vs.110%29.aspx">https://msdn.microsoft.com/en-us/library/mt620030(v=vs.110).aspx</a><br /> <br /> This was the only mention of X509 certificates I could find in the change history, but it seems like it could be related, so I tried what it suggested, and low and behold, problem solved! With some further investigation of this work around, I found some issueson the wcf github repo with several references to the behaviour of certificate validation.<br /> <br /> <a class="moz-txt-link-freetext" href="https://github.com/dotnet/wcf/issues/321">https://github.com/dotnet/wcf/issues/321</a><br /> <br /> <a class="moz-txt-link-freetext" href="https://github.com/dotnet/wcf/pull/603">https://github.com/dotnet/wcf/pull/603</a><br /> <br /> So it turns out, in .NET 4.6.1 they broke the certificate validation, by only looking at the Subject Alternate Name (SAN) extension, and not falling back to the Subject Name CN field as it should. The pull request I linked to above, is for the WCF for .NET core, not 4.6.1 - so I have no way of knowing if this will be fixed for 4.6.x. &nbsp;<br /> <br /> Whilst an app.config change can work around the issue, the real fix is to generate certificates that include SAN extension.<br /> <br /> <h3>Generating a certificate without MakeCert</h3> <span>Makecert.exe, which is commonly used (on windows at least) does not support the SAN extension, M</span>akecert is deprecated, so it's unlikely there will be an update to make it able to generate certificates with the SAN certificate extension. &nbsp;Windows 8/Server 2012R2 &amp; later versions of Windows include a new powershell cmdlet to generate certificates. For Windows 7 the best option is this :<br /> <br /> <a class="moz-txt-link-freetext" href="https://gallery.technet.microsoft.com/scriptcenter/Self-signed-certificate-5920a7c6">https://gallery.technet.microsoft.com/scriptcenter/Self-signed-certificate-5920a7c6</a><br /> <br /> This appears to what the Windows 8 &amp; later cmdlet is based on, it's relatively simple to use and generates certificates that validate properly with WCF on .NET 4.6.1<br /> <br /> <pre class="brush:powershell; toolbar:true;">New-SelfSignedCertificateEx -Subject "CN=MyServer" -KeySpec Exchange -KeyUsage "DataEncipherment, KeyEncipherment, DigitalSignature" -Path c:\certs\example.pfx -Exportable -SAN "MyServer" -SignatureAlgorithm sha256 -AllowSMIME -Password (ConvertTo-SecureString "abc123dontuseme" -AsPlainText -Force) -NotAfter (get-date).AddYears(20)</pre> <br /> Note the above command is on multiple lines to make it easier to read, it can be on one line. <br />746Modifying XML Manifest files with FinalBuilderhttps://www.finalbuilder.com/resources/blogs/postid/739/modifying-xml-manifest-files-with-finalbuilder.NET,DelphiFinalBuilder,General,XMLMon, 07 Dec 2015 11:37:47 GMTThis topic is something that I pulled from our support system, it's something we get asked about more that once a year, that is, how do I modify the xml manifest file using FinalBuilder. Typically its the assembly version attribute that users want to modify, so that's what I'll show here, but you can use the same technique to edit other parts of the manifest file.&nbsp;<br /> <br /> So lets define our XML Document by adding an <a href="http://wiki.finalbuilder.com/display/FB8/XML+Document+Define+Action" target="_blank" title="XML Document Define Action Documentation">XML Document Define Action</a>, and point it at our manifest file.<br /> <br /> <p style="text-align: center;"> <img src="/blogimages/vincent/manifest/manifest-xml-doc.png" alt="Define XML Document" /> </p> <br /> If you open your manifest file in notpad, you will notice assembly element looks something like this :<br /> <br /> <pre class="brush:xml; toolbar:true;">&lt;assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" &gt; </pre> <br /> Note the xmlns attribute, this is what causes users problems with the xml actions in FinalBuilder, XML Namespaces. The MXSML Parser is very strict when it comes to namespaces, and it requires that we make use of them when using XPath to select nodes.&nbsp;On the XML Document action, switch to the MSXML Parser tab and in the Extra Namespaces grid, add the following.&nbsp;<br /> <br /> <p style="text-align: center;"> <img src="/blogimages/vincent/manifest/manifest-xml-doc2.png" alt="Namespace Prefix" /> </p> <br /> What we are doing here is assigning a prefix (x in this case) to the namespace. This prefix will be used in our XPath statements.<br /> <br /> Add an<a href="http://wiki.finalbuilder.com/display/FB8/Edit+XML+File+Action" target="_blank" title="Edit XML File Action documentation"> Edit XML File action</a> - set the XML File to use an XML Document and select the document we defined with the previous action. Now we need to define the XPath statement to the version attribute that we are going to modify.<br /> <br /> <p style="text-align: center;"> <img src="/blogimages/vincent/manifest/manifest-xml-edit-version.png" alt="Edit XML" /> </p> <br /> And finally, add a Save XML Document Action to save our changes to the file. Note that if you are editing other parts of the manifest file, make sure you add the namespaces and different prefixes, and use this prefixes appropriately in your XPath statements.<br /> <br /> Note, all of this could be done in a single Edit XML File action, however, if you want to make more than one modification to the manifest file then it's more efficient to use the xml document define action to avoid loading/parsing/saving the document for each edit.&nbsp;<br />739TFS/VSO Task for Running FinalBuilder Projecthttps://www.finalbuilder.com/resources/blogs/postid/736/finalbuilder-vso-task.NET,DelphiFinalBuilder,Git,TFSWed, 16 Sep 2015 16:33:00 GMTToday we are announcing the new build step for Team Foundation Build 2015. This task will allow users of TFS on-prem and VSO to run FinalBuilder projects on Team Foundation Build agents. The task itself is open source and can be found on <a href="https://github.com/VSoftTechnologies/FinalBuilder-VSO">GitHub</a>.<br /> <br /> Those who use TFS on-prem will be very familiar with our XAML build activity already. This activity took a great deal of confusion out of the XAML build process. Changing a build progress from a complex workflow into a simple to maintain FinalBuilder project. The time and effort saved is huge, especially considering the "default" XAML workflow looks like this:<br /> <br /> <img alt="" src="https://www.finalbuilder.com/blogImages/jason/FinalBuilder-VSO/OldXAMLProcess.png" style="vertical-align: middle; text-align: center; width: 441px; height: 800px;" /><br /> <br /> Thankfully Microsoft have improved on their build system with the release of Team Foundation Build 2015. You can read more about this at <a href="https://msdn.microsoft.com/Library/vs/alm/Build/feature-overview">Team Foundation Build 2015</a>. In summary, the new build system greatly simplifies the build process into a list of tasks to perform. <br /> <br /> The FinalBuilder task is our custom task for TFS Build 2015. It offers TFS script builders the ability to still have a simplified overview of their build process while still gaining the power of FinalBuilder and all its supported actions. With FinalBuilder TFS build script creators are able to perform a wide number of tasks that would otherwise require breaking out powershell and diving into the TFS agent environment variables. <br /> <br /> When installed, the FinalBuilder Task gives users the following UI. All of the properties present in the UI are easily accessible from within any FinalBuilder script run by the task. FinalBuilder also gives simple access to a list of files that triggered the build.<br /> <br /> <img alt="" src="https://www.finalbuilder.com/blogImages/jason/FinalBuilder-VSO/FinalBuilderTaskOptionsAll.png" style="vertical-align: middle; text-align: center; width: 518px; height: 300px;" /> <br /> <h2>Installation and Usage</h2> The steps to adding custom build activities to your TFS and VSO instances are quick and easy. We have created a <a href="https://github.com/VSoftTechnologies/FinalBuilder-VSO">GitHub Repository</a> for explaining how to install, and use our FinalBuilder VSO task. <h2>Repository Clone</h2> To clone this repository use the following command line. You will require git to be installed and available on your path.<br /> <pre class="brush:shell; gutter:false; highlight:3">> mkdir VSoft > cd VSoft > git clone https://github.com/VSoftTechnologies/FinalBuilder-VSO.git Cloning into 'FinalBuilder-VSO'... remote: Counting objects: X, done. remote: Compressing objects: 100% (X/X), done. remote: Total X (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (X/X), done. Checking connectivity... done. </pre> With the repository cloned we require the TFS Extensions Command Line Utility (tfx-cli). It comes as a Node Package Manager (npm) package. Npm comes with both the node.js and io.js installer. Download the installer for your Windows platform and run it.<br /> <br /> To check that NPM is working correctly you can use the npm version command<br /> <pre class="brush:shell; gutter:false; highlight:1">> npm -v 2.10.1 </pre> Now your able to install the tfx-cli package using npm. Install this globally so that its accessable on the command line. The command line for this is as follows;<br /> <pre class="brush:shell; gutter:false; highlight:1">> npm install -g tfx-cli tfx-cli@0.1.11 C:\Users\<username>\AppData\Roaming\npm\node_modules\tfx-cli ├── os-homedir@1.0.1 ├── async@1.4.2 ├── colors@1.1.2 ├── minimist@1.2.0 ├── node-uuid@1.4.3 ├── q@1.4.1 ├── read@1.0.7 (mute-stream@0.0.5) ├── validator@3.43.0 ├── shelljs@0.5.3 ├── vso-node-api@0.3.4 └── archiver@0.14.4 (buffer-crc32@0.2.5, lazystream@0.1.0, async@0.9.2, readable-stream@1.0.33, tar-stream@1.1.5, glob@4.3.5, lodash@3.2.0, zip-stream@0.5.2) </pre> To test that tfx-cli is working correctly and is on the path use the tfx command.<br /> <pre class="brush:shell; gutter:false; highlight:1">> tfx Copyright Microsoft Corporation tfx <command> [<subcommand(s)> ...] [<args>] [--version] [--help] [--json]                         fTfs                       fSSSSSSSs                     fSSSSSSSSSS      TSSf         fSSSSSSSSSSSS      SSSSSF     fSSSSSSST SSSSS      SSfSSSSSsfSSSSSSSt   SSSSS      SS  tSSSSSSSSSs      SSSSS      SS   fSSSSSSST       SSSSS      SS fSSSSSFSSSSSSf    SSSSS      SSSSSST    FSSSSSSFt SSSSS      SSSSt        FSSSSSSSSSSSS                     FSSSSSSSSSS                        FSSSSSSs                         FSFs    (TM) commands:    build         manage task extensions and builds    help         command help    login         login and cache credentials. types: pat (default), basic         login <collection url> [--authtype <authtype>] [options]    parse         parse json by piping json result from another tfx command         parse <jsonfilter> [options]    version         output the version         version [options] Options:    --help    : get help on a command    --json    : output in json format.  useful for scripting </pre> For tfx-cli to upload a task to TFS it needs to be logged in. We can do this once so that all following commands will use the some credentials. The method used depends on whether your using VSO or an On Prem installation.<br /> <h2>On Premises Login</h2> For on premises TFS basic authentication will need to be enabled. The tfx-cli project has a great guide on how to achieve this Using tfx against Team Foundation Server (TFS) 2015 using Basic Authentication.<br /> <br /> Once TFS has been configured to use basic authentication use the tfx-cli login command to connect to TFS. You will be prompted for the TFS collection URL to connect to, and the username and password for accessing that collection.<br /> <pre class="brush:shell; gutter:false; highlight:1">> tfx login --authType basic Copyright Microsoft Corporation Enter collection url > http://<server>:<port>/tfs/<collection> Enter username > <user>@<domain> Enter password > <password> logged in successfully </pre> With a successful login subsequent commands will not require us to provide the credentials again.<br /> <h2>Visual Studio Online (VSO) Login</h2> For VSO login you need a personal access token setup under your account. There is a great article to configure an access token located at Using Personal Access Tokens to access Visual Studio Online.<br /> <br /> With the personal access token configured use the tfx-cli login command to connect to VSO. You will be prompted for the TFS collection URL to connect to, and access token for accessing that collection.<br /> <pre class="brush:shell; gutter:false; highlight:1">> tfx login Copyright Microsoft Corporation Enter collection url > https://<vsoname>.visualstudio.com/<collection> Enter personal access token > <access token> logged in successfully </pre> With a successful login subsequent commands will not require us to provide the credentials again.<br /> <h2>Uploading Task</h2> Once logged into TFS we are able to upload the FinalBuilder task to the server. Tasks are uploaded to the server, the server will then pass them onto agents requried to run those tasks.<br /> <br /> To upload the task use the tfx-cli tasks upload command. Each command shown below is a sub-command of the previous, so order does matter here. The overwrite option is included so that any previously installed version is overwritten. Note however the highest version number of the task will win when running builds.<br /> <br /> Note: This command is run under the directory in which this repositry was cloned to (i.e. FinalBuilderTFS).<br /> <pre class="brush:shell; gutter:false; highlight:1">> tfx build tasks upload ./FinalBuilder --overwrite Copyright Microsoft Corporation<br /> task at: ./FinalBuilder uploaded successfully! </pre> To test that the FinalBuilder task is now installed on the builds page for teh collection the task was uploaded to. Create a new empty Team Foundation Build definition. After clicking "Add build step" a FinalBuilder task should appear in the "Build" category.<br /> <h2>Further Steps</h2> For more information on the following subjects please follow the links;<br /> <br /> How to configure the build task refer to <a href="https://github.com/VSoftTechnologies/FinalBuilder-VSO/blob/master/docs/TaskUI.md">Task UI</a>.<br /> How to install FinalBuilder on an agent refer to <a href="https://github.com/VSoftTechnologies/FinalBuilder-VSO/blob/master/docs/InstallingFinalBuilder.md">Installing FinalBuilder</a>.<br /> How to create a FinalBuilder VSO agent refer to Creating a <a href="https://github.com/VSoftTechnologies/FinalBuilder-VSO/blob/master/docs/FinalBuilderVSOAgent.md">VSO FinalBuilder Agent</a>.736FinalBuilder 8 Released!https://www.finalbuilder.com/resources/blogs/postid/733/finalbuilder-8-released.NET,Delphi,FinalBuilderThu, 20 Aug 2015 19:02:00 GMT<p>It's very nearly 5 years since FinalBuilder 7 was released. Since it's release we have shipped <a href="/downloads/finalbuilder/finalbuilder-7-version-history">many official updates</a>, nearly every update including new features or improvements. This program of continuous improvement has worked well, with customers not having to wait for major new versions to arrive to get support for new versions of Visual Studio or Delphi etc, but it has limited our ability to make major changes. So it's time for a new major version of FinalBuilder.</p> <h2>What's new in FinalBuilder 8</h2> <h3>IDE Themes</h3> <p>The IDE has two new themes, Dark and Light (yes, imaginatively named!). The IDE defaults to Dark on first run, however you can change the theme in the options quite easily.</p> <table style="border: none; width: 100%;"> <tbody> <tr> <td style="width: 50%;"><img alt="IDE Light theme" height="276" src="/blogImages/vincent/fb8-beta/fb8-ide-light-small.png" width="400" /></td> <td style="width: 50%;"><img alt="IDE Light theme" height="276" src="/blogImages/vincent/fb8-beta/fb8-ide-dark-small.png" width="400" /></td> </tr> </tbody> </table> <p> </p> <h3>Debugger</h3> <p>One of the most asked for features now available in FinalBuilder 8, <strong>stepping into included projects</strong>. In FinalBuilder 7 and earlier, you could only step over included projects, and wait for them to return. In FinalBuilder 8, you can step into the included project, if it is not already opened the IDE will open the project and switch to it automatically. To make this possible, there are now "Step Into" and "Step Over" functions. The Step into/over now also applies to targets (see below).<br /> <br /> Debugger breakpoints now have conditions :</p> <p style="text-align: center;"><img alt="IDE Light theme" height="276" src="/blogImages/vincent/fb8-beta/fb8-breakpoint-props.png" style="text-align: center;" width="400" /></p> <h3>Actionlists renamed to Targets</h3> <p>ActionLists have been renamed to Targets. Targets can now also define dependencies, so you can for example define Clean, Build, Test, and have Test depend on Build. If you execute the Test target, and Build has not already been executed, it will be executed first before Test. Targets can be specified on the command line.</p> <p style="text-align: center;"><img alt="IDE Light theme" height="276" src="/blogImages/vincent/fb8-beta/fb8-target-depend.png" style="text-align: center;" width="400" /></p> <p> </p> <p>In FinalBuilder 7 and earlier, projects had a Main and an OnFailure (global error handler) actionlist. In FinalBuilder 8, projects just have a Default Target. Older projects will be imported such that the Main and OnFailure Targets are called from the Default Target inside a try/catch block.</p> <p> </p> <h3>Run Target Action</h3> <p>You can now return values from Targets (ie out parameters) .</p> <p style="text-align: center;"><img alt="IDE Light theme" height="276" src="/blogImages/vincent/fb8-beta/fb8-target-outparams.png" style="text-align: center;" width="400" /></p> <h3>New Help System</h3> <p>The help has moved online in the form of a wiki. This enables us to do inline help updates without needing to ship new builds. The new help is still being worked on, lots of screenshots are missing etc.. </p> <h2>Non Visible Changes</h2> <h3>Stepping Engine</h3> <p>The stepping engine was rewritten to enable stepping into included projects, and to enable target dependencies. This, work, together with the new variables architecture is where the bulk of effort/time was spent in the FinalBuilder 8 development cycle.</p> <h3>Variables Architecture</h3> <p>The variables architecture and the expression evaluator were rewritten to resolve several corner case issues that we were not able to resolve in FinalBuilder 7. The expression evaulator has a new parser that will allow us to more easily extend the syntax in the future. The User variable namespace was removed, it caused too many problems with projects not running under other users, not running on the build server etc. Use Project variables instead.</p> <h3>Core Messaging</h3> <p>Changes to the messaging has allowed us to improve the performance of the stepping engine and logging, with much less thread switching. This also improved the IDE performance.</p> <h3>CLR Hosting</h3> <p>The minimum CLR version is now .NET 4.0 (ie FinalBuilder requires .net 4.0 to be installed). FinalBuilder 8 also requires Powershell 3.0 or later.</p> <h3>Code Changes</h3> <p>In addition to the architectural changes, we also spent a lot of time refactoring the code, running static analysis tools over the source, looking for memory leaks, potential bugs etc. One of the results of this is reduced memory usage during a build compared to FB7. The FB8 IDE does use slightly more memory than the FB7 IDE at startup (mostly due to the heavy use of delphi generics), however the runtime memory usage is much lower.A large  part of the refactoring involved unit testing (we created a new <a href="https://github.com/VSoftTechnologies/DUnitX" target="_blank">unit test framework</a> to suite our needs!) and creating a suite of integration tests. </p> <h3>FBCmd</h3> <p>The command line parameters have changed to be more consistent and easier to specify. You can also specify one or more targets to execute (when not specified, the default target is executed).</p> <h3>New Project File Formats</h3> <p>FinalBuilder has used an xml file format since version 1, however a common complaint over the years, has been that it is difficult to diff file versions. FinalBuilder 8 has tackled this in two ways.</p> <p>A new DSL style project file format (.fbp8) is now the default format, it is very easy to diff.</p> <pre class="brush:delphi; toolbar:true;"> project begin projectid = {04710B72-066E-46E7-84C7-C04A0D8BFE18} target begin name = Default targetid = {E6DE94D6-5484-45E9-965A-DB69885AA5E2} rootaction begin action.group begin id = {D860420B-DE46-4806-959F-8A92A0C86429} end end end end </pre> <p>A new xml format (.fbx8), much less verbose than the old format.<span style="white-space: pre-wrap;"> </span></p> <pre class="brush:xml; toolbar:true;"> <?xml version="1.0" encoding="UTF-8"?> <finalbuilder> <project> <projectid>{6A717C24-D00F-4983-9FD0-148B2C609634}</projectid> <target> <name>Default</name> <targetid>{E6DE94D6-5484-45E9-965A-DB69885AA5E2}</targetid> <rootaction> <action.group> <id>{D860420B-DE46-4806-959F-8A92A0C86429}</id> </action.group> </rootaction> </target> </project> </finalbuilder> </pre> <p>Compressed project files (.fbz8) use the dsl format internally (compressed projects are just a zip file with a project.fbp8 inside it).</p> <p>The default project file encoding is now UTF-8, which is more version control friendly (some version control systems treat utf-16 as binaries).</p> <h3>New Actions</h3> <p>FinalBuilder 8 includes new actions for Chocolatey, Bower, NPM, Gulp, Grunt, Rake, Fake, Mocha, along with Redgate SQL Compare and SQL Data Compare actions.</p> <p>TFS 2015 XAML builds are also supported, a VSO task will be available soon (will be published on github).</p> <h3>License Key installation</h3> <p>We implemented a new more reliable trial mechanism for FinalBuilder 8, and made it simpler to install license keys. You can log into your account on our website directly in the FinalBuilder IDE and download & install license keys</p> <p>The trial mechanism also uses license keys, which is more reliable than the mechansim used in earlier versions.</p> <h3>Where's my license key?</h3> <p>If you had an active Software Assurance Subscription for FinalBuilder 7 as of 20th August 2015, FinalBuilder 8 license keys were generated and added to your account today. You should have received an email notification.</p> <h3>How do I purchase an upgrade?</h3> <p>If you had a subscription for FinalBuilder 7, and it expired, you can upgrade by <a href="/store/section/customers?page=subscriptions">Renewing your subscription</a>.</p> <p>If you have a license for FinalBuilder 6 or earlier, you can <a href="/store/section/customers?page=upgrades">Purchase an upgrade here.</a></p> <h3>Can I safely install FinalBuilder 8 on a machine with FinalBuilder x?</h3> <p>Yes. FinalBuilder 8 installs into a separate folder (as did all older versions of FinalBuilder).</p> <h3>Can FinalBuilder 8 open an run my old projects?</h3> <p>Yes, FinalBuilder 8 can open and run any projects from any earlier version of FinalBuilder. When you save the projects in FinalBuilder 8, it will save it as a FinalBuilder 8 project (new file).</p> <h3>Can older versions of FinalBuilder open FinalBuilder 8 projects?</h3> <p>No, FinalBuilder 8 projects use a different file format.</p> <h3>Does FinalBuilder 8 work with FinalBuilder Server 7?</h3> <p>No. FinalBuilder 8 does not work with FB Server 7, nor can it be made to work. FinalBuilder Server was discontinued over 2 years ago, if you need Continuous Integration then consider migrating to <a href="/continua-ci">Continua CI.</a></p> <h3>I have questions!</h3> <p>Feel free to contact support@finalbuilder.com with any questions you might have.</p> 733Adding NTLM SSO to Nancyfxhttps://www.finalbuilder.com/resources/blogs/postid/730/adding-ntlm-sso-to-nancyfx.NET,Nancyfx,Open Source,Web DevelopmentMon, 18 May 2015 11:52:21 GMT<a href="https://github.com/NancyFx/Nancy" target="_blank" title="Nancyfx on Github.">Nancyfx</a> is a Lightweight, low-ceremony, framework for building HTTP based services on .Net and Mono. It's open source and available on github.&nbsp;<br /> <br /> <p>Nancy supports Forms Authentication, Basic Authentication and Stateless Authentication "out of the box", and it's simple to configure. In my application, I wanted to be able to handle mixed Forms and NTLM Authentication, which is something nancyfx &nbsp;doesn't support. We have done this before with asp.net on IIS, and it was not a simple task, involving a child site with windows authentication enabled while the main site had forms (IIS doesn't allow both at the same time) and all sorts of redirection. It was painful to develop, and it's painful to install and maintain.&nbsp;<br /> <br /> Fortunately with Nancy and <a href="http://owin.org/" target="_blank" title="Owin Website">Owin</a>, it's a lot simpler. Using Microsoft's implementation of the Owin spec, and Nancy's Owin support, it's actually quite easy, without the need for child websites and redirection etc.&nbsp;</p> <p>I'm not going to explain how to use Nancy or Owin here, just the part needed to hook up NTLM support. In my application, NTLM authentication is invoked by a button on the login page ("Login using my windows account") which causes a specific login url to be hit. We're using Owin for hosting rather than IIS and Owin enables us to get access to the HttpListener, so we can control the authentication scheme for each url. We do this by adding an AuthenticationSchemeSelectorDelegate.</p> <pre class="brush:c#; toolbar:true;">internal class Startup { public void Configuration(IAppBuilder app) { var listener = (HttpListener)app.Properties["System.Net.HttpListener"]; //add a delegate to select the auth scheme based on the url listener.AuthenticationSchemeSelectorDelegate = request =&gt; { //the caller requests we try windows auth by hitting a specific url return request.RawUrl.Contains("loginwindows") ? AuthenticationSchemes.IntegratedWindowsAuthentication : AuthenticationSchemes.Anonymous; } app.UseNancy(); } } </pre> <br /> What this achieves is to invoke the NTLM negotiation if the "loginwindows" url is hit on our nancy application. If the negotiation is successful (ie the browser supports NTLM and is able to identify the user), &nbsp;then the Owin environment will have the details of the user, and this is how we get those details out of Owin (in our bootstrapper class).<br /> <br /> <pre class="brush:c#; toolbar:true;">protected override void ApplicationStartup(TinyIoCContainer container, IPipelines pipelines) { pipelines.BeforeRequest.AddItemToStartOfPipeline((ctx) =&gt; { if (ctx.Request.Path.Contains("loginwindows")) { var env = ((IDictionary&lt;string,&gt;)ctx.Items[Nancy.Owin.NancyOwinHost.RequestEnvironmentKey]); var user = (IPrincipal)env["server.User"]; if (user != null &amp;&amp; user.Identity.IsAuthenticated) { //remove the cookie if someone tried sending one in a request! if (ctx.Request.Cookies.ContainsKey("IntegratedWindowsAuthentication")) ctx.Request.Cookies.Remove("IntegratedWindowsAuthentication"); //Add the user as a cooking on the request object, so that Nancy can see it. ctx.Request.Cookies.Add("IntegratedWindowsAuthentication", user.Identity.Name); } } return null;//ensures normal processing continues. }); }</pre> <br /> Note we are adding the user in a cookie on the nancy Request object, which might seem a strange thing to do, but it was the only way I could find to add something to the request that can be accessed inside a nancy module, because everything else on the request object is read only. We don't send this cookie back to the user. So with that done, all that remains is the use that user in our login module<br /> <br /> <pre class="brush:c#; toolbar:true;"> Post["/loginwindows"] = parameters =&gt; { string domainUser = ""; if (this.Request.Cookies.TryGetValue("IntegratedWindowsAuthentication",out domainUser)) { //Now we can check if the user is allowed access to the application and if so, add //our forms auth cookie to the response. ... } } </pre> <br /> Of course, this will probably only work on Windows, not sure what the current status is for System.Net.HttpListener is on Mono. This code was tested with Nancyfx 1.2 from nuget.&nbsp;<br />730FinalBuilder 8 Betahttps://www.finalbuilder.com/resources/blogs/postid/729/finalbuilder-8-beta.NET,Delphi,FinalBuilder,GeneralTue, 05 May 2015 20:06:36 GMT<p>It's almost 5 years since FinalBuilder 7 was released. Since it's release we have shipped <a href="/downloads/finalbuilder/finalbuilder-7-version-history">44 official updates</a>, nearly every update including new features or improvements. This program of continuous improvement has worked well, with customers not having to wait for major new versions to arrive to get support for new versions of Visual Studio or Delphi etc, but it has limited our ability to make major changes. So it's time for a new major version of FinalBuilder. </p> <h2>What's new in FinalBuilder 8</h2> <h3>IDE Themes</h3> <p>The IDE has two new themes, Dark and Light (yes, imaginatively named!). The IDE defaults to Dark on first run, however you can change the theme in the options quite easily. The themes are still a work in progress, we are waiting on an update from a third party control vendor to resolve some issues.</p> <table style="border: none; width: 100%;"> <tbody> <tr> <td style="width: 50%;"><img alt="IDE Light theme" height="276" src="/blogImages/vincent/fb8-beta/fb8-ide-light-small.png" width="400" /></td> <td style="width: 50%;"><img alt="IDE Light theme" height="276" src="/blogImages/vincent/fb8-beta/fb8-ide-dark-small.png" width="400" /></td> </tr> </tbody> </table> <p> </p> <h3>Debugger</h3> <p>One of the most asked for features now available in FinalBuilder 8, <strong>stepping into included projects</strong>. In FinalBuilder 7 and earlier, you could only step over included projects, and wait for them to return. In FinalBuilder 8, you can step into the included project, if it is not already opened the IDE will open the project and switch to it automatically. To make this possible, there are now "Step Into" and "Step Over" functions. The Step into/over now also applies to targets (see below).<br /> <br /> Debugger breakpoints now have conditions :</p> <p style="text-align: center;"><img alt="IDE Light theme" height="276" src="/blogImages/vincent/fb8-beta/fb8-breakpoint-props.png" style="text-align: center;" width="400" /></p> <h3>Actionlists renamed to Targets</h3> <p>ActionLists have been renamed to Targets. Targets can now also define dependencies, so you can for example define Clean, Build, Test, and have Test depend on Build. If you execute the Test target, and Build has not already been executed, it will be executed first before Test. Targets can be specified on the command line.</p> <p style="text-align: center;"><img alt="IDE Light theme" height="276" src="/blogImages/vincent/fb8-beta/fb8-target-depend.png" style="text-align: center;" width="400" /></p> <p> </p> <p>In FinalBuilder 7 and earlier, projects had a Main and an OnFailure (global error handler) actionlist. In FinalBuilder 8, projects just have a Default Target. Older projects will be imported such that the Main and OnFailure Targets are called from the Default Target inside a try/catch block.</p> <p> </p> <h3>Run Target Action</h3> <p>You can now return values from Targets (ie out parameters) .</p> <p style="text-align: center;"><img alt="IDE Light theme" height="276" src="/blogImages/vincent/fb8-beta/fb8-target-outparams.png" style="text-align: center;" width="400" /></p> <h3>New Help System</h3> <p>The help has moved online in the form of a wiki. This enables us to do inline help updates without needing to ship new builds. The new help is still being worked on, lots of screenshots are missing etc.. </p> <h2>Non Visible Changes</h2> <h3>Stepping Engine</h3> <p>The stepping engine was rewritten to enable stepping into included projects, and to enable target dependencies. This, work, together with the new variables architecture is where the bulk of effort/time was spent in the FinalBuilder 8 development cycle.</p> <h3>Variables Architecture</h3> <p>The variables architecture and the expression evaluator were rewritten to resolve several corner case issues that we were not able to resolve in FinalBuilder 7. The expression evaulator has a new parser that will allow us to more easily extend the syntax in the future. The User variable namespace was removed, it caused too many problems with projects not running under other users, not running on the build server etc. Use Project variables instead.</p> <h3>Core Messaging</h3> <p>Changes to the messaging has allowed us to improve the performance of the stepping engine and logging, with much less thread switching. This also improved the IDE performance.</p> <h3>CLR Hosting</h3> <p>The minimum CLR version is now .NET 4.0 (ie FinalBuilder requires .net 4.0 to be installed).</p> <h3>Code Changes</h3> <p>In addition to the architectural changes, we also spent a lot of time refactoring the code, running static analysis tools over the source, looking for memory leaks, potential bugs etc. One of the results of this is reduced memory usage during a build compared to FB7. The FB8 IDE does use slightly more memory than the FB7 IDE at startup (mostly due to the heavy use of delphi generics), however the runtime memory usage is much lower.A large  part of the refactoring involved unit testing (we created a new <a href="https://github.com/VSoftTechnologies/DUnitX" target="_blank">unit test framework</a> to suite our needs!) and creating a suite of integration tests. </p> <h3>FBCmd</h3> <p>The command line parameters have changed to be more consistent and easier to specify. You can also specify one or more targets to execute (when not specified, the default target is executed).</p> <h3>New Project File Formats</h3> <p>FinalBuilder has used an xml file format since version 1, however a common complaint over the years, has been that it is difficult to diff file versions. FinalBuilder 8 has tackled this in two ways.</p> <p>A new DSL style project file format (.fbp8) is now the default format, it is very easy to diff.</p> <pre class="brush:delphi; toolbar:true;"> project begin projectid = {04710B72-066E-46E7-84C7-C04A0D8BFE18} target begin name = Default targetid = {E6DE94D6-5484-45E9-965A-DB69885AA5E2} rootaction begin action.group begin id = {D860420B-DE46-4806-959F-8A92A0C86429} end end end end </pre> <p>A new xml format (.fbx8), much less verbose than the old format.<span style="white-space: pre-wrap;"> </span></p> <pre class="brush:xml; toolbar:true;"> <!--?xml version="1.0" encoding="UTF-8"?--> <finalbuilder> <project> <projectid>{6A717C24-D00F-4983-9FD0-148B2C609634}</projectid> <target> <name>Default</name> <targetid>{E6DE94D6-5484-45E9-965A-DB69885AA5E2}</targetid> <rootaction> <action.group> <id>{D860420B-DE46-4806-959F-8A92A0C86429}</id> </action.group> </rootaction> </target> </project> </finalbuilder> </pre> <p>Compressed project files (.fbz8) use the dsl format internally (compressed projects are just a zip file with a project.fbp8 inside it).</p> <p>The default project file encoding is now UTF-8, which is more version control friendly (some version control systems treat utf-16 as binaries).</p> <h3>New Actions</h3> <p>There are no new actions at the moment, although several are in development, they will be added to the beta builds as they are completed. </p> <h3>How do I get the Beta?</h3> <p>Links to the beta downloads will be published to the <a href="https://www.finalbuilder.com/downloads/finalbuilder">FinalBuilder Downloads</a> page. <br />  </p> <h3>What if I find a bug?</h3> <p>We have created a Beta forum on our forums, or you can email support (please added Beta to the subject). When reporting an issue, be sure to include the beta build number and details about your environment. Please test with the latest beta build before reporting bugs. <br /> <br /> We are particularly keen for people to load up their existing projects from older (ie 7 or earlier) versions of FinalBuilder, save them in FB8 format, and load them again and confirm that everything loaded ok. <br />  </p> <h3>When will it be released?</h3> <h3> </h3> <p>When it's ready ;)</p> 729Continua 1.5 releasedhttps://www.finalbuilder.com/resources/blogs/postid/721/continua-15-released.NET,Continua CI,GeneralTue, 09 Sep 2014 11:13:57 GMT<br /> <br /> <h2>Continua Version 1.5 is now <a target="_blank" href="https://www.finalbuilder.com/downloads/continuaci">available for download</a></h2> <p>Today marks a milestone in Continua CI as we release version 1.5 of the product. Its been many months in the making, we hope you enjoy the update as much as we enjoyed making it.</p> <p>There are many features that we think you'll benefit from by updating to v1.5, some of these include: </p> <h3>Reworked UI:</h3> <ul> <li>Now using bootstrap framework for styling</li> <li>Redesigned <a target="_blank" href="http://wiki.finalbuilder.com/display/continua/dashboards">dashboards</a> that show more information including graphs.</li> <li>Added stages information to the Project tile and list views</li> <li>Disabled configurations are now displayed as faded</li> </ul> <br /> <h3>Cloning:</h3> <ul> <li>Can now clone whole projects and clone configurations between projects.</li> </ul> <br /> <h3>Stage Conditions:</h3> <ul> <li>Auto Promote conditions - stages can now use conditions to control whether to auto-promote to the next stage.</li> <li>Skip conditions - you can now provide conditions for skipping stages or disable a stage completely.</li> </ul> <br /> <h3>New Actions:</h3> <ul> <li>Update GitHub Status Action is now deprecated (use event handler instead - see below).</li> <li><a target="_blank" href="http://wiki.finalbuilder.com/display/continua/NuGet+Restore+Action">NuGet restore action</a>.</li> <li><a target="_blank" href="http://wiki.finalbuilder.com/display/continua/Fake+Action">Fake (F#) build runner.</a></li> </ul> <br /> <h3>Repository Tags: (Git, Mercurial and Subversion repositories only)</h3> <ul> <li>Continua CI can now detect and list repository tags.</li> <li>Tags are now displayed in changeset tabs on configuration and build views.</li> <li>Repository trigger can now be set to trigger on tag changes (new tags, edits and deletions) changes).</li> <li>You can now run a build on a <a target="_blank" href="http://wiki.finalbuilder.com/display/continua/Builds#Builds-RepositoryBranch/Tag">tagged changeset</a>.</li> </ul> <br /> <h3><a target="_blank" href="http://wiki.finalbuilder.com/display/continua/Build+Event+Handlers">Build Event Handlers:</a></h3> <ul> <li> Octopus Deploy: Create/Deploy/Promote Octopus Deploy releases. </li> <li> Tag Repository Changesets: Apply tags to a repository changeset (Git, Mercurial and Subversion repositories only) </li> <li> <a target="_blank" href="http://wiki.finalbuilder.com/display/continua/Update+GitHub+Status">Update GitHub Status: replaces the Update GitHub Status action</a>.</li> </ul> <br /> <h3>and many more changes including:</h3> <ul> <li> Styling changes for improved handling on small screen sizes</li> <li> Report ordering: you can choose which one is displayed first on the build view.</li> <li> New expression functions: Utils.NewGuid() and Utils.RandomNumber() can be used for generation of temporary paths for example</li> <li> Additional LatestChangeset object within the repository object with Branch, BranchName, Comment, CommitterUserName, CommitterFullName, Created, FileCount, Id and RepositoryUsername properties to use in expressions</li> <li> Continua now supports DUnitX enhanced Command Line Options</li> </ul> <h2>Updating</h2> <p>Updating to this new release is the same regardless if you are using v1.0.X or a recent build from the beta or release candidate. Simply download the installer and run it, the setup will guide you through the install process. As usual we are available on <a href="mailto:support@finalbuilder.com">support@finalbuilder.com</a> if you run into any troubles.</p> <p>For this release you will need to update both the server and agents.</p> <h2>A word of thanks</h2> <p>The team wishes to thank everyone who has participated in the beta and release candidate stages for this release. Your positive feedback has been invaluable in shaping the features and functionality of the product. Thank you for your continued support.</p>721Deployment with Continua CI 1.5 and Octopus Deployhttps://www.finalbuilder.com/resources/blogs/postid/712/deployment-with-continua-ci-and-octopus-deploy.NET,Continua CIWed, 02 Jul 2014 16:12:00 GMT<p>So you've got your Continua CI server set up to automatically build, run unit tests and produce reports for your awesome new web application. Now you're ready to try out your project in its natural environment and then eventually release it to the wild for well-deserved public applause.<br /> <br /> Up until now, your options were either to use a Copy action to push the files up to test server and a PowerShell action to set up web services, or preferably run a FinalBuilder script utilising the plethora of actions available for transferring files and interacting with web servers.<br /> <br /> As of version 1.5, Continua CI can also work together with <a href="https://octopusdeploy.com">Octopus Deploy</a> server to provide an end-to-end continuous delivery mechanism. Using the new build event handlers feature, Continua CI builds can now be set up to create Octopus Deploy releases and initiate deployment to test and production environments, at key points in the build process.<br /> <br /> This post will walk through the steps required to push a .Net web application built in Continua to Octopus Deploy and trigger a deployment process to effortlessly get your application running on your test and production servers.<br />  </p> <h3>Preparing your solution</h3> <p><br /> Octopus Deploy requires that you provide your applications as <a href="https://www.nuget.org">NuGet packages</a>. You can create and push the package to the Octopus Deploy server using Nuget Pack and Push actions, or create and push an <a href="http://docs.octopusdeploy.com/display/OD/Using+OctoPack">OctoPack</a> from MSBuild or VisualStudio build runner actions.<br /> <br /> Lets go with the recommended OctoPack option. First prepare your Visual Studio solution - use the NuGet package manager to install the OctoPack package into the projects you want to deploy. This will include web application projects, console application projects and Windows service projects but not class libraries and unit test projects.<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/octopack.png" /><br /> <br /> You can now optionally add a <a href="http://docs.nuget.org/docs/reference/nuspec-reference">.nuspec file</a> to the root folder of your project to describe the contents of your package. If you don't provide a .nuspec file, OctoPack will automatically create one based on your project settings.<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/nuspec.png" /></p> <p> </p> <p> </p> <h3>Setting up the deployment process</h3> <p><br /> Next head over to your Octopus server and set up a deployment project. This should include a “Deploy a NuGet package” process step as below.<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/DeploymentStep.png" /><br /> <br /> We will set this to retrieve the application package from the built-in NuGet feed. Note that the NuGet package id should match the id element in your .nuspec file - this will default to the name of your assembly.<br /> <br /> We added a few more steps:<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/DeploymentProcess.png" /><br /> <br /> And some variables:<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/DeploymentVariables.png" /></p> <p> </p> <p> </p> <p> </p> <p> </p> <h3>Setting up the build process</h3> <p><br /> You can now get back to Continua and set up a configuration for building your project. Once you have entered the configuration details and linked up the repository containing your project, move on over to the Stages page:<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/BuildStage.png" /><br /> <br /> For this simple example you'll need two actions: a NuGet Restore action to ensure that the OctoPack package is available for the build and an MSBuild action to build and push the application to your Octopus Deploy server.<br /> Just enter the path to your solution for the NuGet Restore action (the other fields can be left as is) and complete the main tab of the MSBuild action as required for your project.<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/MSBuildAction.png" /><br /> <br /> You then need to enter some additional properties to tell MSBuild to run OctoPack and tell it where to send your package.<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/MSBuildProperties.png" /><br /> <br /> Set the <em>RunOctoPack </em>property to true and the <em>OctoPackPublishPackageToHttp </em>property to the URL for the NuGet feed on the Octopus Deploy server e.g. http://octopusserver/nuget/packages<br /> <br /> You will also need to provide an <em>OctoPackPublishAPIKey </em>property – you can generate an API key on your profile page on the Octopus Deploy server.<br /> <br /> <span>Optionally, y</span>ou can  use the <em>OctoPackPackageVersion </em>to specify up the package version. Here we use Continua expressions to set this based on the build version. If you leave this out then OctoPack will get this value from the <em>AssemblyVersion </em>property in your AssemblyInfo.cs file.<br /> <br /> Once the actions are set up and saved, run a build and check that your package gets uploaded to the Octopus Deploy server. Then create a release for your deployment project and test that it deploys ok. Now we are ready to look into how to run this process automatically from Continua CI.</p> <p> </p> <p> </p> <p> </p> <p> </p> <h3>Build event handler</h3> <p><br /> On the Continua CI configuration wizard after Stages, we have a new area titled Events. Here you can add <a href="http://wiki.finalbuilder.com/x/BgB4">Build Event Handlers</a> for tagging repository changesets, updating the GitHub status and interacting with Octopus Deploy.<br /> <br /> Create a new build event handler, give it a name and select the Octopus Deploy as the Type.<br /> <br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/NewEventHandler.png" /><br /> <br /> You can now provide general project details under the Octopus Deploy tab.<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/OctopusDeployDetails.png" /><br /> <br /> The Octopus Deploy URL should end with '/api' e.g. http://octopusserver/api. Enter the API key generated under your Octopus Deploy profile and the name of your deployment project.<br />   <br /> You can then choose one or more actions to run. The available options are <strong>Create</strong>, <strong>Deploy</strong> and <strong>Promote</strong> and are used to create a new deployment release, deploy a release to an environment and promote a release from one environment to another. As you select each action, new tabs open so you can provide further details and hook the action to a build event.</p> <p> </p> <p> </p> <p> </p> <p> </p> <h3>Creating a release</h3> <p><br /> Before you can deploy an application you need to create a Octopus Deploy release<br /> <br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/CreateRelease.png" /><br /> <br /> When creating a release you can specify the Release Version or leave this blank to automatically create a number based on the highest package version. You must provide either a Default Package Version or Step Package Versions for each step which requires one e.g.<br /> <br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/StepPackageVersions.png" /><br /> <br /> Flip over to the Create Options tab to tell Continua when to create the release.<br /> <br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/CreateOptions.png" /><br /> <br /> There are six <a href="http://wiki.finalbuilder.com/x/GQB4">Build Events</a> available to choose from. Some allow you to select a Stage and some allow you to select a successful or failed Build Status</p> <p> </p> <p> </p> <p> </p> <p> </p> <ul> <li>On Before Stage Start</li> <li>On Sending Stage To Agent</li> <li>On Stage Completed</li> <li>On Build Pending Promotion</li> <li>On After Build Continued</li> <li>On Build Completed</li> </ul> <p><br /> Generally we want to create the release at the start of the build before the first stage starts.</p> <p> </p> <p> </p> <p> </p> <p> </p> <h3>Deploying to an environment</h3> <p><br /> Now on to the crux of this whole process - deploying your application. We generally deploy to a Test environment first and then, once we are happy with the outcome, promote to a User Acceptance environment or directly to Production. Continua CI allows you to deploy a release previously created by a Create action in the same build event handler, the highest release version in the project or a specific release version. It's up to you to ensure that the release version exists before the deploy action is run. An environment can consist of multiple machines - you can specify which machines you want to deploy to. If no machines are specified then the release will be deployed to all machines in the environment.<br /> <br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/DeployRelease.png" /><br /> <br /> <br /> When selecting the Build Event for deployment, ensure that it is triggerred after the package has been built and pushed to the Octopus Deploy server. Here we have set this to be run once the Build stage has completed successfully.<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/DeployOptions.png" /></p> <p> </p> <p> </p> <p> </p> <p> </p> <h3>Promoting a release</h3> <p><br /> You can promote the latest release from one environment to another. Ideally this would be linked to the promotion of a stage e.g. a testing stage, so that the application can be promoted from a test environment to production environment.<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/PromoteRelease.png" /><br /> <br /> We have set our test stage to require manual promotion;<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/StagePromoteOptions.png" /><br /> <br /> <br /> and set our promote action to run when a build is continued after waiting for promotion.<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/PromoteOptions.png" /></p> <p> </p> <p> </p> <p> </p> <p> </p> <h3> </h3> <p> </p> <p> </p> <h3>Variables</h3> <p><br /> You can also pass variables from Continua CI to your deployment, these will be sent to the Octopus Deploy server before each action is run, updating the variables for the deployment project. We have used expressions is this example to send the build versions number and branch name. These variables can then be used to update project files with details for display or configure services differently depending on the source of the project.<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/Variables.png" /></p> <p> </p> <p> </p> <h3>Running the configuration</h3> <p><br /> Once your build event handler dialog has been completed and saved, its time to start running the configuration. As the build processes Continua CI will display status information mirroring the process running on Octopus Deploy.<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/Status.png" /><br /> <br /> You can also see full details of the deployment process in the build log.<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/BuildLog.png" /><br /> <br /> And all going well you will now see a successful deployment on your Octopus Deploy server!<br /> <br /> <img alt="" src="/portals/0/articleimages/blogimages/dave/Success.png" /></p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> 712Automated UI Testing with ContinuaCI and Seleniumhttps://www.finalbuilder.com/resources/blogs/postid/709/automated-ui-testing-done-right-with-continuaci.NET,Continua CI,GeneralOpen SourceTue, 20 May 2014 11:46:00 GMT<p>You have just completed an awesomely complex change to your shinny new webapp! After running all your unit tests things are in the green and looking clean.</p> <p>Very satisfied at the quality of your work you fire up the application to verify that everything is still working as advertised. Below is what greets you on the root path of your app</p> <p><img alt="Funny error" src="/blogimages/peter/404-notfound-ie5.gif" /></p> <p>We have all been here at some time or another! What happened! Perhaps it was not your code that broke it! Maybe the issue originated from another part of your organisation, or maybe it came from somewhere on the "inter-webs".</p> <p>Its time to look at the underlying problem however ..... testing web user interfaces is hard! Its time consuming and difficult to get right. Manual clicks, much typing, cross referencing client specifications etc, surely there must be an easier way. At the end of the day we DO need to test our user interfaces!></p> <h2>Automated Web UI Testing</h2> <p>Thankfully UI testing today can be Automated, running real browsers in real end to end functional tests, to ensure our results meet (and continue to meet) expectations.</p> <p>For the sake of brevity and clarity in this demonstration we will focus on testing an existing endpoint. It is considered common place to find functional tests included as part of a wider build pipeline, which may consist of such steps as:</p> <ul> <li>Build</li> <li>Unit Test</li> <li>Deploy to Test Environment</li> <li>Perform Functional Tests</li> <li>Deploy to Production</li> </ul> <p> </p> <p>In this article we will be focusing on the functional testing component of this pipeline. We will proceed on the assumption that your code has already been, built unit tested and deployed to a Functional Test environment. Today we will :</p> <ul> <li>Add Automated UI testing to an existing endpoint google.com</li> <li>Configure ContinuaCI to automatically build our project, and perform the tests</li> </ul> <p> </p> <h3>Software Requirements:</h3> <p> </p> <ul> <li>Visual Studio 2010 Express Edition SP1 or greater (<a href="http://visualstudio.com/">visualstudio.com</a>)</li> <li>Microsoft Dot Net Framework version 4 or greater</li> <li>Java JRE (<a href="http://www.oracle.com/technetwork/java/javase/downloads/index.html">http://www.oracle.com/technetwork/java/javase/downloads/index.html</a>)</li> <li>Mercurial (<a href="https://mercurial-scm.org">https://mercurial-scm.org</a>)</li> <li>Mozilla Firefox (<a href="http://getfirefox.com/">getfirefox.com</a>)</li> <li>Nuget (<a href="http://docs.nuget.org/docs/start-here/installing-nuget">docs.nuget.org/docs/start-here/installing-nuget</a>)</li> </ul> <p> </p> <h3>Step1: Prepare a Selenium endpoint</h3> <p>Firstly we will prepare for our UI tests by setting up a Selenium server. <span><a href="http://docs.seleniumhq.org/">Selenium</a> is a browser automation framework which will be used to 'remote control' a real browser. </span>This machine will be designated for performing the UI tests against, preferably this will be a machine separate from your ContinuaCI server.<br /> <br /> Log into the machine you have chosen for the Selenium server with administrator privileges<br /> Download and install Mozilla Firefox (getfirefox.com), this will be the browser that we target as part of this example, however Selenium can target lots of other browsers. For a full breakdown please <a href="http://docs.seleniumhq.org/about/platforms.jsp"> see the docs page</a>: .<br /> Download Selenium Server (<a href="http://docs.seleniumhq.org/download">docs.seleniumhq.org/download</a>), at the time of writing the latest version is 2.41.0.<br /> <br /> Place it into a permanent location of you choosing, in our example ("C:\Program Files (x86)\SeleniumServer")<br /> Download NSSM (<a href="http://nssm.cc/download">nssm.cc/download</a>), unzip it and place into a permanent location of you choosing "C:\Program Files (x86)\nssm-2.22\"<br /> <br /> Ensure that port 4444 is set to allow traffic (this is the default communicationsport for Selenium)<br /> <br /> Open a console and run the following commands:<br /> <span style="font-family: 'Courier New';">"C:\Program Files (x86)\nssm-2.22\win64\nssm.exe" install Selenium-Server "java" "-jar \"C:\Program Files (x86)\SeleniumServer\selenium-server-standalone-2.41.0.jar\""<br /> net start Selenium-Server</span><br /> <br /> <img alt="name project" src="/blogimages/peter/install-sel-1.png" /><br /> <br /> In order to uninstall the Selenium server service, the following commands can be run:<br /> <span style="font-family: 'Courier New';">net stop Selenium-Server<br /> "C:\Program Files (x86)\nssm-2.22\win64\nssm.exe" remove Selenium-Server </span><br /> <br /> <img alt="name project" src="/blogimages/peter/install-sel-2.png" /></p> <h3>Step2: Create a test class and add it to source control</h3> <p>Create a new class library project in Visual Studio, lets call it 'tests'<br /> Open the Nuget Package Manager Console window (tools menu-> library package manager -> package manager console), select the test project as the default project and run the following script:<br /> <br /> Install-Package Selenium.Automation.Framework<br /> Install-Package Selenium.WebDriver<br /> Install-Package Selenium.Support<br /> Install-Package NUnit<br /> Install-Package NUnit.Runners<br /> <br /> Create a new class called within the tests project (lets call it tests) and place the below code (Note: line 23 should be changed with location to the Selenium-Server we setup in the previous step):</p> <pre class="brush: c#; toolbar:true"> using System; using System.Text; using NUnit.Framework; using OpenQA.Selenium.Firefox; using OpenQA.Selenium; using OpenQA.Selenium.Remote; using OpenQA.Selenium.Support.UI; namespace SeleniumTests { [TestFixture] public class test { private RemoteWebDriver driver; [SetUp] public void SetupTest() { // Look for an environment variable string server = null; server = System.Environment.GetEnvironmentVariable("SELENIUM_SERVER"); if (server == null) { server = "http:// *** PUT THE NAME OF YOUR SERVER HERE ***:4444/wd/hub"; } // Remote testing driver = new RemoteWebDriver(new Uri(server), DesiredCapabilities.Firefox()); } [TearDown] public void TeardownTest() { try { driver.Quit(); } catch (Exception) { // Ignore errors if unable to close the browser } } [Test] public void FirstSeleniumTest() { driver.Navigate().GoToUrl("http://www.google.com/"); IWebElement query = driver.FindElement(By.Name("q")); query.SendKeys("a test"); Assert.AreEqual(driver.Title, "Google"); } } } </pre> <h3>Step3: Test the test!</h3> <p>Build the solution<br /> Open NUnit build runner (by default this is located at ~\packages\NUnit.Runners.2.6.3\tools\nunit.exe) , Select file -> Open Project, and locate the tests dll that you have build in the previous step<br /> click the run button<br /> ~ 15 seconds or so you should have one green test!<br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-17.png" /><br /> <br /> So what just happened? Behind the scenes an instance of firefox was opened (on the Selenium Server), perform a simple google search query and undertook a simple Nunit assertion has verified the name of the window was equal to "Google", very cool!.<br /> <br /> Now lets make the test fail, go ahead and change line 78, lets say "zzGoogle", build, and rerun the test. We now have a failing test. Go ahead and change it back so that we have a single passing test.<br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-18.png" /></p> <h4>Create a source control repository</h4> <p>In this example, we're using mercurial</p> <p><span>open a command prompt at ~\</span><br /> <span>type "hg init"</span><br /> <span>add a .hgignore file into the directory. Forconveniencewe have prepared one for you</span><a href="/blogimages/peter/.hgignore.txt">here</a><br /> <span>type "hg add"</span><br /> <span>type "hg commit -m "initial commit""</span></p> <p> </p> <h3>Step 4: Setting up Automated UI testing in ContinuaCI</h3> <p>Navigate to the ContinuaCI web interface</p> <p> </p> <h4>Create a project</h4> <p><br /> Open ContinuaCI<br /> Select "Create Project" from the top tasks dropdown menu<br /> <br /> <img alt="create project" src="/blogimages/peter/create-project-1.png" /><br /> <br /> Name the project something memerable; In our case: "pete sel test 1"<br /> <img alt="name project" src="/blogimages/peter/create-project-3.png" /><br /> Click the "Save & Complete Wizard" button</p> <p> </p> <h4>Create a configuration for this project</h4> <p><br /> Click "Create a Configuration"<br /> Name the config something memorable; in our case "sel-testconfig-1"<br /> Click save & Continue<br /> Click the 'Enable now' link at the bottom of the page to enable this configuration</p> <p> </p> <h4>Point to our Repository</h4> <p><br /> under the section "Configuration Repositories", select the "Create" link<br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-4.png" /><br /> <br /> Name the repository "test_repo"<br /> Select "Mercurial" from the "type" dropdown list<br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-6.png" /><br /> <br /> Select the Mercurial" tab from the top of the dialogue box<br /> Enter the repository location under "source path" in our case '\\machinename\c$\sel-blog-final'<br /> Click validate to ensure all is well<br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-8.png" /><br /> <br /> Click save, your repository is now ready to go!<br /> <img alt="name project" src="/blogimages/peter/create-project-9.png" /></p> <p> </p> <h4>Add actions to our build</h4> <p><br /> Click on the Stages tab<br /> We will add a nuget restore action, click on the "Nuget" section from the categories on the left<br /> Drag and drop the action "Nuget Restore" onto the design surface<br /> Enter the location of the solution file: "$Source.test_repo$\tests.sln"<br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-11.png" /><br /> <br /> Click Save</p> <h4>Build our tests</h4> <p><br /> Click on the "Build runners" category from the categories on the left hand menu<br /> Drag and drop a Visual Studio action onto the design surface (note that the same outcome can be achieved here with an MSBuild action).<br /> <br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-19.png" /><br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-13.png" /><br /> <br /> Enter the name of the solution file: "$Source.test_repo$\tests.sln"<br /> Specify that this should be a 'Release' build under the configuration option<br /> Click save</p> <p> </p> <h4>Setup ContinuaCI to run our Nunit tests</h4> <p><br /> Select the 'unit testing' category from the left hand menu<br /> Drag and drop an NUnit action onto the design surface<br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-20.png" /><br /> <br /> Name our action 'run UI tests'<br /> Within the files: option, specify the name of the tests project '$Source.test_repo$\tests\tests.csproj'<br /> Within the Project Configuration section specify 'Release'<br /> Specify which version of NUnit<br /> In order to provide greater configuration flexibility we can pass in the location of our Selenium server to the tests at runtime. This is done within the 'Environments' tab. In our case the location of the Selenium server is<span></span><span>http://SELSERVER:4444/wd/hub</span><span>.</span><br /> <br /> <img alt="environment tab" src="/blogimages/peter/create-project-24.png" /><br /> <br /> Click Save<br /> <br /> Click save and complete Wizard<br /> We are now ready to build!<br /> <br /> Start a build immediately by clicking the top right hand side fast forward icon<br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-14.png" /><br /> A build will start, and complete!<br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-15.png" /><br /> When viewing the build log (this can be done by clicking on the green build number, then selecting the log tab) we can see that our UI tests have been run successfully. They are also visible within the 'Unit Tests' tab which displays further metrics around the tests.<br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-23.png" /><br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-22.png" /></p> <p> </p> <p> </p> <h3>Step 5: Getting more advanced</h3> <p>Lets try a slightly more advanced example. This time we will examine a common use case. A physical visual inspection test needs to be conducted before a release can progress in the pipeline.<br /> <br /> Place the following code within our test class.</p> <pre class="brush: c#; toolbar:true"> using System; using System.Text; using NUnit.Framework; using OpenQA.Selenium.Firefox; using OpenQA.Selenium; using OpenQA.Selenium.Remote; using OpenQA.Selenium.Support.UI; namespace SeleniumTests { [TestFixture] public class test { private RemoteWebDriver driver; [SetUp] public void SetupTest() { // Look for an environment variable string server = null; server = System.Environment.GetEnvironmentVariable("SELENIUM_SERVER"); if (server == null) { server = "http:// *** PUT THE NAME OF YOUR SERVER HERE ***:4444/wd/hub"; } // Remote testing driver = new RemoteWebDriver(new Uri(server), DesiredCapabilities.Firefox()); } [TearDown] public void TeardownTest() { try { driver.Quit(); } catch (Exception) { // Ignore errors if unable to close the browser } } [Test] public void FirstSeleniumTest() { driver.Navigate().GoToUrl("http://www.google.com/"); IWebElement query = driver.FindElement(By.Name("q")); query.SendKeys("a test"); Assert.AreEqual(driver.Title, "Google"); } [Test] public void MySecondSeleniumTest() { // Navigate to google driver.Navigate().GoToUrl("http://www.google.com/"); IWebElement query = driver.FindElement(By.Name("q")); // Write a query into the window query.SendKeys("a test"); // wait at maximum ten seconds for results to display var wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10)); IWebElement myDynamicElement = wait.Until< IWebElement >((d) => { return d.FindElement(By.Id("ires")); }); // take a screenshot of the result for visual verification var fileName = TestContext.CurrentContext.Test.Name + "-" + string.Format("{0:yyyyMMddHHmmss}", DateTime.Now) + ".png"; driver.GetScreenshot().SaveAsFile(fileName, System.Drawing.Imaging.ImageFormat.Png); // perform an code assertion Assert.AreEqual(driver.Title, "Google"); } } } </pre> <p> </p> <p><br /> Build, and run the test.<br /> <br /> In this example we added an additional test to perform a google search, wait at maximum 10 seconds for results to display, take a screenshot (stored it to disk), and perform an NUnit assertion. The screenshot output from the test can be made available as an artifact within Continua!<br /> <br /> Firstly lets commit our changes; "hg commit -m "added a more advanced test""<br /> <br /> Open the configuration in Continua CI (clicking the pencil icon)<br /> Navigate to the stages section<br /> Double click on the stage name (which will bring up the edit stage Dialogue box)<br /> Click on the Workspace rules tab<br /> Add the following line to the bottom of the text area: "/ < $Source.test_repo$/tests/bin/Release/**.png". This will tell Continua to return any .png files that we produced from this test back to the ContinuaCI Server.<br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-25.png" /><br /> <br /> Click on the artifacts tab.<br /> Add the following line : **.png" This will enable any .png files within the workspace to be picked up and displayed within the Artifacts tab.<br /> **.png<br /> <img alt="name project" src="/blogimages/peter/create-project-26.png" /><br /> <br /> Click save<br /> Click Save & Complete Wizard<br /> Start a new build<br /> <br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-14.png" /><br /> <br /> Sweet! A screenshot of our test was produced, and can be seen within the Artifacts tab!<br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-27.png" /><br /> Clicking on 'View' will display the image:<br /> <br /> <img alt="name project" src="/blogimages/peter/create-project-28.png" /><br /> <br /> <span>We have put the sourcecode of this article up on</span><a href="https://github.com/VSoftTechnologies/Automated-UI-Testing">Github</a><span>.</span><br /> <br /> Please subscribe and comment! We are very excited to see what you guys come up with on Continua, happy testing!</p> <p> </p> <h4>Some additional considerations:</h4> <ul> <li>The user which the Selenium service runs under should have correct privileges</li> <li>The machine designated as the Selenium server may require access to the internet if your webapp has upstream dependencies (eg third party API's like github)</li> </ul> 709Runtime Assembly Reference Loading and the CLRhttps://www.finalbuilder.com/resources/blogs/postid/660/runtime-assembly-reference-loading-and-the-clr.NETThu, 05 Jul 2007 19:00:00 GMT<p>Following on from my <a href="/resources/blogs/four-different-flavors-of-net-assemblies-and-the-clr">earlier post</a> about Assembly resolution and CLR versions, I have an observation to share about the .NET Just-In-Time compiler and the resolution of Assembly references. It's a fairly simple observation, but it came as a surprise to me.</p> <p> </p> <p>DISCLAIMER: This is just an observation. I can't find any real concrete specification of the behaviour I'm describing. My supporting documents are <a href="http://research.microsoft.com/~zorn/mre04/PreJit%20Talk.ppt">this PowerPoint presentation</a>, and <a href="http://pubs.doc.ic.ac.uk/FlexibleLinking/FlexibleLinking.pdf">this doctoral thesis</a>.  If you have better references, or consider this either blindingly obvious or blindingly wrong, please post in the comments.</p> <p> </p> <p>I used to think that if "Assembly A" references another assembly, "Assembly B", then Assembly B is loaded (or at least validated) when Assembly A is loaded. If Assembly B is missing, Assembly A won't run. Am I right?</p> <p> </p> <p>It appears I am not right. The rule is that Assembly B will not normally be resolved (ie checked for existence and loaded) until the JIT compiler encounters some code which references a type belonging to that assembly. You could delete Assembly B entirely and Assembly A would work perfectly, providing it didn't touch Assembly B's types in any of the codepaths which you take.</p> <p> </p> <p>I put together a simple pair of C# projects which demonstrate this behaviour. You can download them <a href="https://www.finalbuilder.com/blogimages/angus/AssemblyResolution/Assembly%20Resolution%20Example.zip">here</a>.</p> <p> </p> <p>The projects build two assemblies, ResolutionTest.exe and MissingAssembly.dll (such creative names!)</p> <p> </p> <p><img alt="One .DLL and One .EXE File" src="/blogimages/angus/AssemblyResolution/folderBefore.png" /></p> <p> </p> <p>MissingAssembly contains one class, MissingClass. ResolutionTest contains a static Program class and another class, MainClass. Here is the code for MainClass:</p> <p><img alt="MainClass Source" src="/blogimages/angus/AssemblyResolution/mainClass.png" /></p> <p>(This is the executive summary version. The actual source has some other attributes and comments about inlining. I'll get to that in a minute.)</p> <p> </p> <p> </p> <p>Here's what happens when it runs:</p> <p> </p> <p><img alt="Normal Execution" src="/blogimages/angus/AssemblyResolution/appBefore.png" /></p> <p> </p> <p>No great surprises. A MainClass object is instantiated. The constructor calls the SubMethod() method, which then creates a new object of type MissingClass from the MissingAssembly.</p> <p> </p> <p style="text-align: left;">Now, suppose we delete MissingAssembly:</p> <p style="text-align: left;"><img align="left" alt="Just an EXE, no DLL" src="/blogimages/angus/AssemblyResolution/folderAfter.png" style="float: left;" /></p> <p style="text-align: left;"> </p> <p><img alt="Uh-oh! An exception!" src="/blogimages/angus/AssemblyResolution/appAfter.png" /></p> <p> </p> <p>An exception is raised because it can't find the MissingAssembly object. However, the MainClass() constructor still executes. The FileNotFoundException occurs when the call to SubMethod() is made. The JITter has examined SubMethod() and said "I need a MissingClass which is held in assembly MissingAssembly. I'd better go find that...", and then failed to find it.</p> <p> </p> <p><strong> </strong></p> <h3><strong>Why is this worth knowing?</strong></h3> <p><strong> </strong></p> <p>Because (I think) it means that you can "cheat" when binding assemblies. Previously I'd used late binding  via Reflection (<a href="http://www.c-sharpcorner.com/UploadFile/samhaidar/LateBindingWithReflection09122005053810AM/LateBindingWithReflection.aspx">like this</a>) when I didn't know if something might or might not be installed on the end user's machine. As far as I can tell, this approach is not wholly necessary - If the "third party" type references are all encapsulated nicely away from the "main" code, it should be possible to just use exception handling to react if the types aren't available at JIT-time.</p> <p> </p> <p>It's also worth knowing because even if you call Assembly.Load() at runtime without any problems, it doesn't mean all the references have resolved. The loaded assembly could still break when you go to use it.</p> <p> </p> <p> </p> <h3><strong>Some things to remember</strong>:</h3> <ul style="list-style-type: disc;"> <li>This isn't something that you can should use every day. You can dig yourself a big hole of shoddy design by doing this. In my case, I just needed a clean way to disable some functionality and fail cleanly when optional assemblies weren't available.</li> <li style="padding: 5px;">The assemblies still have to be available when the source is compiled to IL. You can't compile IL which references types or assemblies that do not exist.</li> <li style="padding: 5px;">This knowledge can help you <a href="http://msdn2.microsoft.com/en-us/library/ms998547.aspx#scalenetchapt05_topic33">optimize your code</a>, by controlling when extra loading and JITting is performed.</li> <li style="padding: 5px;">There is a chance that the JITter will <a href="http://blogs.msdn.com/ericgu/archive/2004/01/29/64717.aspx">inline lightweight method calls</a>. If MainClass.SubMethod() is inlined into the constructor, then it's possible that the constructor will fail. I originally tried to avoid this by attaching <a href="http://msdn2.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions.aspx">MethodImplOptions.NoInlining</a> to SubMethod(). However, in the end I couldn't make it inline the code under any circumstances. It's possible that the JITter notices the unloaded type inside the method, and decides not to inline for that reason.</li> <li style="padding: 5px;">It's a bit of a hack, but you could dynamically link to one of several available assemblies at runtime, by going through a series of alternative wrapper classes (each referencing different assemblies) and finding the one which loads successfully. If all of the wrappers implemented a common interface, you could then use the components interchangeably with acceptable performance. A more generalised CLR-supported model of this is described in the doctoral thesis I linked to above (he demonstrates dynamically choosing an alternative to Windows.Forms for GUI display when running <a href="http://research.microsoft.com/programs/europe/rotor/">Rotor</a> on OS X or Linux.)</li> <li style="padding: 5px;">This probably doesn't work if you've used ngen.exe, for obvious reasons.</li> </ul> <p>Happy coding!</p> <p> </p> 660Four different flavors of .NET Assemblies and the CLRhttps://www.finalbuilder.com/resources/blogs/postid/659/four-different-flavors-of-net-assemblies-and-the-.NETMon, 02 Jul 2007 19:00:00 GMT<p>(This is a technical post about some of the "gotchas" when coding for .NET on 64- and 32-bit architectures.)</p> <h2>The short story:</h2> <p>The TeamFoundation client assemblies are x86-only assemblies. They don't work when called from an x64 .NET Application.</p> <p>Even though they're in the GAC, you'll get a FileNotFoundException if the CLR tries to load them.</p> <h3> </h3> <h2>My story:</h2> <p>I already knew this, but it took me most of the day to realise that was my problem.</p> <h3> </h3> <h2>The long story:</h2> <p>Microsoft's .NET CLR 2.0 supports three different processor architectures: <a href="http://en.wikipedia.org/wiki/X86_architecture">x86</a>, <a href="http://en.wikipedia.org/wiki/X86-64">x64</a> and <a href="http://en.wikipedia.org/wiki/Itanium">IA-64</a>.  This means that there are three different CLR environments. x64 machines can host the x86 CLR alongside the native 64-bit CLR.</p> <p> </p> <p>Although the CLR executes architecture-agnostic <a href="http://en.wikipedia.org/wiki/Common_Intermediate_Language">Common Intermediate Language</a> (aka MSIL) code, any assembly can be marked as only suitable for one of the particular architectures.This is what happens when you choose a "Platform" type for a Visual Studio project. Choosing 'Any CPU' means that the project Assemblies are marked as language-agnostic CIL code.</p> <p> </p> <p>It all plays out like this:</p> <p> </p> <table border="1" cellpadding="1" cellspacing="1" height="113" width="496"> <tbody> <tr> <td><strong>CLR Type</strong></td> <td><strong>Can Be Hosted From</strong></td> <td><strong>Can Load These Assembly Types</strong></td> </tr> <tr> <td>x86</td> <td>x86 or x64 Operating Systems</td> <td>x86, "Any CPU"</td> </tr> <tr> <td>x64</td> <td>x64 Operating Systems</td> <td>x64, "Any CPU"</td> </tr> <tr> <td>IA-64</td> <td>Itanium Operating Systems</td> <td>IA-64, "Any CPU"</td> </tr> </tbody> </table> <p> </p> <p>Or, alternatively:</p> <p> </p> <table border="1" cellpadding="1" cellspacing="1" width="200"> <tbody> <tr> <td><strong>Assembly Type</strong></td> <td><strong>Can Run On</strong></td> </tr> <tr> <td>"Any CPU" / MSIL</td> <td>Any CLR</td> </tr> <tr> <td>"x86"</td> <td>x86 CLR Only</td> </tr> <tr> <td>"x64"</td> <td>x64 CLR Only</td> </tr> <tr> <td>"IA-64"</td> <td>IA-64 CLR Only</td> </tr> </tbody> </table> <p>To find out if an assembly is x86-only, you can use the <a href="http://msdn2.microsoft.com/en-us/library/ms164699(VS.80).aspx">CorFlags.exe</a> utility which ships with the .NET SDK. You can also use this tool to tweak the assembly type, although doing this will break strong named assemblies and generally cause chaos.</p> <p> </p> <p>When loading a.NET-based process, the .NET Framework decides which version of the CLR to load based on the assembly type. Processes based on "Any CPU" assemblies will load in the native CLR for the host system.</p> <p>This can lead to some funny situations. For example, the ASP.NET Development Server application is 32-bit only, so any web sites you run on it will run in the x86 CLR. On the other hand, on x64 IIS can run either 32- or 64-bit ASP.NET applications. This means you can move your ASP.NET application from the Development Server to IIS <em>on the same machine</em>, and all of a sudden you will get a BadImageFormatException when an assembly refuses to load any more.</p> <h2>The Twist:</h2> <p>Sometimes you get a FileNotFoundException instead. This is when you try to reference an Assembly which is in the GAC.</p> <p> </p> <p>... and you think "That's odd, I thought that assembly was in the GAC." and you look in the GAC browser, and there it is:</p> <p> </p> <p> </p> <p><img alt="GAC Viewer In Explorer" src="/blogimages/angus/GACViewer.png" /></p> <p> </p> <p>... the key is the "Processor Architecture" column on the righthand side.</p> <p> </p> <p>As of .NET Framework 2.0, the CLR actually has <a href="http://hoser.lander.ca/The+Wonders+Of+The+Whidbey+GAC++Part+I+Processor+Architecture.aspx">four different GACs</a> - one for each architecture, and one for "Any CPU" MSIL Assemblies. You can see this quite literally if you <a href="http://www.clariusconsulting.net/blogs/pga/archive/2006/04/05/685.aspx">disable the GAC Shell extension</a>, and browse to the GAC directory.</p> <p> </p> <p>Each version of the CLR can only load assemblies which exist in its own GAC, or in the architecture-agnostic MSIL GAC. If you try to load an assembly from a different GAC, you'll see the FileNotFoundException.</p> 659FinalBuilder 3 &amp; Visual Studio 2005 Beta 2https://www.finalbuilder.com/resources/blogs/postid/396/finalbuilder-3-amp-visual-studio-2005-beta-2.NET,FinalBuilderThu, 21 Apr 2005 17:04:00 GMT<p><span style="font-family: Arial; font-size: 13px;"> </span></p> <p style="text-align: left;"><span style="font-family: Arial; font-size: 13px;">I spent the last few days playing with VS 2005, testing the VS.NET support in <a href="/finalbuilder" target="_blank" title="Finalbuilder Website">Finalbuilder</a> 3. If you are trying to build VS2005 Beta 2 projects with the current build of FinalBuilder you will run into problems which are due to the changes between Beta 1 & 2. Since we've only just got our hands on the beta (like every one else), it's going to take us a while to get to grips with it, understand how it works under the hood and figure out what we need to do. We've made a start, and the information below is based on a preliminary review of Beta 2.</span></p> <p style="text-align: left;"><span style="font-family: Arial; font-size: 13px;"> </span></p> <p style="text-align: left;"><span style="font-family: Arial; font-size: 13px;">The good news is you can still use the current build of FinalBuilder with VS 2005 Beta 2 but it needs some gentle persuasion. </span></p> <p style="text-align: left;"><span style="font-family: Arial; font-size: 13px;"> </span></p> <p style="text-align: left;"><span style="font-family: Arial; font-size: 13px;">The "Build VS.NET Solution" action works (I only tested .net apps, not C++), however it doesn't parse the available configs correctly as the solution file format has changed slightly. Configs in the solution file look something like this : "Debug|.NET" - just select the config you want then trim of the |.NET part and it should build fine. Updating Assembly info works, but not for ASP.NET 2.0 projects. ASP.NET seems to have the most changes, and we'll need some time to understand how they fit together and what we can do with them. To precompile ASP.NET 2.0 applications, use the MSBuild action and use the solution file as the project file (interesting that msbuild knows about solution files even though it's not part of vs). Compiling an asp.net application in VS2005 seems to be just a syntax check from what I can see, no binaries are produced. </span></p> <p style="text-align: left;"><span style="font-family: Arial; font-size: 13px;"> </span></p> <p style="text-align: left;"><span style="font-family: Arial; font-size: 13px;">The "C#/VB.NET/J# Project Compiler" actions will not work at all with VS2005 Beta 2 Projects. The reason for this is that the project file formats (csproj,vbproj,vjsproj) have changed and are not at all backwards compatible. The good news is the files are really just msbuild files, and you can build them quite easily with the MSBuild Action. </span></p> <p style="text-align: left;"><span style="font-family: Arial; font-size: 13px;"> </span></p> <p style="text-align: left;"><span style="font-family: Arial; font-size: 13px;">While it's early days still, and Microsoft may still make further changes to file formats, where they live etc (although I hope they don't!), we plan on getting the VS2005 Beta 2 support done asap. The "Build VS.NET Solution" action needs some tweaking. For asp.net 2.0 projects, we'll be creating a new action for pre-compiling them. We will also be creating new actions that are the equivalent of the "C#/VB.NET/J# Project Compiler" actions, they will leverage the work we have already done on the MSBuild action. </span></p> <p style="text-align: left;"><span style="font-family: Arial; font-size: 13px;"> </span></p> <p><span style="font-family: Arial; font-size: 13px;">Stay Tuned!</span></p> 396