Thursday, January 01, 2009
#
I opened my email this morning to discover that I received two awards. First of all, I was awarded 7th place in the Community Credit December 2008 contest. I wasn't able to log into Community Credit for months because my user name didn't appear to be working. However, last night I was determined to submit my points for the INETA Community Champion Program before the year ended, and that program links to the Community Credit program. I eventually figured out how to get my user name, then submitted everything I could remember from the past year. My prize? The Plug Mug!
More importantly, I was awarded MVP Visual C#! I am very honored to be recognized by the MVP program for my contributions to the development community over the past year. I hope to live up to the title and deliver even more for the community in 2009!
If you're not an MVP and haven't received "stupid prizes to smart people"; here's how you do it. Get involved. If you're reading this, you're likely already a software developer of some caliber. Join your local user group. If one doesn't exist, start one. Give presentations on something that interests you. Answer questions in forums. Blog about technology. Once you do this, you may even discover that the official awards given by organizations aren't the true awards. The true awards for being involved are the people you meet, the connections you make, and the personal growth you experience.
Wednesday, December 31, 2008
#
It's the end of the 2008, and I will be celebrating the new year with my wife and friends tonight. Although this is a time for fun, I feel it's important to look back and analyze what I've done and identify areas of improvement.
Here is what I have accomplished this year:
1) Ran Columbia Enterprise Developers Guild
2) Presented at 13 events.
It may not look like much, but doing all of that takes a good amount of energy. Running a user group is a constant process with many surprises that crop up each month. You have to email members about meetings, arrange speakers, arrange sponsors, and facilitate the meetings to ensure things run smoothly. Presenting requires a lot of preparation and travel to places like Miami or Boston on your own dime.
However, I feel like I could have done more. I didn't blog as much as I would have liked. I was off and on in the forums. I didn't write many book reviews. I didn't present in as many places as I could have. I didn't maintain my Community Credit account (costing me stupid prizes).
Although I don't make resolutions, I do want to look back at 2009 and be more amazed at my accomplishments than I am looking back at 2008. So, that is my personal goal this year: contribute more to the community than I did the year before. I want to blog more, present more, and answer more questions. Most importantly, I want to grow the developer community in Columbia, SC.
Sunday, December 21, 2008
#
We are currently in Performance testing with an enterprise solution made with .NET 2.0 and C#. For the record, it consumes several Java services and interfaces with a few other third party systems. When we first set up the performance site, we were using three load balanced web servers and three load-= balanced service servers using ssl between each hope. This turned out to cause a significant performance hit, and to get around it ssl was turned off between the service load balancer and the service servers. The load balancer is hardware based and can handle the certificate itself.
Unfortunately, this caused a little problem:
Microsoft.Web.Services3.Addressing.AddressingFault: Destination Unreachable ---> System.Exception: WSE846: The <wsa:To> header must match the actor URI value of the web service. The actor URI value can be explicitly specified using SoapActorAttribute on the ASMX class. In the absence of the attribute, the actor URI is assumed to be equal to the HTTP Request Url of the incoming message. The <To> header received contained "https://application.myuri.com/SecurityService.asmx" while the receiver is expecting "http://application.myuri.com/SecurityService.asmx".
It appears that the load balancer doesn't handle the <wsa:To> header which causes the application to fail. Since the application is deployed to multiple environments and the services could possibly be consumed by other applications, the solution is to assign the following attribute to every service: [SoapActor("*")].
Sunday, November 30, 2008
#
I've been struggling through a Team Foundation Server 2008 install with Sql Server 2008 over the weekend. It seems to be having an especially hard time with the SQL Server Reporting Services. After analyzing a few things, I determined that the configuration tool was having an issue due to some prior installations of software. The report urls were pointing to a SQL Express directory.
I went about setting up the virtual directories manually. This required setting up an application pool, and I assigned my service user to run the pool. After I did that, I had to grant the user write access to the RSTempFiles folder. Then I received an error when browsing the site, "the path is not a legal form."
I couldn't find a site anywhere with a solution, though there was a dead thread on the old msdn forums with the same problem with SRSS. Since the tubes held no hope for me, I had to resort to old fashioned troubleshotting.
If you receive this error, you need to add your application pool user to the SQLServerReportServerUser (followed by $servername$instancename) group. It's that simple, but the error doesn't indicate what is necessary to fix it.
Tuesday, November 18, 2008
#
In a recent post, Deepak describes how to generate enums using Linq to Sql and SqlMetal.
1. Generate dbml using SqlMetal.
2. Find reference columns in the dbml that will be used as enums in code. Change their type to the enum name.
3. Generate code using SqlMetal.
I find this pretty interesting, but there would need to be some kind of conventions or configuration to denote which tables will be used as enumerations in the code. I think the way to tackle this is to create a custom msbuild task that will replace the enums for you based on either an item group or an xml property. This whole thing could be wrapped up in msbuild and applied in a separate proj file or in the AfterBuild or BeforeBuild target of one of the projects.
Wednesday, November 05, 2008
#
Microsoft has released Enterprise Library 4.1. It is a service release and includes the following:
-
Unity interception mechanism and integration of the Policy Injection Application Block with the Unity Application Block
-
Added support for generics in the Unity Application Block
-
Added support for arrays in the Unity Application Block
-
Performance improvements
-
Usability improvements to the configuration tool
-
Visual Studio 2008 Service Pack 1 support
-
Bug fixes
Monday, October 27, 2008
#
I just learned that Windows Azure has been announced, presumably at PDC 2008. It's brand new, so visit the site to learn more and download the ctp.
Windows Azure is a cloud services operating system that serves as the development, service hosting, and service management environment for the Azure Services Platform. Windows Azure provides developers with on-demand compute and storage to host and manage web applications on the internet through Microsoft data centers.
Between this and Live Mesh, I feel as though we're in the middle of a huge paradigm shift.
Thursday, October 09, 2008
#
I've seen a few questions in the forums where the poster wants the build to fail for certain projects but not others. This can be accomplished through metadata and item batching.
Here is the item group that defines the projects.
<ItemGroup>
<Projects Include="$(MSBuildProjectDirectory)\DataAccess\DataAccess.csproj">
<Group>Build</Group>
<Title>Data Access</Title>
<Description>Data Access Layer</Description>
<ContinueOnError>False</ContinueOnError>
</Projects>
<Projects Include="$(MSBuildProjectDirectory)\Business\Business.csproj">
<Group>Build</Group>
<Title>Business</Title>
<Description>Business Layer</Description>
<ContinueOnError>False</ContinueOnError>
</Projects>
<Projects Include="$(MSBuildProjectDirectory)\NonCritical\NonCritical.csproj">
<Group>Build</Group>
<Title>NonCritical</Title>
<Description>A Non Critical Project</Description>
<ContinueOnError>True</ContinueOnError>
</Projects>
<Projects Include="$(MSBuildProjectDirectory)\Presentation\Presentation.csproj">
<Group>Build</Group>
<Title>Presentation</Title>
<Description>Presentation Layer</Description>
<ContinueOnError>False</ContinueOnError>
</Projects>
</ItemGroup>
Here is the call to the MSBuild task.
<MSBuild Projects="@(Projects)" ContinueOnError="%(ContinueOnError)" />
Since ContinueOnError is defined as metadata for the Projects items, you can access it in a batching scenario by using the % symbol. When assigned to the ContinueOnError attribute, it evaluates the text contained within the metadata, in this case True or False. One side effect of this is that all of the ContinueOnError=False projects will be executed before the True projects.
I don't like this approach, because I consider a compilation failure a failed build. However, this should help you out if you're faced with a scenario where this functionality is required.
Wednesday, October 08, 2008
#
Mike Fourie has begun a project to combine two of the larger MSBuild task libraries. FreeToDev and SDC tasks have a lot of overlap, so I believe the MSBuild Extension Pack is a great endeavor to simplify the life of many of us build architects. However, I do have a gripe after reading the description on the project page.
It implements a TaskAction based design which improves usability and maintenance whilst reducing the code base, e.g. to start or stop a website, typically two task files would be created to perform each task, whereas the pack accomplishes this in a single task files using TaskAction=”Stop” and TaskAction=”Start”.
I feel that a "TaskAction based design" decreases cohesion. Each task should be like a method: the name describes what it does and the attributes are the parameters to do it. If you start coding tasks that change behavior, then you've effectively given the class (remember, tasks are classes) too much responsibility. If multiple tasks have similar responsibilities, the correct approach is to abstract. Create a base class with the common elements, encapsulate what varies, then implement that variation in the child classes which are represented in MSBuild as tasks.
In the example given on the project page, I would prefer to have <Website.Start ... /> and <Website.Stop ... /> than <Website TaskAction="Start" ... /> and <Website TaskAction="Stop" ... />
Lou Vega will be presenting at the Columbia Enterprise Developers Guild tonight. The topic is "A Closer Look at Windows Mobile – Using SMS and State & Notifications Broker." Systemtec is sponsoring the event and will be providing food from Moe's.
Visit the website for more information.
Tuesday, October 07, 2008
#
This is one that belongs on failblog. I happen to be using Visual Studio 2005 at work, so the prop snippet generates a private member variable to encapsulate in a property. In this case, I needed the property "Value". Guess what happens?
private string value;
public string Value
{
get { return value; }
set { value = value; }
}
Fail. The only thing that needs to be done to correct this is to qualify value in the setter.
set { this.value = value; }
There's no reason to make a better prop snippet now that it generates automatic properties in Visual Studio 2008. This problem merely amused me.
Monday, October 06, 2008
#
MSBuild files are loaded and parsed in order. This means that properties and items are in scope if they have been previously defined anywhere within the load chain. Here's an example.
Test.proj
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<HelloWorld>Hello World!</HelloWorld>
</PropertyGroup>
<ItemGroup>
<Files Include="*.*"/>
</ItemGroup>
<Import Project="Test.properties" />
<Target Name="Build">
<Message Text="$(GotHere)" />
<Message Text="$(FileList)" />
</Target>
</Project>
Test.properties
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<GotHere>Got here, $(HelloWorld)</GotHere>
<FileList>@(Files)</FileList>
</PropertyGroup>
</Project>
When you run MSBuild test.proj, you will receive the following output.
Got here, Hello World!
Test.proj;Test.properties
If you were to move the Import task above the property and item definitions, your results will be different as the HelloWorld property and the Files item collection have not been defined.
This concept is important if you are attempting to break a large build file into smaller files. There may be dependencies between common properties & items and conditional properties & items. Conditional properties and items can be refactored out of the primary script (encapsulate what varies) and still use the common properties and items as long as they are defined before the conditional file is imported.
Wednesday, October 01, 2008
#
What do you do when you are loading hundreds of objects and it's taking too long? When you instantiate the object in a vacuum, it runs very fast. However, you run a few tests and determine a collection on the object causes a bottleneck if a call to load the collection occurs many times in succession.
public class Customer
{
private List<Account> accounts = SlowLoadMethod();
public IList<Account> Accounts
{
get{ return accounts; }
}
...
}
If the property doesn't need to be accessed immediately upon instantiation, we can use a technique called lazy loading. This means the data isn't loaded into the member variable and the call to the slow method will not occur until the first time the property is accessed. This is easy to accomplish via a conditional check inside the property's get accessor.
public class Customer
{
private List<Account> accounts;
public IList<Account> Accounts
{
get
{
if (accounts == null)
{
accounts = SlowLoadMethod();
}
return accounts;
}
}
...
}
In this example, the accounts private member is null until the first time someone accesses the Accounts property. At that point, the accounts private member is assigned a value from the SlowLoadMethod. Subsequent accesses to the Accounts property skip this step and returns the field as usual.
Tuesday, September 30, 2008
#
You're writing a Customer class, and the Customer class contains a collection of Account objects. Because you want to add and remove accounts with ease, you implement this collection as a List<T>.
public class Customer
{
private List<Account> accounts = new List<Account>();
public List<Account> Accounts
{
get { return accounts; }
}
}
Life is good. Your tests iterate through the accounts, add new accounts, and remove accounts. However, when you run FxCop, it complains that you shouldn't expose generic lists.
Do not expose List<T> in object models. Use Collection<T>, ReadOnlyCollection<T> or KeyedCollection<K,V> instead. List<T> is meant to be used from implementation, not in object model API. List<T> is optimized for performance at the cost of long term versioning. For example, if you return List<T> to the client code, you will not ever be able to receive notifications when client code modifies the collection.
FxCop is correct in its assessment as it becomes more difficult to later add underlying functionality. But I feel that it leaves out an important point. You shouldn't expose too much about your implementation, and this relays to the world that Employee uses a List<T>. Consumers of the Customer class don't care that you've implemented List<T>, they only care about the interface. Expose the public property as the interface the consumer should be using. In this example, our consumers want to utilize the interface IList<T>. Refactoring this is pretty easy: modify the property to be IList<Account>.
public class Customer
{
private List<Account> accounts = new List<Account>();
public IList<Account> Accounts
{
get { return accounts; }
}
}
In other cases, the consumers may only want to iterate the collection without making modifications. In that situation, expose the list as IEnumerable<T>. The point is to take into account the interface that consumers want to utilize, then hide your implementation.
You shouldn't do it this way if the collection needs to be serialized. In that case, stick with one of the concrete classes such as Collection<T> like FxCop suggested.
Friday, September 26, 2008
#
The Expression Blend team announced the released of of Service Pack 1 for Expression Blend 2 today. Here are the details for this release.
This Service Pack provides you with all of the functionality you had with our earlier Expression Blend 2.5 June 2008 Preview. Besides allowing you to create new projects for WPF, Silverlight 1, and Silverlight 2 RC, we are also exposing new platform functionality like Font Embedding / Subsetting for Silverlight 2 projects.
You can download the service pack here.