Debugging frequently encountered configuration problems

Just took over the development of a new module today, the content is not complex, is the development code of batch.

Trying to debug the existing code, it doesn't make sense to run. This situation has not been done twice in development. Still, it's a headache, and sometimes it takes hours or even one or two days to figure out why. Of course ten is the problem of configuration above. And it took me 2 hours to find the root of the problem.

Here is a brief description of the problems and processes encountered today.

Premise: The new database is typically used in newly developed situations.

The entire batch is divided into 3 parts, GUI (screen display), BL (business logic), DB (data access). Separated from the gui,bl,db three, is the normal code architecture. Links between the three if it is simple, you can add a new project or class to the code directly in the special processing (dbconnutity). When it comes to DB data, configuration settings such as SQL Server, Database,connectiontimeout,alivetimeout,maxpool,minpool settings, etc. are unavoidable.

When the dbconnutitiy and batch are under the same solution, the problem is usually easier to find if the mode is faulty and the debug is tracked gradually. There are many systems that use dbconnutity as a common DLL (edited by other solution that we don't know). This time if we only have the encapsulated DLL file, we cannot drill deep into debug. There is no way to know exactly where the configuration file went wrong. This time only to try to find the way forward.

1. Analyze the exception: if the common DLL writes tightly, will do some basic catch and error parsing, through analysis can generally find the problem. Today, I encountered a failure to return error and generate log.

2. Configuration method: Usually the same large system, the various configuration methods will be consistent. For example, place the configuration file under the Conf folder in the root directory. Usually some, db.xml (Db.ini), Message.xml (Message.ini) and other similar files. With this reasoning, is there a problem with the config file used in the common DLL?

3. Investigate the published application environment: currently being used by customers of the system, the natural variety of configuration is currently relatively correct (of course there are many novice is not allowed to contact the client's host), can be used as a reference. The first reaction, of course, is to look at some of the properties of folders like Common,tool,config. (If it is web development, sometimes it is necessary to look at some of the files under JS)

4. Consult an old colleague: one project is best, and no one can ask other project teams or other old employees. Environment configuration problems are often a common problem that other developers are likely to encounter. Even if have not met, open up the idea to give yourself a new idea, nature is a good thing.

Today, after the discovery of the problem, the first time to modify the Xxx/bin/config under the Db.ini file (because the database name changed, subconsciously here must be modified), and then try to run again or the same problem. Then look at the common DLL path under the reference, and also under Xxx/bin/, the first step is to anticipate that this is not a configuration problem. Some wondered, the project group on 2 people, I and a customer system maintenance personnel, asked to maintain the old comrade, he saw is the development environment, a moment also give good suggestions, put forward let me look at the release of the application environment, because the VPN chain to pick up the host, account permissions problem too troublesome, I asked him to common DLL code. After you find the code, after you edit it separately, copy the generated common DDL to the batch to be executed, and then step through the debugging.

Finally to the Dbconnectinit method when the error, spare a lap or configuration problems. has been changed, that is the wrong place. Look closely at the environment the current batch is compiled under the release environment, and I modify the config file in the debug directory. Executed again, successfully passed, solved the problem. But there is another reason for this problem:. csproj.user files are often modified without saving to the code manager.

<?xml version= "1.0" encoding= "Utf-8"?>
<project toolsversion= "4.0" xmlns= "http://schemas.microsoft.com/developer/msbuild/2003" >
<propertygroup condition= "' $ (Configuration) |$ (Platform) ' = = 'Debug| AnyCPU ' ">
<StartArguments>5372662</StartArguments>
</PropertyGroup>
</Project>

Wisdom is the knowledge that accumulates and collates. This sentence deserves a daily aftertaste.

Debugging frequently encountered configuration problems