This is a little off topic from .Net, but it can related back to .Net. The reason is that an Oracle database can be used for a .Net application.
Most of my work as been with .Net application and not much with Oracle databases writing DML or DDL scripts. When I saw a table in a database using a sequence number as the primary key, this caused a problem when I wrote script to insert a large number new rows into the table. Some how some of the primary key numbers were higher than the sequence number. This caused my insert script to error out because the sequence number was replicating some of the primary key (which as you may know just isn't going to work).
To solve this problem, I needed to bring the sequence number higher than the highest primary key number in the table, I was modifying. I did this by writing a P-SQL script with some assistance.
DECLARE
var NUMBER
BEGIN
FOR i IN 1... number greater than the sequence cache LOOP
SELECT sequence table.nextVal INTO var FROM sequence table name;
END LOOP;
END;
After I ran this script, I was able to replicate the rows I needed to replicate.
Sunday, December 9, 2012
Monday, October 15, 2012
FxCop "Do not catch general exception types"
I never gave much thought on proper ways on using Try Catches and projects where they just don't make to put them in. Until I started working on a legacy software application, this application has hundreds of thousand if not a million lines a of C# code. The client wanted the development team to upgrade the system's framework, clean up the code base, and add several new features. To help clean up the code base, one of the tools we used on this application was FxCop.
FxCop is Microsoft tool to help developers code to Microsoft's coding standards. A developer will point FxCop to .dll(s) within the solution. Then run the code in the .dll(s) through the rule sets in FxCop. Based on the rule sets, FxCop will display critical error(s), critical warning(s), error(s), and/or warning(s). After the all the code is ran through the rule sets, the developer can then select a rule violation. From there, the developed can find and fix the code that is causing the violation.
One rule violation that showed up through out the code base was a critical error. "Do Not Catch General Exceptions Types". One nice thing about FxCop is it provides detail on how to resolve the issue, and it gives a link to MSDN web library that relate to the problem. So I click on the link hoping to get a code example, MSDN didn't give a code example. It did however explain and go into more detail on what FxCop summary gave "You should not catch Exception or SystemException. Catching generic exception types can hide run-time problems from the library user, and can complicate debugging. You should catch only those exceptions that you can handle gracefully." Also, Fxcop gives a resolutions "Modify 'Method Name' to catch a more specific exception than 'type' or re-throw the exception."
After reading the messages FxCop provided and the MSDN page, I knew how the fix this violation. You can replace the general catch exception with a more specific one and or put a "throw" in the general catch exception to re-throw the exception. One problem with just putting a "throw" in the catch statement. The problem is execution of the code stops completely, and the application does not "crash gracefully".
Violates Rule:
public void Foo(int count)
{
try
{
count = 0;
countFoo(count);
}
catch(Exception ex)
{
LogError(ex.Message);
}
}
Or:
public void Foo(int count)
{
try
{
count = 0;
countFoo(count);
}
catch{}
}
Does not Violates Rule:
public void Foo(int count)
{
try
{
count = 5;
countFoo(count);
}
catch(ArguementException ex)
{
LogError(ex.Message);
}
}
Or:
public void Foo(int count)
{
try
{
count = 5;
countFoo(count);
}
catch(Exception ex)
{
LogError(ex.Message);
throw;
}
finally
{
Message.Write(count);
}
}
Or:
public void Foo(int count)
{
try
{
count = 5;
countFoo(count);
}
catch(ArguementException ex)
{
LogError(ex.Message);
}
catch(Exception ex)
{
LogError(ex.Message);
throw;
}
}
The "return" statement will wouldn't be reach if an exception is thrown and you can not wrap it in a "finally".
public int Foo(int count)
{
try
{
count = 5;
countFoo(count);
}
catch(Exception ex)
{
LogError(ex.Message);
throw;
}
finally
{
Message.Write(count);
}
return count;
}
Before you start throwing specific exceptions, throws, finally, or just completely removing the Try Catch all together, I would suggest looking about the code and what is happening within the method. Also, take a look at the caller method and how the application handles thrown exceptions.
Below is a references I used in this blog, and you can find out more details about use of Try Catches.
http://www.dotnetperls.com/exception
FxCop is Microsoft tool to help developers code to Microsoft's coding standards. A developer will point FxCop to .dll(s) within the solution. Then run the code in the .dll(s) through the rule sets in FxCop. Based on the rule sets, FxCop will display critical error(s), critical warning(s), error(s), and/or warning(s). After the all the code is ran through the rule sets, the developer can then select a rule violation. From there, the developed can find and fix the code that is causing the violation.
One rule violation that showed up through out the code base was a critical error. "Do Not Catch General Exceptions Types". One nice thing about FxCop is it provides detail on how to resolve the issue, and it gives a link to MSDN web library that relate to the problem. So I click on the link hoping to get a code example, MSDN didn't give a code example. It did however explain and go into more detail on what FxCop summary gave "You should not catch Exception or SystemException. Catching generic exception types can hide run-time problems from the library user, and can complicate debugging. You should catch only those exceptions that you can handle gracefully." Also, Fxcop gives a resolutions "Modify 'Method Name' to catch a more specific exception than 'type' or re-throw the exception."
After reading the messages FxCop provided and the MSDN page, I knew how the fix this violation. You can replace the general catch exception with a more specific one and or put a "throw" in the general catch exception to re-throw the exception. One problem with just putting a "throw" in the catch statement. The problem is execution of the code stops completely, and the application does not "crash gracefully".
Violates Rule:
public void Foo(int count)
{
try
{
count = 0;
countFoo(count);
}
catch(Exception ex)
{
LogError(ex.Message);
}
}
Or:
public void Foo(int count)
{
try
{
count = 0;
countFoo(count);
}
catch{}
}
Does not Violates Rule:
public void Foo(int count)
{
try
{
count = 5;
countFoo(count);
}
catch(ArguementException ex)
{
LogError(ex.Message);
}
}
Or:
public void Foo(int count)
{
try
{
count = 5;
countFoo(count);
}
catch(Exception ex)
{
LogError(ex.Message);
throw;
}
finally
{
Message.Write(count);
}
}
Or:
public void Foo(int count)
{
try
{
count = 5;
countFoo(count);
}
catch(ArguementException ex)
{
LogError(ex.Message);
}
catch(Exception ex)
{
LogError(ex.Message);
throw;
}
}
The "return" statement will wouldn't be reach if an exception is thrown and you can not wrap it in a "finally".
public int Foo(int count)
{
try
{
count = 5;
countFoo(count);
}
catch(Exception ex)
{
LogError(ex.Message);
throw;
}
finally
{
Message.Write(count);
}
return count;
}
Before you start throwing specific exceptions, throws, finally, or just completely removing the Try Catch all together, I would suggest looking about the code and what is happening within the method. Also, take a look at the caller method and how the application handles thrown exceptions.
Below is a references I used in this blog, and you can find out more details about use of Try Catches.
http://www.dotnetperls.com/exception
Saturday, October 6, 2012
Team Foundation Server 2010 Branch and Merge Fundamentals
Just like other source control tools out there like SVN, team foundation server is a tool where a team can create branches from a single trunk. In any source control tool, the goal of branching is to provide isolation between parallel streams of work. With that being said there are some best practices and question to apply towards branching.
Questions Before Creating branches
Before a person or team start creating branches, branches from branches, and etc, it is recommended to think of a design, There is no universal design to fit all projects, but there are some questions to ask . Is the main trunk used for testing release code or used for development? Are there several different teams all working on a different function of the application? Is the code isolated to a branch so a developer can make the appropriate modifications to the code. Then tested and code reviewed because those changes are introduced to the main trunk? Are there any need for branches? If there is only person working on the project, he or she may not want a create branch(es).
Tips on merging
Questions Before Creating branches
Before a person or team start creating branches, branches from branches, and etc, it is recommended to think of a design, There is no universal design to fit all projects, but there are some questions to ask . Is the main trunk used for testing release code or used for development? Are there several different teams all working on a different function of the application? Is the code isolated to a branch so a developer can make the appropriate modifications to the code. Then tested and code reviewed because those changes are introduced to the main trunk? Are there any need for branches? If there is only person working on the project, he or she may not want a create branch(es).
Creating multiple branches
In TFS 2010, a person can't merge one branch (A) to another branch (B) if branch (A) is not branch's (B) parent . However, a person can merge branch (A) to the trunk. Then a merge can be done to the other branch (B) with the changes that branch (A) had. Also, a person can create a "sub" trunk from another branch (A). They can do this by creating another branch (C) feeding off an already existing branch (A). When this is done, branch (A) is now the branch's (C) trunk, and branch (C) can't do a merge to the main trunk without first merge to branch (A). Another option is re-parent branch (C) by using the "reparent function" in TFS. By doing this, a person will make the main trunk the parent of branch (C). So branch (C) can directly merge changes into the main trunk and not worry about having to merge into branch (A) just to merge to the trunk.
In TFS 2010, a person can't merge one branch (A) to another branch (B) if branch (A) is not branch's (B) parent . However, a person can merge branch (A) to the trunk. Then a merge can be done to the other branch (B) with the changes that branch (A) had. Also, a person can create a "sub" trunk from another branch (A). They can do this by creating another branch (C) feeding off an already existing branch (A). When this is done, branch (A) is now the branch's (C) trunk, and branch (C) can't do a merge to the main trunk without first merge to branch (A). Another option is re-parent branch (C) by using the "reparent function" in TFS. By doing this, a person will make the main trunk the parent of branch (C). So branch (C) can directly merge changes into the main trunk and not worry about having to merge into branch (A) just to merge to the trunk.
To create a branch select the source to branch from and the folder/location to branch to. Then determine how and what code to move to the branch by selecting latest version or changeset.
Select a branch > File > Branching and Merging > Reparent...
Reparent Screen to select to a branch to make a parent
Sometime development in a branch may take a couple days to complete. During this time, other people probably committed their code in the main trunk. Before merging a branch into the trunk, it is best to get the latest version (GLV) from the trunk or the latest clean build of code, and perform a merge from the trunk to a branch. During this process, it will get changes from the trunk and copying them into your branch. This may cause some conflicts in code in which they can be resolved by using the TFS "merge tool" to resolve the conflict(s). Once all the conflict(s) has been resolved and the merge is complete, it would be best to compile the code to make sure the code builds without any errors, and a person can go a step further by running unit testes and/or do a "smoke test" on the application. If everything builds and works like it should, a person can merge the branch into the trunk. This way all the changes are added to the trunk without overwriting other people code. Also, this prevents a lot of merge conflicts in the trunk.One thing a person may want to consider doing is creating a label in the branch before performing a merge into it. By creating a label and setting it to last check-in done in the branch, a person can have a clear point where someone can perform a "rollback" to. This is just encase it is deemed necessary to do a "rollback" in the branch.
Best practices to follow
• Use meaningful branch names where applicable
• Always prefer Branching over “code-freeze”
• Integrate early and often to avoid “bing bang merge”
• Avoid cascading branches
• Preserve the physical integrity of the branch
• Isolate Change
• Isolate Work, not People
• Avoid baseless merges
Below are three references I used in this blog, and you can find out more details about branching and merging design and process using TFS 2010.
http://msdn.microsoft.com/en-us/magazine/gg598921.aspx
http://intovsts.files.wordpress.com/2010/06/techdays2010_branchingandmergingwithtfs2010.pdf
http://jamessdixon.wordpress.com/2010/12/14/tfs-branching-warning-lots-of-screen-shots/
Merging a trunk to a branch. Choose the source to merge from and select get latest version or a by selected changsets. Choose the target branch to merge to.
To create a label, come up with a meaningful name and put a descriptive comment of what the label is for. Then select a branch to be applied to and determine where to relate the label to: latest version or a specific changeset.
• Use meaningful branch names where applicable
• Always prefer Branching over “code-freeze”
• Integrate early and often to avoid “bing bang merge”
• Avoid cascading branches
• Preserve the physical integrity of the branch
• Isolate Change
• Isolate Work, not People
• Avoid baseless merges
Below are three references I used in this blog, and you can find out more details about branching and merging design and process using TFS 2010.
http://msdn.microsoft.com/en-us/magazine/gg598921.aspx
http://intovsts.files.wordpress.com/2010/06/techdays2010_branchingandmergingwithtfs2010.pdf
http://jamessdixon.wordpress.com/2010/12/14/tfs-branching-warning-lots-of-screen-shots/
Subscribe to:
Posts (Atom)