Visit msnbc.com for Breaking News, World News, and News about the Economy
In my last post, I showed how you could enable static code analysis for a visual studio project. However, you can also set up static code analysis at a more global level if you are using Team Foundation Server for source code control.
Within a Team Project, you can set up a check-in policy that requires the code to pass static code analysis. You can do this by simply right-clicking on the Team Project and selecting Source Control from the Team Project Settings.
From the Source Control Settings dialog, click on the Check-In Policy tab. and click the Add... button. (Note - I already have the Code Analysis policy set for my project in the image below.)
Click the Add... button to add a new check-in policy and select Code Analysis from the menu.
From here, you should be able set up the rules just as you would at the project level. Any rules you specify should generate an error when violated, and therefore, the code will not compile. As a result, the developers will not be able to check-in code that violates any of the rules that you have set for the team.
So, if you have already set up rules within your projects, another nice feature in Visual Studio is the ability to synch up your settings in each project with those set at the check-in policy level. You can do this by selecting the Replace with Check-in Policy under Analyze/Code Analysis Settings for Solution in Visual Studio.
All of the settings in your current projects will match those set at the Team Project level. None of your previous suppressions attributes should have been removed.
Hope this helps!
The static code analysis within Visual Studio is a great way of automating initial code review. In order to turn it on do the following.
1. Go to Properties within the particular project.
Code analysis can only be enabled at the project level, so the first step is to go to your properties section of each project you want enabled for code analysis.
2. Go to the Code Analysis tab.
3. At the top, check the box that "Enable Code Analysis on Build..."
4. On the right-hand side of the screen, check the box for those rules that you want treated as an error. (By default it is treated as a warning and will not stop the build process.)
Sometimes the rules may not make sense for projects where a lot of code is auto-generated. In this case, you could leave that rule as a warning in the project settings.
In other cases, you may want to suppress the errors for particular members of your types or for whole namespaces. This can be done by right-clicking on the rule violation in the Error List that appears when compiling your project and selecting a Suppress Message option.
As seen above, this can either be set within your source or in a project suppression file. You can learn more about this here.
Many of you may be familiar with the use of JSON (JavaScript Object Notation). It is a very tight syntax for expressing the state of an object and is very widely used in Web 2.0/AJAX style development in which objects are passed back and forth between the client using the XmlHttpRequest object out of band to eliminate the need to do a full page refresh.
I found a great article by Rick Strahl that outlines the pros/cons of two built-in .NET serializers: JavaScriptSerializer and DataContractJsonSerializer. You can read about them here.
After using both methods in my own application, I found that another con of the JavaScriptSerializer that is a pro for the DataContractJsonSerializer class is that it requires a public default, parameter-less constructor. This means that I cannot serialize objects that I also would like to make read-only, and therefore, requires a constructor with the properties defined up front.
One point I wanted to make in this post was that the extension class that Rick defines in his post for simplifying DataContractJsonSerializer usage does not work properly. In order to correct it, I added the 'this' keyword to the first parameter so that .NET recognized the static methods as extensions to the object type. In addition, I converted the FromJsonString() method to a generic FromJsonString<T>() method to allow the return object to be strongly typed.
Code is listed below, if you are interested.
How frustrating! I spent at least 15 minutes trying to figure out how to change the default browser for debugging to my preferred browser in Visual Studio 2008.
Apparently, with a normal ASP.NET application, you can just right-click on any .aspx file and select 'Browse With...' from the context menu. The dialog that opens (shown below) has the option to select a browser and click 'Set as Default' button.
Unfortunately, the .aspx files in ASP.NET MVC applications don't don't provide this option in the context menu. The only one that works is the Default.aspx file.
I found the answer from this helpful blog post. Thank you, Steve Bodnar!
My recommendation to Microsoft is to either put this setting in the Tools/Options menu, which seems to be the most natural place to look for this setting, or place it in the Properties of the Web Site/Application project - which might be even better if you want to specify this setting per project.
I am working on a current project where we are trying to create a site that gives visibility/transparency into our company and its performance whether good or bad. This is being done in order to build relationship with those we do business with. And it occurred to me how fundamental transparency really is in work and life.
Lately, I have noticed a lot of examples of people and processes that are geared to pursuing transparency. Regardless of what I think of President Obama's policies, I have to say that he has been fairly transparent with his decisions and agenda. And every time some corruption (financial industry, legislative pork) or misbehavior is mentioned, his solution tends to be creating some framework (site or process) for exposing those ills through transparency.
It also occurred to me that a lot of project management processes aid us in exposing the truth about projects. Risk management helps to expose potential issues that can ruin a project's timeline or budget. Issues lists keep track of potential flaws in a given system. And project post-mortems can help teams to learn from past mistakes and improve for future iterations.
Even rating systems within eBay and Amazon or content updates from Facebook can help to bring a level of transparency that build trust.
So, why should transparency be so important?
For one, transparency builds trust. If someone knows the truth about me, whether good or bad, they can begin to expect certain behaviors from me. They can trust that I am who I say I am, and there is no fear that I will change or that there is something they do not know about me.
All relationships grow from a root of trust. Without it, there is no basis for relationship. So, if I want to grow quality relationships with my family, friends, and colleagues, I have to nurture trust, and therefore transparency.
It also creates a level of accountability. If I am transparent about my life and work to myself and others, I am forced to face reality. And even though reality is not always pretty, it can allow me to choose to pursue change. Without it, I can safely live in denial and be complacent with the way things are. And worse, if I keep things a secret, those failures may grow worse. It was once said, "You are only as sick as your secrets."
The Bible concurs with these benefits saying that,
"If we say we have fellowship with him while we walk in darkness, we lie and do not practice the truth. 7 But if we walk in the light, as he is in the light, we have fellowship with one another, and the blood of Jesus his Son cleanses us from all sin." (1 John 1:6-7)
You cannot have fellowship (relationship) with others and grow in your life without a level of transparency.
So, I have decided that transparency or being transparent needs to be a core value for me. And this blog post is my first attempt at admitting that I need to work on it. I need to be willing to be honest to others about my life and work regardless of the consequences and be humble enough to apologize when I have failed or hurt someone. It's the only way to have the quality relationships and integrity I desire.
I was reviewing an interface for a WCF web service today, and I began wondering about web service naming conventions.
It is understood that a service should be a logical grouping of a set of functionality. Therefore, if you have several pieces of functionality that center around a Project concept, then you should group them together under the name ProjectService.
So, the convention for service names is:
When creating methods for a data service, though, should you restate the concept in the title? In this case, you would use the following methods: CreateProject(), UpdateProject(), GetProjectByID(). Isn't this already understood by the title of the web service? So that you could say Create(), Update(), and GetByID() instead.
I propose no.
The latter might make more sense in an object-oriented world where you are operating on the object itself. However, a service is more like a manager class that operates on Project objects. Also, theoretically speaking, each one of these functions can live on their own apart from any other functionality. So, specifying the concept in the title of each method would make sense. And finally, there might be functionality in this service for sub-objects such as Task that would not be substantial/independent enough to live on its own in a TaskService.
In that case, it would be important to understand which type of object your Create(), Update(), and GetByID() are operating on.
So, my recommendation for a data web service methods is:
What are your thoughts?
