Guy kolbis

Here is a problem I encountered while working with Visual Studio 2005 and 2008....

The last time this happened to me was while working on TFS custom control. So in order to create a custom control, we must add the assembly we have created and a wicc file to the following folder:

"C:\Documents and Settings\All Users\Application Data\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\9.0"

This is the path where TFS (Team Explorer) will look at when using custom controls.

When I deployed a new version of the custom control to that location I suddenly started receiving the InvalidCastException telling me that it was:

"Unable to cast object of type 'x' to object of type 'x'"

So, what happened here? The common sense tells us that this should be a version issue.

What did I find out?

If you attach to a running instance of VS2005/8 and check what Modules are loaded (you may need to add the Modules window command from the Debug category in Tools --> Customize...) you'll probably see two versions of your assembly are loaded, or even the same version of the assembly loaded twice: in both cases you'll see the same error message.

Why does it happen?

The IDE uses cache to store the assemblies for its projects. The IDE caches versions of assemblies in the following folder:

"x\Documents and Settings\user\Local Settings\Application Data\Microsoft\VisualStudio\8.0\ProjectAssemblies"

And at least in my case doesn't detect the particular assembly containing the type has a new version and it doesn't update the cache.

How do I solve it?

So first step, delete all folders in ProjectAssemblies. Next, make sure the IDE can only find ONE copy of your assembly, which is easier if you only have one copy of the DLL in your disk, and only one reference to it (or exactly the same reference from all projects) in your solution.

Here is a small utility that will help you convert a *.ResX file to *.Resource file:

void GenerateResources(string source, string target)
{
    ResXResourceReader reader = new ResXResourceReader(source);
    IDictionaryEnumerator iterator = reader.GetEnumerator();

    // Define a resource writer for writing resource files 
    IResourceWriter writer = new ResourceWriter(target);

    while (iterator.MoveNext())
    {
        writer.AddResource(iterator.Key.ToString().PadRight(10, ' '), iterator.Value);
    }

    writer.Generate();

    reader.Close();
    writer.Close();
}

Where the source is the ResX file name and the target is the Resource file name.

I have a customer that wants to built a client application, the application should support composition, add-ins type development (each developer or team to concentrate on their area of expertise), smart parts UI controls and several other typical client requirements.

Being Microsoft oriented person, I considered using the CAB (composite application block). I had to make a design decision whether I will go that road or not.

CAB

The Composite UI Application Block facilitates the design and implementation of your client applications in three areas:

• It allows your application to be based on the concept of modules or plug-ins.
• It allows developers with shell expertise to build components that hide user interface complexity from the business logic development.
• It facilitates development using patterns for loose coupling between modules.

Sounds good! Right?

Facts

• Neither  the developers know or used CAB.
• Developers are 6/10 knowledge in .NET 3.5 and 7-8/10 in .NET 2.0
• Time limit for infrastructures: 14 days!!!
• My Team was not yet assembled and only few of the developers were available.

Process

So, Microsoft recommends that before deciding to use CAB, we first must analyze whether this application block if it is suitable for your particular needs. To evaluate this application block and determine its applicability to your projects, it is suggested that you dedicate at least half of a day to explore the application block. The following is a suggested evaluation approach:

1. Download the code and documentation in the language of your preference.
2. Install the Composite UI Application Block and compile it.
3. Read the "Introduction" and "Scenarios and Goals" sections of the documentation.
4. Compile and run the QuickStart samples.
5. Start with the "Walkthrough - Designing and Building a CAB Application" QuickStart and read the related documentation.
6. If the application block looks like a good fit for your application, and for an in-depth, quick immersion on the code, follow the instructions on the Hands-on-Lab training content.

Making a decision

It took me one day to achieve all that and make it "work". The impression I got was that this is a great tool and can suite my needs functionality speaking. However before making the decision I need to understand whether this works for me budget wise. Remembering the time limit and the dev team, I seek for an advise on the overhead in time limit to for training and infrastructure development. The result was that it should take around 7 days for my developers to "Get Started" and have a good knowledge in CAB not to mentioned the fact that not all my team was assembled yet. Considering this I stood at a dilemma. From one had functionality speaking I wanted to use CAB, but on the other hand project wise, I had no time to spare for training my team.

Result

For this customer under the facts I have mentioned, we have decided not choosing CAB.

QA

If there are any thoughts on the issue and the selection, I would love to hear them.

For those of you who ever wrote a web service (I guess most of you have), sharing types was an impossible mission. If you had defined a type in the server side (the web service side), when consuming it on the client side, the proxy generated for you contained the same type but under a different namespace. Do you know that problem?!

When WCF shipped, a new possibilities emerged. One can now share types and reuse them.

In order to do so, all you need to do is get into the "Configure Service Reference.."

Now verify that the "Reuse types in all referenced assemblies" is checked.

By default it will be checked!

The only issue with this mechanism is the fact that Data Contracts (Interfaces) are not being shared! I do not know what is the reason, but in order to overcome this "Bug", you have to manually delete the contract from the generated proxy and replace it with the shared contarct.

When it comes to creating a .NET project, whether this is a class library, windows application or any other project type, you must give it a name. If we will look at the project options we will see that the name we gave applies to both the assembly name and the default namespace. For example if I created a project by the name of Core, the result will be as follows:

Now, for each item that I will add to the project under the root will get the default namespace, for example if I add a new item Class1, its namespace will be Core and its full qualified name will be Core.Class1.

When I usually create a project I use a template that create 3 folders in the project root:

1. Configurations - contains all the general configurations for the project and the solution, for example a link to GlobalAssemblyInfo.cs.
2. Resources - Images, strings and etc.
3. Src - This is the container for all the sources (the code goes here).

When using this template I feel more in control over the project logic, flow and structure.

However, when going this road, I struggle a bit with the namespaces. Let me explain... For each item I will add to the Src folder, its namespace will be Core.Src and its full qualified name will be Core.Src.Class1, thus when users will use my code, they will have to specify the using to Core.Src.

In order to avoid it, I manually delete for each item I add to the project the Src extension. This works out for me because I have high discipline, however when it comes to my dev team, this is not something I can count on.

As for now, I have to perform code review and verify the namespaces.

How would you handle this situation? Do you have any tips of your own?