DCSIMG

 Subscribe in a reader

March 2009 - Posts - Guy kolbis

March 2009 - Posts

According to Ed Glass from Microsoft Visual Studio Team Test Team posted about new VSTT Quick Reference Guide 1.0.

According to Ed:

“This is a comprehensive collection of technical information on VSTT –- 83 pages of information!!! Many questions you may have on how stuff works in web, load, and unit test are answered in this doc. This doc is a must have for anyone working in VSTT.

image

You can download it here.

kick it on DotNetKicks.com

Just the other day, I had an argument about the way to add references to a project. As you already know, there are two main ways to achieve that:

  1. Project Reference.
  2. File Reference.

The “Project Reference”, add a reference to a project within the given solution where a "File Reference” references an assembly that is located everywhere, either on the local machine or on the network (we just browse to it and add it to the references).

So, the question is: “when to use Project and when to use File reference?”

My Opinion

In my opinion the rule should be simple:

Use “project reference” to add reference to assemblies within your solution.

Use “file reference” to add a reference to a cross solution assemblies (I will give an example later on).

An Example

Lets say that you have two teams in the development process, the infrastructures team and the application team.

The infrastructure is working on their solution. Every month they release a new version of the infrastructure and only then the application team should use the new version. In order to achieve that the application team should reference files in order to work with a specific version (release) of the infrastructures. If they would have add the project to the solution and add a reference, they would have worked on the development version that might not be ready yet.

In this case it is recommended to use “File References” and I call it “cross solution assemblies”. 

Other Considerations

I assembled some pros and cons in regarding to both ways. Consider them if you are not sure which way to go:

  • File reference will not allow you to see the “Go To Definition” (it will show you the metadata).
  • File reference will not show you all the referenced locations in the “Show All References” option.
  • Project reference sometime requires additional projects to be added as well if you have a dependency.
  • With File reference you have to manually fix the build order and the dependencies.
  • If you like working with multiple solutions (that are locally created), working with File References is easier.
  • In project reference when ever you build your project, the referencing projects will automatically get the updated version. If you want to achieve that with file reference, you will have to add post build events.

Charles Sterling posted a new blog post where he indicates that Microsoft VSTS Rangers had published two white papers on how to build SharePoint applications with VSTS:

You can read more about it here.

 

image I am using Log4Net as a logging framework for a small application I am writing.

I needed to get the full path to the output file that Log4Net is generating. Apparently it is quite hidden…So here is a code that will help you get that file:

public static string LogFile
{
get
{
return ((FileAppender)LoggerService.Logger.Logger.Repository.GetAppenders()[0]).File;
}
}

The loggerService is my Log4Net wrapper which is fully tested and you can use it here:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using log4net;
using log4net.Config;
using System.IO;
using System.Windows.Forms;

namespace Core.Services
{
public static class LoggerService
{
public static ILog Logger
{
get;
private set;
}

public static string LoggerConfigFile
{
get;
private set;
}

public static bool IsInitialized
{
get;
private set;
}

public static void ShutdownService()
{
lock (typeof(LoggerService))
{
if (!IsInitialized)
{
throw new CoreException(Core.Res.Core.Core_Logger_ShutdownException);
}

IsInitialized = false;
Logger = null;
LoggerConfigFile = null;
LogManager.Shutdown();
}
}

public static void InitializeService()
{
lock (typeof(LoggerService))
{
if (IsInitialized)
{
throw new CoreException(Core.Res.Core.Core_Logger_InitializationException);
}

Logger = LogManager.GetLogger(typeof(LoggerService));
LoggerConfigFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;

if (!File.Exists(LoggerConfigFile))
{
throw new IOException(string.Format(Core.Res.Core.Core_FileSystem_FileNotExistFormat, LoggerConfigFile));
}

XmlConfigurator.ConfigureAndWatch(new FileInfo(LoggerConfigFile));
IsInitialized = true;
}
}

public static void Debug(object msg)
{
lock (typeof(LoggerService))
{
Logger.Debug(msg);
}
}

public static void DebugFormat(string format,params object[] parameters)
{
lock (typeof(LoggerService))
{
Logger.DebugFormat(format, parameters);
}
}

public static void Info(object msg)
{
lock (typeof(LoggerService))
{
Logger.Info(msg);
}
}

public static void InfoFormat(string format, params object[] parameters)
{
lock (typeof(LoggerService))
{
Logger.InfoFormat(format, parameters);
}
}

public static void Warn(object msg)
{
lock (typeof(LoggerService))
{
Logger.Warn(msg);
}
}

public static void Warn(object msg, Exception ex)
{
lock (typeof(LoggerService))
{
Logger.Warn(msg, ex);
}
}

public static void WarnFormat(string format, params object[] parameters)
{
lock (typeof(LoggerService))
{
Logger.WarnFormat(format, parameters);
}
}

public static void Error(object msg)
{
lock (typeof(LoggerService))
{
Logger.Error(msg);
}
}

public static void Error(object msg, Exception ex)
{
lock (typeof(LoggerService))
{
Logger.Error(msg, ex);
}
}

public static void ErrorFormat(string format, params object[] parameters)
{
lock (typeof(LoggerService))
{
Logger.ErrorFormat(format, parameters);
}
}

public static void Fatal(object msg)
{
lock (typeof(LoggerService))
{
Logger.Fatal(msg);
}
}

public static void Fatal(object msg, Exception ex)
{
lock (typeof(LoggerService))
{
Logger.Fatal(msg, ex);
}
}

public static void FatalFormat(string format, params object[] parameters)
{
lock (typeof(LoggerService))
{
Logger.FatalFormat(format, parameters);
}
}
}
}

I hope this helps.

kick it on DotNetKicks.com

Recently I had installed some add-ins for my Visual Studio, however I could not see them nor use them. I wanted to check if the add-ins where installed, so I have tried to open the Add-In Manager. Unfortunately the Add-In manager was grayed out – disabled:

image 

In order to fix that I had to allow Visual Studio to load Add-Ins.

From tools—>Options—>Environment—>Add-In/Macro Security I have checked the option Allow Add-In component to load:

image

Once, I completed that I had to restart VS and waala:

image

I hope this helps…

If you have tried to evaluate Visual Studio 2010 CTP you might have gotten an activation issue such as follows:

image

In order to fix it, I followed this post by Brian Keller:

image

I hope this helps…

image

I just finished reading a post puclished by liammclennan on about Test Driven Development (TDD) and Return of investment (ROI).

According to on:

"The cost of TDD is easily measured - how long is spent writing and maintaining tests. The benefit is more complicated."

 

So, where does the ROI is better? Is it by using TDD? Is it by using traditional development? Is it by using an hybrid of both?

Unfortunately, I have not found a research that can really give me an answer.

I would love to think that the ROI of using TDD is greater than the one with traditional development process.

What do you think?