Referencing different versions of an assembly - Part 1 (ILMerge)

Consider the following scenario:

 

We have one huge monolithic Visual Studio solution.

It contains two applications (App1 & App2) which references lots of other projects (of which I have drawn three - A, B & C), which in turn reference Some other project - "Infra".

Our business requires that we'll develop a new version of App1 which will require a new version of Project A and a new version for Infra.

We could have update Infra, and then update Project A as well as Project B and C and actually release a new version for the whole line of products.

But this is not such a great idea - as it will require building, testing and deploying of App2 without gaining any business advantage.

(You could think that we can just leave the previous version of App2, but actually we need to update it in this scenario to be able to deploy hotfix in case of finding a bug in Infra for example)

So what we actually need is to manage branches and versions.
This will look like this:

 

In this diagram we have made a branch for Infra project and have two versions for it. Project A will use the newer version (V1) while others will use the older version (V2).

We have, however, an implementation problem here - as you can't hold the same project twice in on Visual Studio solution.

We can fix it by breaking out Infra project from the solution into its own solution, and reference DLLs instead projects. This will look like this:

 
(I have left App2 outside this diagram as it not needed for the explanation any more)

This way, each project will reference the version it needs (using "Specific Version").

But is referencing DLLs actually solve the problem?

Let's look at the Bin folder of our projects:

Project A --> Bin --> Infra.dll (version 2)
Project B --> Bin --> Infra.dll (version 1)

App1 --> Bin --> Infra.dll (which version ???)

You see, windows' folders can't contain the two files with the same name...
I don't know which of them we will end with - but it doesn't matter - we need both!

At first we have came with 3 options to solve this new problem:

1. Put the two DLLs into different sub folders under Bin (via post build script), and tell the application to probe those folders.
   
2. Install the DLLs into the GAC.
   This way they won't be copied into the Bin at all.
   
3. Add the DLL's version to their name (e.g. Infra-1.dll)

Each option has its pros and cons, and I won't go deeper into it.
Why bother selecting the less bad option if you can find a good one? (Thanks Pavel!)

 

ILMerge

This application knows to merge multiple .NET assemblies into a single assembly.

How would that help? See:

With the ILMerge solution, you can keep every thing normal (not changing Assemblies names, without the need for the GAC and without using complicated sub folders).

The only thing you need is to put post build event to do ILMerge on Project A & B.
Then reference the Merged DLLs from App1. Simple - isn't it? 

 

You can download ILMerge here

See those docs for description of the problem:

http://msdn2.microsoft.com/en-us/library/0z1t9z56(VS.80).aspx 
http://msdn2.microsoft.com/en-us/library/3b12we19(VS.80).aspx 

 

See next parts:

Part 2
Part 3

Was Never...

So in MSDN (How to: Add New Work Item Queries) it says you have an Operator called "Was Never":

But when you open the drop down list, you only see "Was Ever":

And if you try to write it by yourself, you get:

TF20032: The operator for row {0} is not recognized or missing

 

So, is it a bug, or am I missing something?

A Tour in Jerusalem

We had travel to Jerusalem this week.
By "we" I mean the employees in the company I work for.

(Tower of David)

 

I'm not a stranger to Jerusalem. I have been there countless times.
Nevertheless, you always find new things in this city.

It can be a Fish Stand in Mahane Yehuda Market:

Or an old Synagogue with error in the order of the Ten Commandments:
(See if you can spot it)

A new Museum (The Generation Center, near the Western Wall Tunnels)

Or just an interesting window (but you need to understand the background)

 

So, what should I add?

go and visit (or revisit) Jerusalem - The Holy City.

Or at least visit my Jerusalem Album on Flickr...

Problems that are fixed in the .NET Framework 2.0 Service Pack 1

At last!!!

Microsoft just published the so missed article (KB 945757):

Problems that are fixed in the .NET Framework 2.0 Service Pack 1

Thanks Memi for updating me on this.

 

If you compare it with the list I have supplied - you can see that are a lot more fixes in the SP1 than I have succeed to find (70 in my list vs. 161 in the SP1)

But there at least some hotfix in my list which haven't entered the SP1 (944100, 943598 and 943175 for example).

Probably those were fixed too late for entering Service Pack 1 - so if you need them fixed - ask for the specific hotfix.

 

So now - go read the full list - and decide if/when to deploy it.

Good luck.

Rosario: Business Objective, Feature and Requirement

Initial comment:

The following explanation is based on November Rosario CTP, and it is only my understanding of the product. Maybe I haven't got it right. Comments are welcome.

 

When you look at Rosario's CMMI work items, you meet some old and new types which used for Requirement Management:

• Business objective (new)
• Feature (new)
• Requirement

Now,  as far as I could see, the CMMI project site hasn't been updated yet with descriptions for the new work item types, so I will try to describe their roles by myself.

 

A little bit about Relations

Rosario presents different types of relations between work items.

Parent - Child
Fulfilled by - Fulfills
Predecessor - Successor
Tested by - Tests
Related - Related

Some work items defines what type of relation they should be part of.
See below for details.

 

Business Objective

As I understand, it should represent a objective which can be achieved in multiple ways. it doesn't come to describe what should be done, it comes to describe what should be achieved.

Relations:

It's possible to have a tree of BO (Business Objective), but it seems Microsoft doesn't mean you use it in that way (you can see it by the lack of "parent-Child" in its UI).
Its main use is with Feature in "Fulfilled by - Fulfills" relation.

Feature

Feature, in contrast with BO, describe what should be done, in different levels of abstraction.

Relations:

This work item suggested to be used in tree like "Parent-child" Hierarchy of Features. It can also take part in relation of "Fulfilled by - Fulfills" with Business Objectives.

Requirement

Features and Requirement are really similar, and the only difference I could point out is that while Feature has the "Fulfilling" connection to other items (probably for use with BO) Requirement doesn't. in fact, it doesn't have a built in UI for a "Parent-Child" relation either, so it seems Microsoft wants us to use it as the most detailed and low level item in "Requirement Management" before Task level.

 

to be continued...