>>>Hi,
>>>
>>>I just dusted off a WPF project I'd been working on using Prism/Unity. It was still on Prism 2 so I decided to upgrade to v4. There were a couple of changes to the namespaces used and the DLLs where they resided (details here:http://msdn.microsoft.com/en-us/library/gg430859(v=pandp.40).aspx). I refactored all the namespaces and changed to referenced DLLs. All seems fine except for *one* problem:
>>>
>>>I have a simple class defined thus:

public class ILLObjectDeletedEvent : Microsoft.Practices.Prism.Events.CompositePresentationEvent<DeleteInfo> { }

When this is referenced I get an exception:
>>>"Could not load file or assembly 'Microsoft.Practices.Composite.Presentation, Version=2.0.1.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified." so it is obviously still trying to resolve this using the v2 version of Prism (even though the namespace explicitly implies v4 - there was no such namespace in v2) I cannot find why this is so.
>>>
>>>Also - An oddity: the solution contains two potential startup apps. One give this exception but the other does not.
>>>
>>>Any suggestions of what I might try to track down the root of this problem ?
>>
>>That is weird...
>>
>>FYI, it looks like ServiceLocator and Unity are still V2 are you missing a reference?
>>
>>Is it only that one error being thrown, or are there others?
>
>Got it working but the cause is still a mystery to me.
>
>The class in question was the only one in its assembly that referenced anything in Prism so I was not getting any other errors.
>The simplify the problem I by-passed a lot of intermediate code and attempted to create an instance of the class directly in the OnStartup() of both WPF applications.
>In the application producing the error the line would not compile - it was already looking for the Practices.Composite. Presentation dll. Looking in the .csproj files revealed that, whilst the working app was referencing the assembly directly as a project within the solution, the failing app was referencing the DLL itself in that projects bin/debug folder.
>I removed the reference and added it back as a project reference - and it worked.
>I removed it again and replaced the reference to point to the DLL as before - and it *still* worked.
>
>'Copy local' was true for the DLL reference so I don't know why the failing application was presumably still trying to use a DLL created prior to the upgrade to Prism v4? And I still don't know of a simple way of tracking down this type of problem......
>
>Anyway, I wasted the best part of a day on this ; it's a beautiful sunny morning and I'm taking the rest of the day off !!!

I've seen things like that happen, and they are a royal pain when they do. Glad you got it.