There are multiple methods to reference a class library in VS. The most commonly used method is to select the project tab when referencing to reference the class library project under this solution and select the Browse tab to directly reference the class library DLL file, in fact, these two references are slightly different. Today we will summarize them for everyone.
C # local project (console, winform)
- When you reference a class library project, any modifications to the referenced DLL class library will take effect immediately. You do not need to save or generate a class library. If you delete a class library project, the DLL referenced in this project is also deleted.
- Reference the class library DLL. In this case, the modification to the class library must be made into a class library project, and the regeneration cost project will take effect. If you delete or change the directory of the class library DLL, the reference in this project will point to the DLL generated under the bin \ debug directory of this project (but only after you delete or change the directory of the class library DLL, do not refresh the cost solution immediately, because the principle of recreating a solution is different from that of generating a solution, when the solution is regenerated, VS clears the originally generated DLL class library file in the bin \ debug directory of the project, that is, the solution is cleared first, and the cost solution is regenerated, at this time, the bin \ debug directory of this project does not contain the originally generated DLL class library file. Of course, an error will be reported when a solution is generated. You must build a solution or run this project, in this case, the reference in this project will point to the original DLL class library file in the bin \ debug directory of this project, and save the new reference information to the project file, then you re-generate the Solution VS will not delete the previously generated DLL class library file in the bin \ debug directory, however, if the DLL class library references other class library projects (that is, the indirect reference relationship between this project and these other class library projects), see the appendix Add content), then re-generate the solution for this project, VS will still Delete the DLL files of other class library projects referenced by the DLL class library file under the bin \ debug directory, therefore, if the DLL class library referenced in this project calls the code in these other class libraries, an error may occur. Therefore, do not delete or change the directory of the DLL class library file referenced in the project ). However, if you restore the library DLL to the original directory, the reference in this project will point to the library DLL.
- In either of the preceding methods, you must copy the properties of the referenced DLL file to a local directory. Otherwise, an error is returned when you run the project.
ASP. NET Web applications
- When you reference a class library project, any modifications to the referenced DLL class library will take effect immediately. You do not need to save or generate a class library. If you delete a class library project, the DLL referenced in this project is also deleted.
- Reference the class library DLL. In this case, the modification to the class library must be made into a class library project, and the regeneration cost project will take effect. If you delete or change the directory of the class library DLL, the reference in this project will point to the DLL generated under the bin directory of this project (but only after you delete or change the directory of the class library DLL, do not refresh the cost solution immediately, because the principle of recreating a solution is different from that of generating a solution, when the solution is regenerated, VS clears the previously generated DLL class library file in the bin directory of the project, that is, the solution is cleared first and the cost solution is regenerated, at this time, the bin directory of this project does not contain the previously generated DLL class library file. Of course, an error will be reported when the solution is generated. You must generate a solution or run this project, in this case, the reference in this project will point to the original DLL class library file in the bin directory of this project, and save the new reference information to the project file, then you re-generate the Solution VS will not delete the original DLL class library file in the bin directory, however, if the DLL class library references other class library projects (that is, this project and these other class library projects are indirectly referenced. For details about indirect references, see the additional content below ), then, after the solution is regenerated for this project, VS will continue Delete the DLL files of other class library projects referenced by the DLL class library file in the in \ debug directory, therefore, if the DLL class library referenced in this project calls the code in these other class libraries, an error may occur. Therefore, do not delete or change the directory of the DLL class library file referenced in the project ). However, if you restore the library DLL to the original directory, the reference in this project will point to the library DLL.
- In either of the preceding methods, you must copy the properties of the referenced DLL file to a local directory. Otherwise, an error is returned when you run the project.
ASP. NET Website
- When you reference a class library project, any modifications to the referenced DLL class library will take effect immediately. You do not need to save or generate a class library. If you delete a class library project, the DLL referenced in this project is also deleted.
- Reference the class library DLL. In this case, the modification to the class library must be made into a class library project, and the regeneration cost website project will take effect. If you delete or change the directory of the class library DLL, the reference in this project will still point to the directory of the original DLL class library file (but ASP.. NET website is directed to the address of the DLL file through the refresh file), does not point to the DLL generated under the Bin directory of this project, but when the solution is generated for this project, A warning is generated to indicate that the original file of the referenced DLL class library project cannot be found. If you restore the DLL class library to the original directory, the warning will disappear. In addition. when the NET website project re-generates the solution, VS will not delete any files under the Bin directory of the project, so even if it deletes or changes the directory of the DLL class library file referenced by the project, because all DLL files in the Bin directory of this project are still present, all the code of this project can still be correctly run.
- DLL files referenced by the ASP. NET Website will be copied to the Bin directory of the website.
Additional content: Here is a small question about direct and indirect references in the class library reference chain.
First, let's talk about the reference chain. We all know that the class libraries in the C # project can also reference other class libraries. If there are three class libraries: LibA, LibB, and LibC, these three class libraries have reference relationships: LibA <-LibB <-LibC (where A <-B indicates that Class B references the DLL file generated by Class ), in this case, the three class libraries LibA <-LibB <-LibC are a reference chain (LibA is the reference chain header and LibC is the end of the reference chain ).
- Direct reference: direct reference indicates that the two class libraries are adjacent to each other in the reference chain, such as the preceding LibA, LibB, LibB, and LibC libraries.
- Indirect reference: indirect reference indicates that the positions of the two class libraries in the reference chain are not adjacent, such as the preceding LibA and LibC.
In the direct reference relationship of the reference chain, for example, LibA <-LibB, we all know that the Library Project LibB will generate the DLL file generated by the class library project LibA after it is generated, copy to the bin/Debug directory of the LibB project. In indirect references of a reference chain, for example, in LibA <-LibB <-LibC, after three class library projects in the reference chain are generated, the bin/Debug directory of LibC must contain LibB. DLL, because LibC and LibB are directly referenced, LibA must exist in the bin/Debug directory of LibB. DLL, because LibB and LibA are directly referenced. But the problem is, does the bin/Debug directory of LibC also have the DLL file LibA. DLL of the class library project that has an indirect reference relationship with it?
After many experiments, I found that when LibB of the class library project uses LibA members (that is, LibB not only references LibA DLL files, but also uses LibA DLL files, for example, you have called the LibA method and declared the class objects in LibA, but remember to use only using to import the namespace in LibA ), after the LibA <-LibB <-LibC file is generated, the LibA file is generated in the bin/Debug directory of the LibC file. DLL and LibB. DLL. However, if the LibB project does not use the LibA member of the class library project (that is, LibB only references LibA, but LibB does not use LibA at all ), the bin/Debug directory of the LibC class library project only contains LibB. DLL.
So you will find that VS is actually very smart when generating the reference chain, because when generating LibC in LibA <-LibB <-LibC, VS will check several DLL files in the bin/Debug directory generated by the LibB class library project that has a direct reference relationship with LibC. In this example, because LibA and LibB are directly referenced, so there must be two DLL files in LibB bin/Debug: LibA. DLL and LibB. DLL. Then, VS will check whether LibA. DLL is used in LibB. DLL. If VS is used, the LibA. DLL and LibB. DLL will be copied to the bin/Debug directory of LibC at the same time. If LibA. DLL is not used, VS considers LibA. DLL redundant and only copies LibB. DLL to the bin/Debug directory of LibC.
However, the above section is not absolute, because I found that if the LibC project at the end of the reference chain is changed to the Asp.net website or Asp.net application, the DLL file generation principle is different. net each project references a DLL file with its own set of generation rules. The above only discusses the generation rules of class library projects.
