Mobile Project Development notes (experience in managing DLL files under different solutions for mutual reference)

When a project is large, management of DLL files is particularly important. For example, multiple solutions can be referenced between different projects, if the referenced paths all point to the DLL files under a project bin, the DLL is very poorly maintained. So how can we better manage these DLL files in this case? This is the case for the recent China Mobile project. There are three solutions in the project, multiple projects under each solution, and different projects of each solution are referenced. In addition, some external COM components are referenced. When the code of a Project changes, it is often necessary to consider whether the DLL file referenced by other projects has been updated, in this case, when a bug occurs, it is difficult to determine whether it is a dll version update problem. In addition, such DLL file management is not only troublesome, but also may cause an inexplicable problem caused by incorrect DLL file versions.

At present, this project has reached the final stage and has been reconstructed. Therefore, we have organized the DLL file management of the project and shared some new experiences with our friends. I also learned how to use the post-build event Command Line event (post-build event). I feel that using post-build event command line is a way to manage DLL. I personally feel that this method is more practical. I would like to share it with my friends for reference and hope they can provide valuable comments.

Summary: when multiple solutions reference the DLL relationship with each other, you can create a referencelib folder in a unified manner. All projects reference external DLL (non-local solution) all references under the referencelib folder, which stores all the DLL files for other compiled solutions. Once the external DLL is referenced, the path will be displayed in the reference area of the project, different projects under the same solution can be referenced directly.

The problem is that when there is an update under the project, what if I copy the updated DLL file from the project to the referencelib folder dedicated to DLL file management? That is to say, when the project is compiled, the copy operation is executed, so that the post-build event command line post-event compilation event is used.

When compiling a project, copy the DLL to the specified folder to facilitate timely reference of the new DLL. Write commands in Build Events -----> post build event command line

Syntax: Copy "Path 1" "Path 2"

Note: Path 1 indicates the path to be copied from, which is equivalent to "from"

Path 2 indicates where the file is copied, which is equivalent to ""

The following are examples of how to understand the syntax format.

Copy "$ (solutiondir) Configuration \ *. xml" C: \ charleschen"

Copy "$ (solutiondir) Configuration \ *. Configuration" C: \ charleschen"

Copy "$ (solutiondir) Configuration \ *. config" "C: \ charleschen"

Copy "$ (solutiondir) Configuration \ icon \ *. config" "C: \ charleschen"
Copy "$ (solutiondir) .." reference \ database. config "" C: \ charleschen"

Copy "$ (solutiondir) .." reference \ images \ open.gif "" C: \ charleschen"

Note:

1. $ (solutiondir) indicates the solution. "$ (solutiondir) configuration" contains the file configuration.

2. "*. xml" indicates the file with the suffix "XML.

3. "$ (solutiondir) .. \ reference \" indicates that there is a file reference at the same level as the solution.

Copy "$ (projectdir) bin \ debug \*. * "" $ (projectdir ).. \ references: Copies all files in the bin \ debug folder under the current project directory to the references folder at the same level as the current project.

 

The above uses "$ (solutiondir)" to represent the path, which is automatically recognized by. Of course, it's not just this one. You can see other predefined path Representation Methods in msdn: For details, see msdn. Here I copy it:

For more information, see msdn: http://msdn.microsoft.com/zh-cn/library/42x5kfw4 (vs.80). aspx

Macro description
$ (Configurationname)
Name of the current project configuration (for example, "Debug | any CPU ").
 
$ (Outdir)
Path of the output file directory, relative to the project directory. This is resolved to the value of the "output directory" attribute. It includes the Backslash "\" at the end.
 
$ (Devenvdir)
The installation directory of Visual Studio 2005 (defined as the drive + path), including the Backslash "\" at the end.
 
$ (Platformname)
The name of the current target platform. For example, "anycpu ".
 
$ (Projectdir)
Project directory (defined as drive + path), including the Backslash "\" at the end.
 
$ (Projectpath)
The absolute path name of the project (defined as drive + path + basic name + file extension ).
 
$ (Projectname)
The basic name of the project.
 
$ (Projectfilename)
Project File Name (defined as basic name + file extension ).
 
$ (Projectext)
The file extension of the project. It includes "." Before the file extension.
 
$ (Solutiondir)
Solution directory (defined as drive + path); including the Backslash "\" at the end.
 
$ (Solutionpath)
The absolute path name of the solution (defined as drive + path + basic name + file extension ).
 
$ (Solutionname)
The basic name of the solution.
 
$ (Solutionfilename)
Solution file name (defined as basic name + file extension ).
 
$ (Solutionext)
The file extension of the solution. It includes "." Before the file extension.
 
$ (Targetdir)
Directory of the generated primary output file (defined as drive + path ). It includes the Backslash "\" at the end.
 
$ (Targetpath)
The absolute path name of the generated primary output file (defined as drive + path + basic name + file extension ).
 
$ (Targetname)
The basic name of the generated primary output file.
 
$ (Targetfilename)
Name of the generated primary output file (defined as the basic name + file extension ).
 
$ (Targetext)
The file extension of the generated primary output file. It includes "." Before the file extension.