I ran into something with Team Build 2008 that burnt me up for pretty much a whole day. I was using the AfterCompileSolution target (as I saw suggested) to run the building of our setup projects (because MSBuild doesn't support setup projects - how can an open source setup project engine - wix - support MSBuild and MS does support them is beyond me). Anyway, I am also using the AssemblyInfoTask to increment our version numbers. So the $(MaxAssemblyVersion) is always blank. Even though I went into the blah.blah.Versioning.targets and spit it out there and it gives me the 5.0.0.10 I am expecting. So, WTF.
Dunno, but apparently something is out of scope, so if I go back to "AfterCompile" instead of "AfterCompileSolution" then it's back, but now $(Platform) is gone.
????
<Target Name="AfterCompile">
<DevEnv TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildUri="$(BuildUri)"
Solution="$(Solution)"
SolutionConfiguration="Setup"
SolutionPlatform="Any CPU"
Target="Build"
Version="9" />
<WorkspaceItemConverterTask
TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildUri="$(BuildUri)"
WorkspaceName="$(WorkspaceName)"
WorkspaceOwner="$(WorkspaceOwner)"
ServerItems="$/Trimble.MobileSolutions/current">
<Output TaskParameter="LocalItems" ItemName="LocalDirectory" />
</WorkspaceItemConverterTask>
<Exec WorkingDirectory="$(SolutionRoot)"
Command="$(TF) checkin /comment:"Auto-Build: Version Update" /noprompt /override:"Auto-Build: Version Update $(MaxAssemblyVersion)" /recursive $(AssemblyInfoSpec)"
ContinueOnError="true" />
<PropertyGroup>
<LocalDirectoryAsProperty>@(LocalDirectory->'%(FullPath)')</LocalDirectoryAsProperty>
</PropertyGroup>
<CreateItem Include="$(LocalDirectoryAsProperty)\**\product\setup\**\*.msi">
<Output TaskParameter="Include" ItemName="MsiFiles"/>
</CreateItem>
<!--<Copy SourceFiles="@(MsiFiles)" DestinationFolder="$(DropLocation)\xx.$(MaxAssemblyVersion).xx" />-->
<Copy SourceFiles="@(MsiFiles)" DestinationFolder="$(DropLocation)\$(MaxAssemblyVersion)\%(FilesToArchive.RecursiveDir)"/>
<!--<Copy SourceFiles="@(MsiFiles)" DestinationFolder="$(DropLocation)\$(MaxAssemblyVersion)\%(RecursiveDir)" />-->
</Target>
Thursday, October 25, 2007
Tuesday, October 23, 2007
MsBuild and CopyLocal = False
As MsBuild rolls thru building a solution, it calls GetCopyToOutputDirectoryItems as a task (subtask) for each project reference during the CoreCompile task.
If you are using a "build all to one directory" strategy, this is a waste. To change the net effect of this, change all project references to CopyLocal = false.
This decreased our build time from almost 3 minutes to just over 2 minutes.
If you are using a "build all to one directory" strategy, this is a waste. To change the net effect of this, change all project references to CopyLocal = false.
This decreased our build time from almost 3 minutes to just over 2 minutes.
Monday, May 14, 2007
Verbiage: Marco Polo Testing
Even when using TDD, there comes a time when the inevitable occurs that you need to run the application and see how the changes you made effect the application in whole.
In the application I work on, it is very large with a environment that is large and brittle. When I need to run the application, I dread it. About 25% of the time, you need to overcome other problems to get to the meat of your testing. Some of these problems can be overcome by getting a newer version of the source code. Some of these problems can be overcome by getting newer binaries of "second party" DLLs we use. Some problems are within the database or web servers, so it get outside of your control.
This is what I would like to dub "Marco Polo Testing".
Marco Polo Testing - phrase - The act of executing a large piece of software to test a single aspect of it. Upon trying to arrive at the single aspect, you encounter many different unexpected situations. None of these situations were predictable, you have little to no control over any of them. By the time you arrive at the place in the software you wanted to test, you've forgotten why you were going there.
From wikipedia, Exploration
Exploration is the act of searching or traveling for the purpose of discovery, e.g. of unknown regions, including space (space exploration), for oil, gas, coal, ores, caves, water (Mineral exploration or prospecting), or information.
The term can also be used to describe the first incursions of peoples from one culture into the geographical and cultural environment of others. Although exploration has existed as long as human beings, its peak is seen as being during the Age of Discovery when European navigators travelled around the world discovering new worlds and cultures.
In scientific research, exploration is one of three purposes of research (the other two being description and explanation). Exploration is the attempt to develop an initial, rough understanding of some phenomenon.
In the application I work on, it is very large with a environment that is large and brittle. When I need to run the application, I dread it. About 25% of the time, you need to overcome other problems to get to the meat of your testing. Some of these problems can be overcome by getting a newer version of the source code. Some of these problems can be overcome by getting newer binaries of "second party" DLLs we use. Some problems are within the database or web servers, so it get outside of your control.
This is what I would like to dub "Marco Polo Testing".
Marco Polo Testing - phrase - The act of executing a large piece of software to test a single aspect of it. Upon trying to arrive at the single aspect, you encounter many different unexpected situations. None of these situations were predictable, you have little to no control over any of them. By the time you arrive at the place in the software you wanted to test, you've forgotten why you were going there.
From wikipedia, Exploration
Exploration is the act of searching or traveling for the purpose of discovery, e.g. of unknown regions, including space (space exploration), for oil, gas, coal, ores, caves, water (Mineral exploration or prospecting), or information.
The term can also be used to describe the first incursions of peoples from one culture into the geographical and cultural environment of others. Although exploration has existed as long as human beings, its peak is seen as being during the Age of Discovery when European navigators travelled around the world discovering new worlds and cultures.
In scientific research, exploration is one of three purposes of research (the other two being description and explanation). Exploration is the attempt to develop an initial, rough understanding of some phenomenon.
Friday, May 11, 2007
verbiage
my friend and former co-worker, jay flowers developed a strong aversion to our workplace based upon his continue frustration of how stupid we acted. (well, that's my take on it). one of ironies within the irony is that jay came up with these on his own, but he was one of the worst spellers (self-admittedly) i ever met in my entire life; no, he is the worst.
anyway, he used verbiage that was off-the-wall, teaching me phrases such as "the forces", "oral tradition" and others.
since he has left our place where we gather from 9-5 in exchange for u.s. currency, and i have tried to keep his legacy alive and i amuse myself with some of the verbiage i come up with to describe the silliniess of our plight/condition.
i also am trying to find things to post here on a daily basis that document my walk across this this third rock from that star.
so here it is, the 1st in a series of pretty gosh darn funny (at least it amuses me) verbiage i have taken to using around my workplace.
preface: we build software consumed by someone who runs it by a 3rd party 1st. this 3rd party independently tests it before the end consumer accepts it. sometimes, these release get stuck with the 3rd party for a long, long time.
i said today, "there is code to support unit test in the production code".
one of my peers question, "in production, like the users have it???".
"well, released code," i said.
"oh, ok, not in production.", he said.
"ok, well, we released it, let's call it shelf code, then.", i said. and the term "shelf code" was born.
shelf code - noun - code that has left the building, staged to be deployed to the end users, but probably will be in this purgatory for a long, long time.
anyway, he used verbiage that was off-the-wall, teaching me phrases such as "the forces", "oral tradition" and others.
since he has left our place where we gather from 9-5 in exchange for u.s. currency, and i have tried to keep his legacy alive and i amuse myself with some of the verbiage i come up with to describe the silliniess of our plight/condition.
i also am trying to find things to post here on a daily basis that document my walk across this this third rock from that star.
so here it is, the 1st in a series of pretty gosh darn funny (at least it amuses me) verbiage i have taken to using around my workplace.
preface: we build software consumed by someone who runs it by a 3rd party 1st. this 3rd party independently tests it before the end consumer accepts it. sometimes, these release get stuck with the 3rd party for a long, long time.
i said today, "there is code to support unit test in the production code".
one of my peers question, "in production, like the users have it???".
"well, released code," i said.
"oh, ok, not in production.", he said.
"ok, well, we released it, let's call it shelf code, then.", i said. and the term "shelf code" was born.
shelf code - noun - code that has left the building, staged to be deployed to the end users, but probably will be in this purgatory for a long, long time.
Thursday, May 3, 2007
Data is a mess
Found out today that the MB labs data is a utter mess. Everyone blames on people that are no longer there. But, everyone there has allowed to continue to be that way for a long time (eight or more years).
Going to try to straighten some of it out, not the data, but the way it's striped off and put into the entities.
Going to try to straighten some of it out, not the data, but the way it's striped off and put into the entities.
Wednesday, April 18, 2007
Unit Testing Expected Exception
I have seen and implemented a few different patterns to unit test expected exceptions. This was one that I saw the other day that seems to be the pinnacle pattern to unit test an expected exception.
The key aspects of it are:
• Declaration of a variable scoped to the entire method to hold a reference to an exception (Dim theExpectedException As ArgumentNullException)
• Catching the exception @ the most granular level that it HAS to be the expected exception, by using the correct exception type (ex As ArgumentNullException) and the when clause (When ex.ParamName = "lab").
• Asserting on the condition that the exception IsNotNull proves it was thrown and caught in the method.
Sub NewILabAdornmentsNegativeILabNull()
Dim lab As ILab = Nothing
Dim adornments As IDisplayLine.LabAdornmentStrings = None
Dim target As IDisplayLine
Dim theExpectedException As ArgumentNullException = Nothing
Try
target = Factory.DisplayLine(lab, adornments)
Catch ex As ArgumentNullException When ex.ParamName = "lab"
theExpectedException = ex
End Try
Assert.IsNotNull(theExpectedException, "Proves Factory.DisplayLine(ILab,LabAdornmentStrings) throws an ArgumentNullException exception when passed a null lab.")
End Sub
The key aspects of it are:
• Declaration of a variable scoped to the entire method to hold a reference to an exception (Dim theExpectedException As ArgumentNullException)
• Catching the exception @ the most granular level that it HAS to be the expected exception, by using the correct exception type (ex As ArgumentNullException) and the when clause (When ex.ParamName = "lab").
• Asserting on the condition that the exception IsNotNull proves it was thrown and caught in the method.
Sub NewILabAdornmentsNegativeILabNull()
Dim lab As ILab = Nothing
Dim adornments As IDisplayLine.LabAdornmentStrings = None
Dim target As IDisplayLine
Dim theExpectedException As ArgumentNullException = Nothing
Try
target = Factory.DisplayLine(lab, adornments)
Catch ex As ArgumentNullException When ex.ParamName = "lab"
theExpectedException = ex
End Try
Assert.IsNotNull(theExpectedException, "Proves Factory.DisplayLine(ILab,LabAdornmentStrings) throws an ArgumentNullException exception when passed a null lab.")
End Sub
What Macallan @ Old Homestead Should I Get
I am going to the Old Homestead next weekend. I am committing to an appx $150 shot of Macallan. Any suggestions??? I had the 1968 last time and really enjoyed the caramel tones.
Tuesday, April 17, 2007
TFVC - Check Out - Check In - Lock
So, we're about to make the leap from VSS to TFVC. We've got 60 developers. How many times will we lose source code due to someone doing a bad merge?
Anyone else recently gone thru this?
Anyone else recently gone thru this?
Monday, April 16, 2007
VSS History for added files in CCNet
Discovered late last week that when using ccnet components to query VSS for changes, that added files do not have a full path. They only have a 'folder name\file name' path. All parent folders are missing from the path.
Has anyone else looked into how to fix this for ccnet?
Has anyone else looked into how to fix this for ccnet?
Friday, April 13, 2007
CI Factory
Made my second submission to CI Factory today.
Not comfortable with the process yet, but it was my second OSS submission.
Not comfortable with the process yet, but it was my second OSS submission.
Writing Unit Tests For TDD Backwards
Today, co-worker asked me how to write a unit test.
I basically explained to him that we write them backwards:
1. Write the test’s Description using “Proves correctly …”
2. Write your Assert(s) – Each needs to describe its own “Proves…” and that “Proves..” must support the overarching “Proves…”
3. Write your Exectution – The SINGLE statement that invokes the target of the test
4. Write your Setup
When you do the above steps, everything becomes very focused and clear.
I basically explained to him that we write them backwards:
1. Write the test’s Description using “Proves
2. Write your Assert(s) – Each needs to describe its own “Proves…” and that “Proves..” must support the overarching “Proves…”
3. Write your Exectution – The SINGLE statement that invokes the target of the test
4. Write your Setup
When you do the above steps, everything becomes very focused and clear.
Subscribe to:
Posts (Atom)