Splitting and deployment of WEB projects

Some content reference from: http://dev.csdn.net/article/21/21714.shtm
The process is as follows:
1. Create a solution folder demo
2. Create a blank solution demo
3. Create a new Web root application Program Project http: // localhost: 8040
4. Create a virtual directory for the Web application http: // localhost: 8040/modules and delete the Web. config and Global. asax
5. Create a virtual directory for the Web application http: // localhost: 8040/controls to delete the Web. config and Global. asax
6. create a blank folder under the solution Folder: build, and create the bin folder under it. After compilation, We will compile all aspx, ascx, and web in the Web root application project. config and global. copy the asax file to build and copy the DLL file to bin.
In addition, the web virtual directory application created above will be automatically marked as an application by Vs, which is unnecessary. We can delete it in IIS (which is to delete the application)

After the above steps, we can split a web project into a root project and several sub-module projects. However, the problem also arises, that is, the deployment problem, how can we quickly copy the aspx, ascx, and DLL files in each project to the final build folder to maintain its structure?
We can use. net post-generation events, which I found when studying the Cuyahoga project, are difficult to deploy because the web project does not have post-generated events and pre-generated events, the solution of Cuyahoga is to modify the definition file of the web project *. csproj: Change the project type from web to local, and delete. net automatically generated *. csproj. webinfo file, and then open the project separately,. net will recognize it as a local project rather than a web project, and,. net will also generate *. csproj. finally, open the solution definition file, change the address of the web project from http to the path relative to the solution definition file, and so on, after changing all the web project files, open the solution and you will find that the web project has changed to a local project. When the entire solution is handed over to the customer, even if the customer does not create a web application in the unique way of a web project, the client can open and compile the application. Another purpose of Cuyahoga is to automate the deployment, cuyahoga is a modular project, with ascx appearing in modules. If web projects are used, these web modules cannot be automatically copied to the deployment target folder, you can copy the generated event.
(Note in the above operation that after you change the web project to local, delete it immediately *. csproj. webinfo file. At the same time, do not rush to open the total solution file. Otherwise, an error message is prompted. You should open the project separately and exit directly, in this case, Vs will automatically generate *. csproj. the user file, and then open the total solution file to modify the corresponding path of the Project)

At first, I thought Cuyahoga had the best solution, but later, I found that opening his solution, if you want to add a user control module by yourself, this module has been changed to local, so. net does not allow you to create webform-related files.

Further research found that, in fact, web projects can also have pre-generated events and post-generated events, but,. net will not display them. Therefore, we do not need to convert the web module project to local, or use the generated events to deploy the module to the final release folder. The method is as follows:
1. Open the folder of the web module project and find the project definition file.
2. Open the project definition file and copy the following content to the postbuildeven value. The content of this attribute is the generated event command:
Copy *. DLL $ (solutiondir) Build \ bin/Y & # XD; & # XA; if not exist $ (solutiondir) Build \ $ (projectname) MD $ (solutiondir) build \ $ (projectname) & # XD; & # XA; del $ (solutiondir) Build \ $ (projectname )\*. aspx & # XD; & # XA; copy $ (projectdir )*. aspx $ (solutiondir) Build \ $ (projectname)
The preceding Command needs to be explained as follows:
Copy *. dll $ (solutiondir) Build \ bin/y
This command is used to copy all. DLL files in the project folder to the build \ bin folder of the solution folder (macro $ (solutiondir). If the file exists, it will be overwritten automatically.
& # XD; & # XA;
These two characters are linefeeds In the event generated by vs. net. They must be added after each command line
If not exist $ (solutiondir) Build \ $ (projectname) MD $ (solutiondir) Build \ $ (projectname)
This command is used to create a folder for the project in the build directory. The if command is used. Macro $ (projectname) indicates the project name. For example, if the project name is controls, the target Folder does not contain controls, the folder is automatically created.
Del $ (solutiondir) Build \ $ (projectname) \ *. aspx
This command deletes the aspx file under the project folder in the target folder to keep the project folder clean.
Copy $ (projectdir) *. aspx $ (solutiondir) Build \ $ (projectname)
Finally, the above Command copies all aspx files in the project folder to the project folder in the target folder.

Note that some macros used above, such as the path generated by $ (projectdir) itself with the end \ separator. Therefore, you do not need to add \

Each web module project can use the post-generated events to deploy the project. Of course, I have not copied the ascx above.
After compilation, the build folder has a correct structure and only contains the content of the files required for website running.

This is my experience. The following is an example site: Click to download
To run this example, set up your site http: // localhost: 8040, point to the demo folder and post it in the bodhi tree reading (780) Comments (3) edit favorites to 365key category: Reading Notes