views:

88

answers:

3

For downloading and installing .NET/dll, all I need is copying the dll to a specific directory, and let the .NET know about it. Is this correct?

I use mono, so with mono, I set the MONO_PATH to include the directory. And, it looks OK.

Here are my questions.

  1. With some libraries, not only dll file, but also xml file is provided. For example, I downloaded for System.Data.SQLite, and I have System.Data.SQLite.dll/xml. What's the purpose of this xml file? Do I have to copy this file also?
  2. For windows system, the .net dll is just like the other dll in terms of calling this dll. Is this correct? I mean, can I just copy the dll in a directory, and making the directory as a part of PATH environment enable the .NET finding the dll.
+1  A: 
  1. The XML file is used by your IDE to provide the Intellisense documentation.
  2. On Windows, copying a .NET assembly to a folder on the path does not seem to allow the executable to find the DLL.
Mark Rushakoff
Really? I thought it used reflection to build up the Intellisense?
Nate Bross
@Nate: There *might* be a compile-time option to include this information in the assembly... But I've had to rebuild assemblies from source, intentionally generating XML documentation, to get Intellisense working with said assemblies that I have downloaded, on more than one occasion.
Mark Rushakoff
Without the XML file, you should still get code completion, but no docs.
mhutch
+1  A: 

To answer your two questions:

  1. You do not need the XML file - it is only used for intellisense.
  2. Yes, the dll location follows the same rules as any other .NET dll. It needs to either be in the application folder (or bin folder for web applications/services) or installed in the GAC.
Oded
+1  A: 
  1. The XML is for the IDE intellisense (as others have said). It is not necessary.
  2. The ability to locate a DLL by setting a path variable, only works for native code on Windows systems. For managed / .net code, the rules of .net fusion are followed. A little over-simplified, the managed DLL must be one of: (a) in the same directory as the executable, (b) strong-named and in a location reachable by an app.config codebase attribute, or (c) in the GAC.
Brent Arias