   [.net] CodeDom error: "metadata file ___ could not be found"
  I'm using CodeDom to compile a C# script at runtime. This is the part that adds the assemblies:cp.ReferencedAssemblies.Add("System.dll");cp.ReferencedAssemblies.Add("System.Data.dll");cp.ReferencedAssemblies.Add("System.Drawing.dll");cp.ReferencedAssemblies.Add("System.Windows.Forms.dll");cp.ReferencedAssemblies.Add("Microsoft.DirectX.dll");cp.ReferencedAssemblies.Add("Microsoft.DirectX.Direct3D.dll");// This is a custom DLLcp.ReferencedAssemblies.Add("MyCore.dll");Whenever I try to compile a script, I get the above error for the two DirectX assemblies and my custom DLL.After googling for a bit, I found a solution:cp.ReferencedAssemblies.Add(typeof(Microsoft.DirectX.Matrix).Assembly.Location);Doing that for the 3 assemblies solves the problem, but my question is, why don't I get this error for the first few assemblies? Is there a more "elegant" way to solve this?Thanks in advance.   
  My guess is that the MDX DLLs are old, and the CodeDOM is unable to determine how to load them. I'm not exactly sure why, but since MDX is officially deprecated, it would make sense that if any assemblies are to cause problems, it would be them. I'm not sure how deeply you are involved in your project, but I still need to ask: Why MDX? Using it is just asking for trouble if you ask me. Not only is Microsoft no longer updating it, but it has been known to cause problems, including the infamous LoaderLock problem. The only reason I would use MDX nowadays is if I already had a significant code base that depended upon it.   ;Quote:Why MDX?I'm not really doing anything serious with it. If I ever will, I'll probably switch to SlimDX.Quote:since MDX is officially deprecated, it would make sense that if any assemblies are to cause problems, it would be them.I doubt that's the reason. When I did the typeof trick, it worked just fine (and note that I also had this problem with my custom DLL), which tells me that the problem is that it can't locate the assemblies.It seems like the System.* assemblies are in a different location that the MDX ones. The System.* ones are obviously in the GAC, but I thought the MDX ones would be there too?It's also weird that it can't find my custom DLL. Both the application and the DLL are in the same solution, and the application has a dependency on the DLL, but I guess that doesn't mean that CodeDom knows where to look for it?I'm somewhat new to all this, so I thought I must be missing something obvious. While googling, I saw that some people had similar problems with their custom DLLs, and they were able to fix it by rebuilding their solution, but it didn't seem to work for me. How can I tell if my solution is being built properly? (and what does "properly" even mean?)   ;  This has interested me as well, so doing a quick little search of my own I came up with some interesting information. It seems that the ReferencedAssemblies don't automatically get searched for assemblies in the GAC. In fact, it doesn't seem to care about the GAC at all. The only reason it can find the framework assemblies without an exact path is because the framework folder is automatically added to the search path internally.That makes dealing with custom assemblies and non-framework assemblies a little more difficult. I'm not sure your solution is a bad one, but I found another snippet on the web that looks like it will do what you want.   ;  That solution also looks hackish, but at least it looks more robust than what I'm doing.My code is adopted from this tutorial and the author (that's RobTheBloke, BTW) doesn't mention anything about it. I wonder how he managed to avoid this problem...Thanks for your help. I suppose my googling skills could use some improvement... [smile]   