The Story of the Old Assembly...

Once upon at time there was an assembly. It was a good assembly. It did it's job very, very well. It was an assembly that was very important to its fellow assemblies. It not only contained business related logic, but it also served as an implementation boundary to other satellite assemblies.

Well, one day, as the application was being tested by the thorough QA technician, things weren't behaving as they should. The ever important assembly seemed to be having "issues". The QA technician was testing specific scenarios that surely the ever important assembly could perform; but alas, the technician had to enter a "failure" report on the test cases that he was testing. The ever important assembly was devastated. It didn't know what went wrong. Surely the master developers who created him had done their job well. Surely the QA technician was testing as good as he had before... What was the problem??

Well, as time went on the assembly had to rely on the helpful hand of the development team to find out what it's problem was. Turns out, that the problem was simple once the symptoms were clearly understood.

The symptoms were somewhat puzzling, however. The nightly build process was working fine. The code compiled on every machine that it ran on. But something very interesting occurred: the timestamp of the assembly was almost 2 weeks old on the QA box. Hmmm...what could this mean? "Perhaps something was wrong with the build server", the assembly thought. Well, after hours of looking into the issue, and pouring through the build process, it became apparent what the problem was....

A little over a week prior, in the dark of night, a little gremlin snuck into the application solution and decided to mess with this ever important assembly. It opened up Visual Studio 2008, opened up the parent project, expanded the "References" folder, and right clicked on the assembly while it slept, and clicked "properties". While inside the "Properties" view the little nefarious gremlin changed the "Copy Local" value to "False".

Nearly two weeks passed before it became apparent that something was awry with the ever important assembly. Well, the developers came to save the day and changed the "Copy Local" value back to "True". The build ran successfully, and the old assembly was old no more...

Cheers filled the office air as the QA technician retested his scenarios! Pass, Pass Pass...was the chant!! All was well!

 

OK, the moral of the story, if you try to publish a project, and an assembly is not being updated (and it's satellite assemblies don't get published either), the FIRST thing that look at is the "Copy Local" property of  the assembly reference from within the parent application.

 

What did you think of this article?




Trackbacks
  • No trackbacks exist for this post.
Comments
  • No comments exist for this post.
Leave a comment

Submitted comments are subject to moderation before being displayed.

 Enter the above security code (required)

 Name

 Email (will not be published)

 Website

Your comment is 0 characters limited to 3000 characters.