none
Xaml Exception - Could not load file or assembly 'x' or one of its dependencies for C++ dll dependancy RRS feed

  • Question

  • I am trying to resolve a xaml exception: Could not load file or assembly 'x' or one of its dependencies.

    The problem is in a C# project that has a dependancy on a C++ dll the my xaml cannot reference.

    The problem is resolved if I add a path to the required dll to be system path, but this is not a solution I can use for a customer environment.

    I tried coping the required C++ dll to the assembly build directory using a link in the project so all of the required files are available in the output directory but this does not help.
     

    Since Xaml can find the dll in the system path, is there a way to tell the xaml to look in a additional paths to find dll references?

    Stack trace:
     Could not load file or assembly 'PKZipLib.dll' or one of its dependencies. The specified module could not be found. File name: 'PKZipLib.dll' at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.Assembly.Load(AssemblyName assemblyRef) at XamlStaticHelperNamespace._XamlStaticHelper.Load(String assemblyNameVal) in D:\Project$\XmasClassic\Dev\XMAS\Classic\DocProcessing\Src\DocProcessingWorker\Ringtail.Legal.DocProcessing.Activities.Containers\obj\Debug\_Ringtail.Legal.DocProcessing.Activities.Containers.g.cs:line 104 at XamlStaticHelperNamespace._XamlStaticHelper.LoadAssemblies() in D:\Project$\XmasClassic\Dev\XMAS\Classic\DocProcessing\Src\DocProcessingWorker\Ringtail.Legal.DocProcessing.Activities.Containers\obj\Debug\_Ringtail.Legal.DocProcessing.Activities.Containers.g.cs:line 56 at XamlStaticHelperNamespace._XamlStaticHelper.get_AssemblyList() in D:\Project$\XmasClassic\Dev\XMAS\Classic\DocProcessing\Src\DocProcessingWorker\Ringtail.Legal.DocProcessing.Activities.Containers\obj\Debug\_Ringtail.Legal.DocProcessing.Activities.Containers.g.cs:line 43 at XamlStaticHelperNamespace

    Monday, January 24, 2011 8:17 PM

Answers

  • For #3 above it appears I need to install the 2010 VC++ runtime on my Server 2003 machine.

    Guess the only outstand question on the item is the problem described in #2 above.

    Let me know if anyone knows an answer to this item, otherwise thanks to all the replied with suggestions.

    • Marked as answer by rsimmons1000 Thursday, January 27, 2011 6:36 PM
    Thursday, January 27, 2011 6:36 PM

All replies

  • Have you tried using the AppDomain.CurrentDomain.AssemblyResolve event?
    Tuesday, January 25, 2011 7:52 AM
  • Nope have not heard of that...I will research.

    Is it something I can use to have the xaml designer look for dlls in an additional path?

    Tuesday, January 25, 2011 4:08 PM
  • I think you are right to try to avoid placing your C++ dll in the system directory.

    A couple of questions:

    -does calling Assembly.Load() and passing in the assembly name of your C++ dll work? (It is a .net assembly done in C++/CLR, is that right?)

    -is your C# project the .exe file that you are running, or does it get hosted in some other assembly (as a plugin or whatever)? Does AppDomain.CurrentDomain.BaseDirectory point to the directory you placed your C++ dll in?

    -does your C++ dll depend on additional DLLs? They may need to be placed in the directory along side of it.

    -is the output directory actually going to be the right directory for .net to find your dll? If your code in the C# project is running inside a process something.exe, normally Assembly.Load() will be able to automatically find any assembly in the same directory as the something.exe.

    For more information, this may be a good reference from MSDN: "How the runtime locates assemblies"
    Tim

    Wednesday, January 26, 2011 3:55 AM
    Moderator
  • First of all, thanks for replying Tim.  Regarding the questions:

    -does calling Assembly.Load() and passing in the assembly name of your C++ dll work? (It is a .net assembly done in C++/CLR, is that right?)

    > No the C++ is not a managed C++ assembly.  It is a third party unmanaged C++ assembly...

    -is your C# project the .exe file that you are running, or does it get hosted in some other assembly (as a plugin or whatever)? Does AppDomain.CurrentDomain.BaseDirectory point to the directory you placed your C++ dll in?

    > Yes the C# project is running in a different executable.  Yes, the dlls the the project dll depends upon are located there.

    -does your C++ dll depend on additional DLLs? They may need to be placed in the directory along side of it.

    > No, that dll is the only dependancy other than a couple system dlls.  I was working with a coworker that ran dumpdll(?) to check for other dependacies...  If I add a deploymentItem attribute to my MS unit tests, they will run successfully  e.g. [DeploymentItem(@"pkarchive85u.dll")]

    -is the output directory actually going to be the right directory for .net to find your dll? If your code in the C# project is running inside a process something.exe, normally Assembly.Load() will be able to automatically find any assembly in the same directory as the something.exe.

    >C# does not drag my unmanaged C++ dll to the output directory so I am using links and build events to insure the dlls are copied to the correct locations.

    For more information, this may be a good reference from MSDN: "How the runtime locates assemblies"
    Tim

    >P.S. In the stack trace above you can see that the xaml object directory and temporary g.cs files are involved...  Containers.g.cs:line 104 at XamlStaticHelperNamespace._XamlStaticHelper.LoadAssemblies().  I am currently rewriting my xaml WF activities as .cs code because I am really stumped on what else to do.

       

    Wednesday, January 26, 2011 6:23 PM
  • > No, that dll is the only dependancy other than a couple system dlls.  I was working with a coworker that ran dumpdll(?) to check for other dependacies...  If I add a deploymentItem attribute to my MS unit tests, they will run successfully  e.g. [DeploymentItem(@"pkarchive85u.dll")]

    Hmmm... I'm a little confused about this now, is this scenario actually failing only when you run unit tests? Or it passes when you run unit tests, but fails in some other scenario?

    (I know MSTest deploys all your files to a special folder which is different from your regular build output folder, is that the cause of the problem?)

    Also, I don't know the dumpdll tool you mean, but if you do have a scenario where your XAML does load successfully, you could just attach a debugger and look at all the loaded modules to verify that you have the list of all the dependencies. (Or look at the dll load events listed in the debug output)

    Wednesday, January 26, 2011 7:41 PM
    Moderator
  • I think I am dealing with 3 problems all with the error: Could not load file or assembly 'x' or one of its dependencies

    1. Tests pass when I run tests if I add the deploymentItem attribute or if I add the path to the dlls in question to the system path.  So adding the deploymentItem attribute copies the dlls to the MSTest "shadow directory" which solved my problem for MSTest.

    2. The Xaml designer fails with the error when it references the my assembly that has the C++ dll dependancy.  The workflow would still run however and the designer worked if I added the C++ dlls in question to a directory in the system path which is not the best option.  (Never figured this out  and am still looking for ways to tell the WF xaml designer to look in additional paths for my unmanaged  C++ dlls.  Worked around the problem by rewriting some of the designer xaml as .cs.  Not really a solution but is preventing designer view errors.)

    3. Now I am running my workflow created with VS2010 on a 2003 Serer machine and am getting the same error.   Ran dumpbin (not dumpdll) to see there was a dependancy on the VS2010 dll MSVCR100D.dll that is not on the 2003 server machine (sigh).  I see others on the web have had this issue.  I am currently going down a path to research this. 

    Hope this makes sense.  Any clues are appreciated.

    Thursday, January 27, 2011 3:39 PM
  • For #3 above it appears I need to install the 2010 VC++ runtime on my Server 2003 machine.

    Guess the only outstand question on the item is the problem described in #2 above.

    Let me know if anyone knows an answer to this item, otherwise thanks to all the replied with suggestions.

    • Marked as answer by rsimmons1000 Thursday, January 27, 2011 6:36 PM
    Thursday, January 27, 2011 6:36 PM