Newly built version of Prism throws a version error.

Topics: Prism v4 - WPF 4
Jan 21, 2013 at 9:04 PM

Hello all,

 

I had made some really cool changes to the framework which work great on my own machine.

I copied over the prism source to my work laptop and recompiled it there.

When I copy the updated Microsoft.Practices.Prism.dll file to the location used by our app,  and recompile the application that uses it, I get this error:

The type 'Microsoft.Practices.Prism.Modularity.InitializationMode' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Practices.Prism, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. 

The new dll is in the same location as the old one and I can double click it in the reference section and bring up the object explorer on it. It has the "initializationMode" property that says can't be found. The property sheet for this dll states it is version 4.0.0.0.

 

Any ideas why I can't drop this new dll in place?

Thanks.. this will be a huge help to the team when it works in this location!

Harold

Jan 22, 2013 at 12:28 AM

further note....

 

Looking at the properties for the Microsoft.Practices.Prism.dll file as originally distributed in the Prism download, it has a digital signature. The one I built with my custom changes does not have a signature. Would this throw the above error?

 

thanks

Harold


Developer
Jan 22, 2013 at 1:10 PM
Edited Jan 22, 2013 at 1:13 PM

Hi Harold,

I believe that this problem could be related to the use of strong names in Prism assemblies, as strong-named assemblies can only reference other strong-named assemblies. Hence this may be the cause of your DLL conflicts.

In other words, if you rebuild your Microsoft.Practices.Prism assembly and reference it in your application, other assemblies (e.g. Microsoft.Practices.Prism.UnityExtensions) which reference this assembly may cause a conflict.

As a quick test I believe you could try referencing all the the Prism assemblies required in your application and not only the Microsoft.Practices.Prism assembly , that were build from the PrismLibrary solution you modified, as using these new build assemblies altogether may not present this kind of errors.

Also, for more information on Strong-Named Assemblies you could check the following MSDN article mentioned in the Recommendations for Modifying the Prism Library section of the Prism documentation:

As a side note, you may check that the new assemblies are unblocked before referencing them in your application.

I hope this helps,

Agustin Adami
http://blogs.southworks.net/aadami

Jan 22, 2013 at 2:56 PM

Hey Agustin,

 

the weird part is I did strong name it and looked at using the IL Disassembler and it looks ok. but still same error. When I build it on my own Win 7 box I don't sign it and it works fine with the other dll's. When I build it on my work computer, it fails. My work laptop is really locked down.. while my own box everything is admin rights... does that matter?

My work project I want to use it on is huge and I don't want to go and modify all of the projects.. I should just be able to replace the existing Microsoft.Practices.Prism.dll file with my newly built one...

 

Thanks for your reply!

Harold

 

Developer
Jan 22, 2013 at 6:44 PM

Hi Harold,

Based on my understanding, what Agustin means is that you cannot use you own version of Microsoft.Practices.Prism.dll along side the original Prism assemblies, as Prism uses strong named assemblies, thus generating the exception you are mentioning. Hence, if you wish to use your custom version of Prism, you will need to rebuilt and replace ALL the Prism assemblies.

For doing so, when building your custom Prism solution, you will need to copy ALL of the following assemblies to the environment where your application is running:

  • Microsoft.Practices.Prism.dll
  • Microsoft.Practices.Prism.Interactivity.dll
  • Microsoft.Practices.Prism.UnityExtensions.dll (only required if you are using Unity)
  • Microsoft.Practices.Prism.MefExtensions.dll (only required if you are using MEF)

(As far as I know, you still should be able to use the original Microsoft.Practices.ServiceLocation.dll and Microsoft.Practices.Unity.dll assemblies without problems.)

Also, take into account that you will need to change all the references to the aforementioned assemblies in the application to point your custom versions, by manually removing and adding the references.

Regards,

Damian Cherubini
http://blogs.southworks.net/dcherubini

Jan 22, 2013 at 7:15 PM

ah ok.. gotcha.. .i'll try that.. i can see where that would make a difference... they all need to be in sync and come from the same build.

 

Thanks

Harold

Jan 23, 2013 at 8:28 PM

that did it Damian! Thanks very much, it was a huge help!

 

Harold