Microsoft MSBuild caches target calls internally. Thus, it is not possible to build same project(s) twice (i.e. when you are propagating changes between logical subsolutions).
One of the workarounds is about batching .NET builds. Another one is simply about calling MSBuild projects multiple times while adding dummy values to the properties:
<MSBuild
Projects="@(SomeSolution)"
Targets="Rebuild;Copy"
Properties="SomeProperty=SomeValue;DummyProperty=1;" />
BTW, MSBuild has a nice switch called “/maxcpucount:n” (or “/m” for short), that specifies the maximum number of concurrent processes to build with.
Published on August 1, 2008
in Snippets.
Synergy is the term used to describe a situation where the final outcome of a system is greater than the sum of its parts.
Integration between different development subsystems does not yield only benefits and efficiency boosts. You can get more issues as well. Here’s vivid example:
- User is located in Russia (GMT +5). He sends in the change to SVN at August 1, 01:21 local time (via TSVN 1.5.0)
- Subversion repository (SVN 1.5) is located in the France (GMT +1). It files changes as July 31, 19:21 universal time
- Integration server (CC.NET 1.4) is hosted somewhere in Arizona (GMT -7). A bit later it requests changes in the interval up to July 31, 19:34 universal time (using SVN client 1.5.0.31699)
- Subversion server returns XML like:
<?xml version="1.0"?>
<log>
<logentry revision="20">
<author>rinat.abdullin</author>
<date>2008-07-31T17:37:43.265138Z</date>
<paths>
<path action="M">/Platform/trunk/CENSORED.build</path>
</paths>
<msg>Restored back FxCop analysis. #DistribRelease</msg>
</logentry>
<logentry revision="21">
<author>rinat.abdullin</author>
<date>2008-07-31T19:21:12.328206Z</date>
<paths>
<path action="M">/Platform/trunk/Libraries/!Readme.txt</path>
</paths>
</logentry>
</log>
- Note, that the second log entry does not have the msg item. That’s what hits CruiseControl.NET hard in some C# code:
private static string ParseMessage(XmlNode logEntry)
{
XmlNode msgNode = logEntry.SelectSingleNode("msg");
return msgNode.InnerText;
}
- TortoiseSVN does display the second message properly:
Now here’s the challenge: which issue tracker(s) does this issue belong to?
The management of software development is all about using scarce development resources to satisfy unlimited wants of the customers.
In the situations with limited resources (time, budget and skilled labor) the only way to get more out of nothing is to use these resources more efficiently. One way of achieving such a goal is about better automation of some development processes and leveraging the opportunities provided by the integration of different development subsystems.
Here some examples of such automation and integration:
- Integration server tags SVN on every production build, runs the normal routine, then packages all redistributables in a separate folder (matching build label) that is accessible via FTP (side effect is that all production packages are saved somewhere and could be easily retrieved if such need arises).
- Integration server uses svnRevisionLabeller (or any other similar plugin) to retrieve revision number from the SVN, incorporate it into the proper 4-digit version and build .NET assemblies with that.
- Integration server updates version flag on every production release. Production systems have module that checks this flag regularly and informs user of the new version.
- Integration server updates Click-Once publication on every production release and the client application updates automatically after the next launch.
- Keywords (feature from the Subversion) are used to populate attributes of some business classes with the “last changed” and “latest revision id” values on per-file basis. These values are retrieved via the reflection upon the generation of some inter-development reports/statistics
- Integration server hosts continuous monitoring project that regularly checks the production systems, runs some sanity checks and reports any failures or deviations if they are detected
- Integration server checks commit messages before build and passes all encountered tags to the build script (i.e.: #RunAllTests, #DeployToTest, #CreateRelease, #SetVersion(1.2), #TestPerformance etc). Friend of mine used to do that on his projects.
- Integration server locates all issues/tickets that were closed since the last release build, marks them with the build version and either creates a link to the filter in issue management system (JetBrains does that) or auto-populates change log report (being delivered with the release artifacts).
- Integration server runs the unit-tests and captures screen-shots of all the presenters available. These shots are then labeled and framed nicely and are used to update the pictures in the product documentation (which is also gets packaged and processed on the release cycle)
- Production release creates Virtual Machine package with the pre-installed and pre-configured solution (could be used by testers and sales-people)
I’ve leveraged some of these scenarios (items 1 through 6) in different development projects I’ve been a part of (esp. in projects that were based on the xLim principles). On the overall such things do really reduce the development friction and have solid Return On Investment rate in increased stability and saved time. And they also reduce the risk that a mere mortal would make a stupid mistake while performing some mundane action.
Reduced development and release friction obviously promote faster development iterations. That shrinks the lag between the moment customers have requested some functionality and the moment they can inspect it (and provide feedback for the next changes).
Are there any time-saving recipes that have proved themselves worthy in your project and are not on this list?
NB: Obviously one must be cautious about taking any single item from the list and applying it to the specific development project. Specifics always matter and not all combinations will be worth it.
Boo language has nice code pattern called Generator:
// Generator expressions are defined through the pattern:
<expression> for <declarations> in <iterator> [if|unless <condition>]
// Generator expressions can be used as return values:
def GetCompletedTasks():
return t for t in _tasks if t.IsCompleted
// Generator expressions can be stored in variables:
oddNumbers = i for i in range(10) if i % 2
This pattern simply creates some IEnumerable object via the syntax transformation. We can not have this sugar in C# yet, but that’s how we can leverage the concept:
// Simple syntax
var customerList = new List<Customer>();
for (int i = 0; i < 40; i++)
{
customerList.Add(new Customer
{
Name = "Customer_" + i
});
}
// generator + LINQ syntax
var customers = Generator.For(40).Select(i => new Customer
{
Name = "Customer_" + i
});
Continue reading ‘Generator pattern in C# .NET’
Ricardo Cavalcanti has raised question on fluent passing of parameters into the queries encapsulated by the QueryFor (specification) pattern.
Let’s talk about the easiest option of passing parameters, first. It requires no new code at all and is just about chaining queries:
var list = customers
.Find<ImportantCustomers>()
.Where(c => c.City == "Ufa");
Where comes from the in line extension method provided by Linq.
However, in certain situations Linq might be not enough. This involves queries that encapsulate come complex business logic or require parameter pre-processing, that you want to hide away.
Continue reading ‘Linq queries with parameters for your ORM IRepository’
Latest version of NUnit unit-testing framework for .NET has finally got support for the row tests. They are implemented by Andreas Schlapsi as an extension that now comes bundled with the NUnit 2.4.7.
Basically, row test is a test that could be run multiple times with different parameters (in other words, it is a simple data-driven test, where the data is provided by the attributes). Consider the following C# code snippet:
[TestFixture]
public sealed class Test_InterceptorCompiler : DslTests
{
[RowTest]
[Row("Chained Interceptions.boo")]
[Row("ConsoleWriter.boo")]
[Row("IWriter.boo")]
[Row("Multiple Classes.boo")]
[Row("Complex Writer.boo")]
public void Interception_Dsl_Compiles(string name)
{
var step = new InterceptorCompilerStep()
.Intercept<ComplexWriter>()
.Intercept<ConsoleWriter>()
.Intercept<IWriter>();
CompileDslToMemory(step, name);
}
}
Upon the execution in the NUnit GUI it will produce the following output:
Note, how every Row is treated as a separate unit test, and you can see which parameters have caused the failure.
Disadvantage of this new feature of NUnit is - JetBrains test runner (it comes with the R#) does not recognize them, yet. You would need to fire up NUnit GUI or use some other VS integration like TestDriven.NET in order to “run this test from the code”.
PS: there is an interesting podcast on the topic - The Past, Present and Future of .NET Unit Testing Frameworks.
We’ll get back from the Boo + Business + DSL to the XPO + ORM + IOC series for a little bit.
Nicholas Blumhardt has just written an interesting and extremely thorough article on Implementing the Specification Pattern via Linq. Let’s try to play with the idea and take it a one step down the road. Here we can:
1. Add ORM abstraction by implementing generic IRepository (of T) interface:
public interface IRepository<T>
{
IQueryable<T> Find(QueryFor<T> query);
IQueryable<T> Find(string criteria);
IQueryable<T> Find<K>() where K : QueryFor<T>, new();
IQueryable<T> Query();
// ...
}
Continue reading ‘Implementing ORM-independent Linq queries’
Latest Comments