Use Visual Studio Conditional Compilation to manage development environment diversities

Large enterprise solutions may have different parts and each part may need different development/deployment environment. For example a project may have a part to work with third party web service. Now not all developers are interested for codes works with that web service. For faster/smooth development, developers who are not working with that web service may not want to interact with the service. Every time a developer run/debug the code and if the web service is invoked (which may kill time) then it’ll be annoying for developers who don’t work with that part of the code. So how we can fix this problem where people who are working with web service will invoke web service whereas people who are not working with web service will not invoke web service?

 

1. Create a new Configuration

In Visual Studio(VS) you can create custom configuration beyond DEBUG and RELEASE. Right click on the Solution in VS and click Configuration. In this configuration window select ‘New’ in the dropdown under ‘Active Solution Configuration:’. You’ll be prompted with the following window.

 

Figure 1: Create Custom Configuration from Configuration Manager.

Now enter a meaningful name for the configuration and select the base configuration (DEBUG or RELEASE).

 

2. Create Conditional Compilation Symbol for the configuration

Make sure that the new configuration is selected for the solution. To make sure this open ‘Configuration Manager’ by right clicking on the solution. The following figure shows that the custom configuration is selected for the solution.

Figure 2: Select Custom Configuration from Configuration Manager

Now open the properties window of the project you want to work differently for this configuration. Select Build tab and enter a conditional symbol name (WSDEBUG_SYMBOL in the figure) as shown below:

Figure 3: Create a conditional symbol for custom configuration

FYI, here the conditional compilation symbol will be associated with configuration name. So this conditional symbol will be active only when you select that particular configuration under which the symbol created.

 

3. Use Conditional Compilation Symbol in code

Since conditional compilation symbol is associated with configuration name, whenever you’ll select any configuration any project/solution, any symbols defined in that project/solution will be active. Now code block which needs to be conditional compiled can be put in a condition below:

#if WSDEBUG_SYMBOL
     Console.WriteLine("This is WSDEBUG");
#else
     Console.WriteLine("This is not WSDEBUG");
#endif

In the above code block, if you select any configuration that has any conditional compilation symbol named “WSDEBUG_SYMBOL” defined then first condition will be executed either else condition will be executed. Now you can write your code inside custom compilation section. So all you need to do is to change your configuration from DEBUG to your custom one (as like WSDEBUG).

 

Conclusion

One nice thing about VS is that it doesn’t keep track of the project’s configuration, user selected for a project/solution, inside project or solution. Rather it keeps this information in a file named like “yourproject.csproj.FileListAbsolute.txt”. So as long as you don’t keep this file in source control,different user’s configuration for project/solution will be kept locally. So if developer dev1 change project or solution’s configuration to WSDEBUG, then no other developer’s local settings will be affected.

So the solution is now that if you need different settings than others then create your own configuration and conditional compilation symbol. Then use that symbol for conditional compiling. Since your project/solution preference is kept locally, every time you’ll open the solution you’ll find your custom configuration selected whereas other developers will be using their own configurations. So the final answer to the question I had asked at the top of the post is “developers who wants to work with web service may select their custom configuration to use whereas developers who don’t want to work with web service may use default DEBUG configuration”

codeproject

Path.Combine like support for URLs

.NET framework has Path.Combine for combining two paths into one. This is great one as we don’t need to care about if first path ends with slash (/) or not. Today I needed functionality to combine two Uri into one. I needed to combine URLs in different places so having a unified solution would be better. At first I searched for any combine method in Uri. No Luck! Then after googling I have come to the following code snippet.

        public static string CombineUrls(string absoluteUrl,string 
             relativeUrl)
        {
            Uri absoluteUri=new Uri(absoluteUrl);
            return new Uri(absoluteUri, relativeUrl).ToString();
        }

Here the absolute Url is converted to an Uri object. Then another new Uri object is created combining this absolute Uri and relative Url.

SharePoint: Parse Response XML from List.asmx

If you use SharePoint web service then the response of invocation of most of the methods will be in XML format. Sometimes you need to parse the XML to find the operation status. For example when you use List web service’s UpdateListItems for insert, update or delete operation the result of the operation will be returned in  xml.

To parse returned xml you need to know the namespaces of the XML. The following code snippet shows different namespaces used in the response XML.

XmlDocument document=new XmlDocument(); 
document.LoadXml(responseXml); 
var namespaceManager = new XmlNamespaceManager(document.NameTable); 

//sharepoint namespace 
namespaceManager.AddNamespace("sp", "http://schemas.microsoft.com/sharepoint/soap/"); 
//list item namespace 
namespaceManager.AddNamespace("z", "#RowsetSchema"); 
//picture library namespace 
namespaceManager.AddNamespace("s", "uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882"); 
//web part namespace 
namespaceManager.AddNamespace("dt", "uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"); 
//directory namespace 
namespaceManager.AddNamespace("rs", "urn:schemas-microsoft-com:rowset"); 

In the above code snippet you can see there are five namespaces defined. Once you have defined these namespaces you can select nodes of particular namespace as shown below. The following code snippet select all row nodes under z namespace (of the format <z:row>).

document.SelectNodes("//z:row", namespaceManager);

SharePoint Error: “Non-supported field type change. The field cannot be changed to the new type. Please check the new type and try again.”

I was getting the exception while I was working with SharePoint feature. I tried to figure out why I was getting the error. Then I found that while I was testing a feature I created a site column. Later I was working on another feature and in that feature I tried to create a list column with the same name.

So you may get this exception when you’ll try to create a list column with a name which is already used for any site column and these two have different data type.

Test Driven Development (TDD), Step by Step: Part 1

Introduction

So at first let’s ask ourselves what is Test Driven Development(TDD)?

“TDD is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and then refractor the code to pass the test”.

TDD is upside-down approach for non-TDD developers. What’s our natural approach to development is? We write code to implement a functionality in mind. Once we finish coding, we test then modify if error is found and test again. This cycle continues. This traditional non-TDD approach is shown below:

Image 1: Traditional Approach to Software Development.

 

On the other hand in TDD approach you write test first rather than production code. So in reality with TDD even if you don’t have a class OrderProcessSystem (considering you are working on a order processing system) you are writing test for making sure Order Processing System is working fine just taking for granted that the class OrderProcessingSystem exists. It might sound bizarre. But its the main point in TDD .You want your test to fail at this point. Then go create classes, add functionalities and make sure the test passes. The overall approach is “You write the tests first, watch them fail, and then start producing the code that will get them to pass”. I’ll show you this in details later in this series of post. The TDD approach is shown below in the following figure:

Image 2: TDD approach to software development.

Why TDD? What’s the problem with traditional approach?

Now you may ask hey man I am not using TDD but my development is going well. I‘m delivering product in time with quality and bla bla bla. To answer your question let me remind you first “No process in this world is the best in all cases”. Every process has its merits and demerits. Even if nowadays waterfall model is appropriate for some kind of systems. So my focus is not TDD is best over non-TDD approach. Rather TDD offers some sort of benefits that we can leverage:

1. Automated testing: Nowadays as system is getting bigger and complex people are moving to automated testing. Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system. Whereas human may left a test out mistakenly during testing process.

2. Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test the all systems that may be affected due to the modification which may be time-consuming. This may also left hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified the whole set of tests in the system is run to make sure existing tests are passed. This make sure that existing functionality is not broken.

3. Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to be failed. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).

4. manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increase the time to deliver the product from the build time. With TDD a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.

5. Alternative Documentation: Unit tests are kind of documentation to system. Each unit tests tell about a individual requirement to the module or system. For example the following test ensure that only a logged in user with proper balance can buy an item when the item exist in stock. This test reflects an user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance()
{
    LoginToTheSystem();
    SelectAnItemToBuy();
    MakeSureItemExsitsInStock();
    MakeSureUserHasBalanceToBuy();
    RunTheTransaction();

}

6. Better way to fix bugs: In TDD approach when QA finds a bug, developer first write a test that generate the bug (that is the test will fail due to this bug). Then developer modify code to make sure that the test is passed (i.e., the bug is fixed). This approach make sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.

7. Repetition of the same bug reduced: The way bug are fixed in TTD is described in point 6. With TDD once a bug is found its put under test. So every time you run the whole tests in the system the tests associated with the bug are run and make sure the bugs are not generated again.

Are you convinced with TDD?

May be reading the above section you have convinced that TDD is the best as it offers so may benefits. From my personal experience before introducing any new approach you need to know:

1) What’s skills, the new approach expect developers to have?

2) What’s the restriction/demerits of the approach?

3) Will this approach fit with your system or environment? How can you fit TDD in your team?

Lets answers these questions.

Skill set requirements: With TDD developer writes test first rather than code. Many developers find it difficult to follow this approach (and most of the time resist not to follow TDD) as they are used to write code first. Most of the time non-TDD developers don’t want to follow this “test first then write code” as this is upside-down way of developing to them. Also in TDD the whole dependency is on Test case. TDD considers that test is the right thing and we need to make sure the test passes. But what if the test itself is not correct or enough tests are not written to cover all aspect of the system. If your test doesn’t cover all aspects of the system then may be you are missing some parts of the system to test. This is the case with manual testing and we are using automated testing to make sure whole part of the system comes under test. So writing good test cases is important for making successful TDD system. But if you don’t start and practice writing tests you don’t know how to write good tests.

Restriction of TDD: TDD requires having good skills on writing test cases which cover all aspects of the system. But writing good test cases requires to introduce TDD and practice more and more to be expert in TDD. So initially after introducing TDD you may not get the full benefits of TDD until you have a good number of people in your team having good skill in writing TDD. Also TDD can’t cover all aspects of the system. For example you can’t test UI, multithreading etc. So even including TDD you need to have manual tester. Sometimes you need to maintain tests as well as code to make sure that tests reflect the system requirements. This is an extra overhead for TDD.

How to Introduce TDD in your team: Once you are convinced with TDD you’ll try to Introduce TDD in your team. But you need to be careful and need to consider the following aspects before introducing TDD.

• sometimes some good initiative fails due to the way initiative is taken or introduced. For example you are overwhelmed with TDD and then decided to force all members in your team to follow TDD. From my point of view this will introduce a catastrophic productivity loss of the whole team. First of all you need to consider that your team members need to be expert in TDD to get full benefit of TDD. So introduce TDD in a small scale. Ask 2/3 developer to follow TDD. Once they get used to TDD ask few others to join with them. This way after few months you will find that your whole team is following TDD.
• Sometimes you’ll find few members of your team are not interested in TDD.Don’t force them to follow TDD. Rather use TDD with others who are interested.If you can prove TDD is better then once the guy who resisted to follow TDD will come and follow TDD.
• Select proper time to introduce TDD in your team. For example you have production release next month and you have bunch of works to do. Introducing TDD at this stage will slow the productivity of the team down. So select time to introduce time when you have less work pressure and team is in relaxing mode to learn and practice new approach.

Misconceptions about TDD

Some people argue that TDD takes more time than non-TDD approach. This may be true when you are introduced TDD in your team and your team members don’t have expertise in TDD (i.e., how to write test cases). Remember in the long run your team members will be expert in TDD and you’ll get the full benefits of TDD.

May be the above argument will not satisfy you as you will argue that writing TDD will take time which we could save if we wouldn’t write test case. This is true that writing tests takes extra time but it also saves time from other ends. Without TDD you need to depend fully on manual testing. In non-TDD approach you use to run the code, debug to test or find bugs. So with non-TDD approach you spend most time on manual testing. Also with non-TDD approach reasonable time is spent with QA personal to test the system. But with TDD approach you spend more time to write test cases but less time to run-debug and also less time with manual testing. So My argument is that with TDD your testing time is finally reduced as developers don’t need to depend heavily on manual testing and as testing with QA personal is shortened.

codeproject

SharePoint 2010 Beta2: Tooltip bug or as designed?

I have installed SharePoint 2010 beta2 and found that the arrow image in breadcrumb has tooltip which is showing colon(:) as shown below. There should not be any tooltip for the arrow image. Not sure if this is bug or as designed.

Figure: Tooltip in breadcrumb showing colon (:)

SharePoint Solution: Removed solutions which have failed

Sometimes you may find that solutions have generated error during retraction . This may happen if the “Windows SharePoint Services Administration” service doesn’t run when you run the retract command with stsadm the retraction will fail. So when you visit the solution details page you will find that the deployment status is error and there’s no other operation to perform on the solution except “Back to Solutions” link.

Figure 1: Solution Failed to retract

Now you may consider that if you start the administration service then it’ll work. But it will not. So how will you change the solution status from error to some valid state? If you try the retract the solution from command line or delete the solution then you’ll find exception. Few points to remember before heading on how to fix this:

1. Remember the retraction will work only on deployed solution. Since the solution is not in deployed state so the retraction will not work.

2. You can’t delete the solution as an retraction process in progress.

3. Retraction of a solution is internally a deployment operation.

 

Solution

The first thing you need to do is to cancel the retraction operation. You can’t do it from sharepoitn central administration site. You need to do it from stsadm command line. First find all the solution in deployment state (as said before, retraction is also a kind of deployment). To find all the solutions in deployment state run the following command:

stsadm –o enumdeployments

This will show you all the solutions in deployment state. The output will be something like below

<Deployments Count="1">
   <Deployment JobId="5d0feb9a-4ca6-4e16-9fc0-8839960972f2">
      <Title>Windows SharePoint Services Solution Retraction for "deploymentpackage.wsp"</Title>
      <Type>Retraction</Type>
      <State>Failed</State>
      <File>deploymentpackage.wsp</File>
      <ServerType>Front-end Web server</ServerType>
      <Target>Global</Target>
   </Deployment>
</Deployments>

In the above output notice the jobid. This is the key we need to go with the solution. A job is created for retracting the solution and we have found the job id. All we need to do now to remove job. You can run the following stsadm command to remove a job for deployment/retraction.

stsadm -o canceldeployment -id 5d0feb9a-4ca6-4e16-9fc0-8839960972f2

When you run the command the deployment (retraction actually) will be canceled and if you run the enumdeployments again you’ll find that the deployment is canceled.Now if you go back to the central admin site you’ll find that the solution is in deployment status. Now before performing any other operation on the solution you need to start the “Windows SharePoint Services Administration” service either you’ll get the solution in error state again.

Let your application ask you to attach to a debugger rather than you do it manually

Sometimes you need to debug an application in a point where it’s difficult to attach debugger manually. For applications which you can’t run directly from Visual Studio (say windows service), you usually use attach process to visual studio to debug. So if you have a windows service running (with debug mode dlls) then you can attach the process to your visual studio to debug. But if your windows service has some code in the constructor that you need to debug then how would you debug the code? When you’ll attach the windows service the constructor code is already executed.
There a way in dot net to prompt to attach a debugger from the running application. If you write the following code in any place in your code then when the application will find this statement the application will prompt you to attach a debugger.

System.Diagnostics.Debugger.Break();

Then if you attach the application with visual studio with code (with correct build version) you’ll find yourself in debug mode. But remember that this statement needs to be removed from code before release build. This is because this statement will be compiled with code even with release build. To make sure you have not put that code accidentally in your release build you can put a preprocessor directive like below:

#if DEBUG
System.Diagnostics.Debugger.Break();
#endif