views:

1094

answers:

2

Does anyone have a good resource on dlls and how they are used / generated in Visual Studio? A few questions I'm rather hazy on specifically are:

  • How refresh files work
  • How dll version numbers are generated
  • The difference between adding a reference by project vs browsing for the specific dll

Any other tips are welcome as well.

+3  A: 

See the question on DLL information for some background.

Version numbers for unmanaged DLLs are stored in the DLL's rc file, same as for an exe. For managed DLLs I believe it uses AssemblyFileInfo attribute, usually in AssemblyInfo.cs for a Visual Studio generated project:

[assembly: AssemblyFileVersion("1.0.0.0")]

If you add the reference by project then VS will be able to copy the correct flavour (debug/release) of the referenced assembly to your output directory. It can also use this information to implicitly add a dependency between the projects so it builds then in the right order.

Rob Walker
+5  A: 

.NET DLL's

The general term for a .NET DLL is an assembly. They are a single atomic unit of deployment and consist of one or more CLR 'modules' (for most developers usually just one unless they are combining compiler output from two or more languages for example). Assemblies contain both CIL code and CLR metadata such as the assembly manifest.

.refresh Files

.refresh files are simply text files that tell VS where to check for new builds of referenced dll's. They are used in file based web projects where there isn't a project file to store this info.

Version Numbers

.NET Assembly version numbers are generated by an assembly scoped attribute AssemblyVersion which is usually found in a source file named 'AssemblyInfo.cs' (found under a project folder named 'Properties' from VS2005 onwards). Version numbers are comprised of major.minor.build.revision, for example -

[assembly: AssemblyVersion("1.0.0.0")]

AssemblyVersion is used as part of an assembly's identity (i.e. in its strong name) and plays an important role in the binding process and during version policy decisions.

For example if I had two assemblies of the same name in the GAC then the AssemblyVersion attribute would differentiate them for the purposes of loading a specific version of the assembly.

AssemblyVersion number can be fixed and incremented manually or you can allow the compiler to generate the build and revision numbers for you by specifying:

[assembly: AssemblyVersion("1.0.*")] - generates build and revision number
[assembly: AssemblyVersion("1.0.0.*")] - generates revision number

If the AssemblyVersion attribute is not present then the version number default to '0.0.0.0'.

The value of the AssemblyVersion attribute becomes part of an assembly's manifest, the AssemblyFileVersion attribute value does not.

The AssemblyFileVersion attribute is used to embed a Win32 file version into the DLL. If this is not present then AssemblyVersion is used. It has no bearing on how the .NET assembly loader/resolver chooses which version of an assembly to load.

Project References vs Browsing For DLL

If you're adding a project reference it means that the referenced project will be part of your solution. This makes debugging simpler by being able to step directly into your referenced project's code. If you only add a dll reference then you don't have the benefits of the project being part of the solution and being able to step into the code within the solution.

Kev