Continuous Integration and Other Tips
I keep talking about continuous integration because I have come to rely on the feedback it provides. As you commit changes to your version control, the continuous integration engine gets a fresh copy of the code, builds the code, and runs tests against the compiled results providing the team with a quick picture of the state of the code.
Continuous integration helps you keep your code working. New bugs that get past developers are caught quickly. Older code that was impacted, and now broken, by a contemporary change is identified quickly.
Preferably those kinds of bugs are found by developers running automated tests before committing changes. However, sometimes in larger libraries, code may be used in multiple places such that a developer could in good conscience check in a breaking change.
Recently our current team moved away from a CI product that is popular because it integrates with Dot Net Code development tools. After hours of effort, and months of waiting, the team moved our CI to Team City, implementing the software in 1 day, and having continuous integration on multiple solutions the following day.
This is not intended to be a plug for Team City as much as a bit of a rant about choosing tools based on cost, gut feeling, or something you used elsewhere.
NuGet Tip…
I like NuGet. Nuget is a Visual Studio extension that allows you to keep external libraries up to date, and manage the references to them in a simple fashion. At the same time I have been fighting with NuGet because I was constantly having to resolve the references in solutions.
The tip a colleague found today was that for those libraries used in more than one solution, you need to modify the project so that the Project Directory Variable uses a relative path, and that all your projects resolve to the same relative path. Then, the Libraries referenced can use that Project Directory Variable to resolve the reference to the external libraries such as NUnit, etc.
Here are some of the hard won instructions my colleague found and wrote up…
1. Unload the project from the solution
2. Edit the csproj file (right click, edit)
3. Modify the $SolutionDir entry to remove any non-variable names:
FROM SOMETHING LIKE:
<SolutionDir Condition="$(SolutionDir) == ” Or $(SolutionDir) == ‘*Undefined*’">……WebApplications</SolutionDir>
TO:
<SolutionDir Condition="$(SolutionDir) == ” Or $(SolutionDir) == ‘*Undefined*’">……..</SolutionDir>
4. Modify the NuGet packages HintPath variables to use the $SolutionDir variable in front of the “packages” folder:
FROM SOMETHING LIKE:
<HintPath>……MyApplicationpackagesNewtonsoft.Json.5.0.6libnet35Newtonsoft.Json.dll</HintPath>
TO:
<HintPath $(SolutionDir)packagesNewtonsoft.Json.5.0.6libnet35Newtonsoft.Json.dll</HintPath>
5. Reload the project
You will also want to make sure your solution has “Enabled NuGet Package Restore”, and that the NuGet.exe, NuGet.config, NuGet.targets and all of the packages.config files have been included in your source control commit.
The big change here is that since the virtual path is the same for all solutions, the project will continue to load the defined NuGet package, regardless of what solution in which it is included.
Life is so much better after today. I like those kinds of days.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Tips for using SQL Server 2012 Table Hints
In this article, you can find some helpful tips to use SQL Server 2012 table hints.
Featured White Paper(s)
Key Considerations in Evaluating Data Warehouse Appliances
read more)