I am working on a solution with 4 projects (abc.sdk, abc.data_base_, abc.tester, abc.vb)  All but abc.tester are used by other developers as an api/sdk for their projects.  abc.tester had an UserControl that used an ActiveX control(MapX from mapinfo).  Everything was working great until I needed to move it to abc.sdk for the other developers to use.  The first problem I encountered was that abc.sdk had a strong name and the Interop.MapXLib did not and the compiler complained. This was solved by creating a key file and placing the name in Wrapper Assembly Key File .  Now abc.sdk uses MapX but afo.sdk.tester still needed to use MapX's data structures.  So, it still needed a reference to MapX in abc.tester.  This is where a runtime problem occured that I have no idea how to solve.  First of all, it throws an exception: /////////////////////////////////////////////////////////////////// System.IO.FileLoadException: The located assembly's manifest definition with name 'Interop.MapXLib' does not match the assembly reference. File name: Interop.MapXLib ... Fusion log follows: === Pre-bind state information === LOG: DisplayName = Interop.MapXLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=64405c7f88cc397e  (Fully-specified) LOG: App_base_ = C:gkellyprojectsafosdkafo.sdk.testerbinDebug LOG: Initial PrivatePath = NULL Calling assembly : afo.sdk, Version=1.0.986.14974, Culture=neutral, PublicKeyToken=0c807bda6759890e. === LOG: Publisher policy file is not found. LOG: Host configuration file not found. LOG: Using machine configuration file from C:WINDOWSMicrosoft.NET_frame_workv1.0.3705configmachine.config. LOG: Post-policy reference: Interop.MapXLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=64405c7f88cc397e LOG: Attempting download of new URL file:///C:/gkelly/projects/afosdk/afo.sdk.tester/bin/Debug/Interop.MapXLib. DLL. WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN  string /////////////////////////////////////////////////////////////////// Anyway, here are the questions: 1.  Has anyone experienced this that recognizes the problem? 2.  If you have two projects that use the same ActiveX control (not the same instance).     Each have their own Wrapper?  Is this correct? 3.  Do they both need a strong name now?  The same strong name for the wrapper?  I don't understand. 4.  If no one has an answer, can someone just come shoot me and put me out of my misery gkelly

We had the same problem, and it's a massive pain in the ass.  First you need to understand the problem.  If you increment a strong named assembly's version number or you remove the strong name then dependant assemblies will fail.  This makes sense, otherwise someone could create an assembly that was named the same as yours, exposed the same methods as yours, then formatted the harddrive when a method was called. Here is what we did to solve the problem: - all our projects (dll/exe) use a strong name for security purposes - we do not allow the auto increment of version numbers, we change it manually whenever the solutions code changes - we created one solution that contains all of our other solutions - for each solution within the mega solution we then used the dependencies tool that is built into VS.Net to indicate what other solutions it is dependant on - then we build the entire solution The magic here is that the dependencies determine the order that the solutions are built in.  So when the process is complete every file is properly _link_ed to the latest version of the other files, no more manifest errors. The down side is that it makes hot fixing a file a little more difficult. I'm not sure whether or not simply avoiding versioning up the components would avoid the manifest error, never tried it.  Either way we like to version up as it helps us keep the world in order. HTH Cheers