Isn't Microsoft.Common.Targets just related to the IDE build process?
But don't see much info about it except this :http://msdn.microsoft.com/en-us/library/ms164312(VS.80).aspx
(Usual UT bracket problem with the link)

>Your referenced DLL probably also has a reference to Microsoft.Common.Targets, so I'm betting that you don't have a reference to that in your new project. Add it and you should be good...
>
>~~Bonnie
>
>
>
>>>>>>Hi again,
>>>>>>
>>>>>>Well, another newbie question.
>>>>>>
>>>>>>I have a vb file containing a class definition. I what to be able to use the same vb file is different solutions. But when I reference an existing vb file in a location outside the project, VS makes a copy of the original and passes it in the current project folder. Hence, I now of two copies of the file. Now when I modify one of the copies, I have make sure I update all the other copies.
>>>>>>
>>>>>>Is there a way to have a central repository of shared files that all project share?
>>>>>
>>>>>Can you build your generic classes into dll and reference this dll in your projects?
>>>>
>>>>I thought about do that, but felt the classes were small enough that they didn't require becoming DLLs.
>>>
>>>Naomi's right - put them in a separate project.
>>>Having lots of little DLL's in .NET is no big deal. Takes a while to start thinking that way but remember these aren't the same animal as COM DLLs.
>>
>>I am beginning to see this. Coming from the world of COM, it is abit of a learning curve to stop think as if the .Net DLL class are COM-like.
>>
>>I built the common class into it's ouw DLL. Then added a reference from another application to the common DLL. When I build the application, i receive a whole lot of error refering "Microsoft.Common.Targets". I sure it has something to do with the reference i just added. But what?
>>
>>Do I need to copy the DLL to the working project folder. I rather mantain a single copy that other project only reference. Having to copy the DLLs around is as defeative as having the copy the VB file.