We ran across this this morning where a colleague was trying to load a module she had built from a DirectoryModuleCatalog into the shell of our Prism application. She was getting an error that the module could not be loaded, an error which included "An attempt was made to load a program with an incorrect format." We stripped the module down to the bare bones, but still were getting the error. In fact, when we tried debugging, the debugger never even got into the constructor of the module.
A little research suggested that maybe the Unity dlls being referenced were different, which wouldn't surprise me since VisualStudio seems to go out and add whatever dll might be registered that it thinks fits the bill when you load up a project that another developer had started. After checking and re-checking the references for both the shell and module projects, we determined that probably wasn't it.
Then I found a bit about the build configuration. Her plugin was being built with an X86 target platform and the shell was being built for 'Any CPU' on her x64 machine. Voila. She went into Properties > Build for the Module project and changed the target to x64 (interestingly Any CPU was not available, which is maybe another issue), and the module loads into the shell as expected.
A little research suggested that maybe the Unity dlls being referenced were different, which wouldn't surprise me since VisualStudio seems to go out and add whatever dll might be registered that it thinks fits the bill when you load up a project that another developer had started. After checking and re-checking the references for both the shell and module projects, we determined that probably wasn't it.
Then I found a bit about the build configuration. Her plugin was being built with an X86 target platform and the shell was being built for 'Any CPU' on her x64 machine. Voila. She went into Properties > Build for the Module project and changed the target to x64 (interestingly Any CPU was not available, which is maybe another issue), and the module loads into the shell as expected.
No comments:
Post a Comment