Archive for the ‘Usings’ Category

VB.NET ‘Type or Namespace cannot be found.’ after converting VS 2005 projects into VS 2008

October 23, 2009

I am converting some VB.NET projects from VS 2005 into VS 2008. I had converted the projects ‘Animals’ and ‘Food’, put them into a Solution, Zoo.sln, added a Project Reference for Food into the Animals project and compiled the Solution which duly compiled and ran.

Visual Studio 2008 Conversion Report Ambiguous
But, examining the Conversion Report for ‘Food’, I noticed that only the Food.vbproj file was marked as converted. The summary at the end of the log said:

Converted: 1 file.
Not Converted: 72 files.

This made me worried. Why were there 72 files Not Converted ? Had I actually converted Food properly ? Angst got the better of me, so I Unloaded and Removed Food from Zoo.sln, retrieved the source again from Visual Source Safe and reconverted the Project.

I got the same result: 1 file converted (just the vbproj) and 72 files with no status next to them (but no errors either) and a count of 72 ‘Not Converted’.

I Googled here and there and eventually found a forum post by the knowledgable Peter Bromberg which said that Class files (.vb and .cs) will not by touched by the VS 2005 to VS 2008 Conversion. That put me at ease. So then I re-added Food to Zoo.sln, added the Project Reference into Animals as before and recompiled.

This time 102 errors: Horrific memories of school examinations covered in red pen filled my mind.

All the errors said the same thing: ‘Type or Namespace xyz cannot be found. (Are you missing an Imports or Assembly Reference) ?‘ All the errors were in ‘Anmals’ referring to unknown types which I knew existed in ‘Food’.

Well, I checked the Project Properties for ‘Animals’ and the Reference to Food ws there and it was to the correct Food.dll. I removed the reference, recompiled Food and re-added the Reference. Still 102 errors. Things hadn’t looked this grim since the days I flunked MacroEconomics 2A with a score so low it had to be examined through a microscope.

Prodding The Corpse

Here was a typical line returning two unknown type errors on MonkeyDrink:
Dim fermentedCoconut As MonkeyDrink = New MonkeyDrink()

As an experiment I tried the following:
Dim fermentedCoconut As Food.MonkeyDrink = New Food.MonkeyDrink()

To my amazement, Food.MonkeyDrink appeared in Intellisense and resolved to a known type, reducing my error count. So Animals obviously had a valid Reference to Food. Why then the compile error ?

Now you’re probably thinking ‘the dolt has left out his Import statements in the class files’ but remember these projects were converted – they never had Imports statements in them in the first place, yet Animals had always compiled with Food before. WHY was it chucking a spaz now ? The pain, the pain, the journey of pain…

Unknown Feature #999

Checking again the References Tab in the Property Page for the Animals Project, I clicked on Food in the References list then scrolled further down and noticed for the first time a pick list of namespaces from all the Referenced projects: Lo and Behold, Food was not selected. Once I selected Food (thus telling the compiler to Import all the Namespaces from Food) and recompiled, my errors vanished with the silken ease of Master Ninjas after a successful assassination.

The miraculous feature I had discovered is the Visual Studio Imported Namespaces List which MSDN beautifully describes here

The Imported Namespaces List is only available in VB Projects (not C#), that’s why I had never seen it before.

So Now I Know

If your Types cannot be found in your VB.NET project but you know the containing project is referenced, or maybe you’re wondering why your Class files have absolutely NO Imports statements in them, have a look at the Imported Namespaces List in the Project Designer via Project Properties. It’s….how you say…verrrrry nice.

Advertisements

Unused usings

May 12, 2008

Having Obsessive-Compulsive tendencies, I spent some time stripping unused Usings from our .cs files, all 626 of them. Smug with my efforts, I then wondered if it had achieved anything useful, specifically if it had reduced the size of our generated dlls. I was a little dissapointed to discover that it had not but OTOH it seems that I probably improved the compile time of the app a little bit.

This post by Andrew Troelsen of the MSDN C# Team says that the C# compiler, csc.exe, ignores Usings and Assembly References not referenced in code, while under the Comments in the same post Anthony Ashe points out that the compiler still does a ‘copy local’ for unused assemblies leading to redundant crud lying around in your bin directories as well as your source code.

In addition to the above, as Patricia Shanahan points out, it is good practice to remove Unused Usings as inspection of your Usings helps to convey to maintainers of your code what your code is likely to do and affect.

Now, if you’ll excuse me, its time to Dettol the cat.