Number of Unit test projects in Visual Studio solution

Some time ago I have discussion with my co-worker  how to organize test projects. 
Should we have a single test project that does all sorts of things and references every project?
It is good to have one integration test dll, but for unit tests, what is the point merging everything into one.

In ideal world I agree that small independent projects are better. Unfortunately we have  solution size limitations 
However, Visual Studio performance quickly degrades as the number of projects increases. Around the 40 project mark compilation becomes an obstacle to compiling and running the tests, so larger projects may benefit from consolidating test projects.
  • Single solution. If you work on a small system, create a single solution and place all of your projects within it.
  • Partitioned solution. If you work on a large system, use multiple solutions to group related projects together. Create solutions to logically group subsets of projects that a developer would be most likely to modify as a set, and then create one master solution to contain all of your projects. This approach reduces the amount of data that needs to be pulled from source control when you only need to work on specific projects.
  • Multiple solutions. If you are working on a very large system that requires dozens of projects or more, use multiple solutions to work on sub-systems but for dependency mapping and performance reasons do not create a master solution that contains all projects.
At the moment we decided to go with one huge integration test and one huge unit test projects.
And we constantly trying to keep reasonable (not too many) number of projects in the main solution. Unfortunately this number is quite big – 70+. 

Office customization tips

I’ve posted below a few Office customization tips, that I prefer to setup when using a new computer.
Display File Path in Excel

Steps to display the file path of the current open file (Excel 2007):

  1. Right click on the ribbon

  2. Choose “Customise quick access toolbar”

  3. Select “All commands”

  4. Then choose “Document Location”

  5. Click “Add”.. and it will appear on the right

MS Word 2007/2010 – display path and filename in menu bar

To add the Document Location command to your Quick Access Toolbar(QAT):

– Click the More (or Customize) command at the end of the QAT and then click

More Commands.

– In Choose Commands From, select Commands Not In the Ribbon.

– Locate Document Location, select it, and then click Add to add it to your


Prompt to open a Microsoft Office Word document as read-only

  1. In a Word file, click the Microsoft Office Button , and then click Save As.

  2. Click Tools, and then click General Options.

  3. Select the Read-only recommended check box.

  4. Click OK.

  5. Click Save. If prompted, click Yes to update the existing file with the new read-only setting.


Serialization error when property is declared as base class, but populated by derived class

I’ve receive  quite generic error Message :
 Type ‘MyclassType’ with data contract name ‘MyclassType:’ is not expected. Consider using a DataContractResolver or add any types not known statically to the list of known types – for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.
Type : System.Runtime.Serialization.SerializationException, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089

After investigation I found that the class that I tried to serialize, had a property declared of the base class, but at runtime derived class was assigned, and serialization was unable to resolve it.
The fix was simple- to add KnownType property to container class.

public class Mycontainer 
 MyBaseclass PropertyOfmyClass { get; set;}

public class  MyclassType : MyBaseclass
{ ….}

Unfortunately, the serialization time error message didn’t specify the name of container class , not the name of property. it makes harder to fix the error.

Response for REST method was truncated because default MaxItemsInObjectGraph was not big enough.

We have a   REST service with attributes [WebGet(UriTemplate =“…”, BodyStyle =WebMessageBodyStyle.Bare, ResponseFormat =WebMessageFormat.Xml)]

Normally it worked fine. But for particular data it has a huge response that was truncated. 

The size returned in a few attempts in IE browser was 2196456, in Chrome slightly different 2195397.

After a search in google I found, that has a number of suggestions.


For WCF service that will transfer large amount of data in operations, here are the configuration settings you need to check:

1) the maxReceivedMessageSize attribute of the certain <binding> element(in your case, that’s the webHttpbinding)


2) The <readerQuotas> settings (under the <binding> elements) which has control over the maxarrayLength, maxStringLength ,etc…


3) The DataContractSerializer behavior which has a MaxItemsInObjectGraph property. You can configure it via ServiceBehavior of your WCF service

#DataContractSerializer.MaxItemsInObjectGraph Property

4) And if your WCF service is hosted in ASP.NET/IIS web application, you also need to enlarge the “maxRequestLength” attribute of the <httpRuntime> element (under <system.web> section).

#httpRuntime Element (ASP.NET Settings Schema)

 After a few attempts my collegue found that our problem was caused by

#DataContractSerializer.MaxItemsInObjectGraph Property


<behavior name=“MyOperationBehavior>
          < dataContractSerializer maxItemsInObjectGraph =2196456 />

Upgrading PostSharp from ver 2.1 to new version 3.0

I was upgrading our solutions from PostSharp 2 to PostSharp 3. The small solution based on cache attribute from was upgraded without any problems.

Upgrading my main solution by installing nuget package PostSharp also was quite well. 
The only annoying thing was that installer added 
RequiresPostsharp.cs file to all projects, that already had SkipPostSharp=true setting and I had manually remove them
The issue was reported at
but Gael unfortunately  considers this behavior “by design“.
More work was to convert   psproj files PostSharp.Toolkit.Diagnostics ver 2.1 to new PostSharp.Patterns.Diagnostics.3.0.
There was no documentation.I’ve only found a short notice at the bottom of 

PostSharp Toolkits 2.1 need to be uninstalled using NuGet. Instead, you can install PostSharp Pattern Libraries 3 from NuGet. 
Namespaces and some type names have changed. 
Uninstall for 2.1 suggested to remove NLog nuget package, which we are using regardless of PostSharp.
I’ve run 
Install-Package PostSharp.Patterns.Diagnostics.NLog

The install of PostSharp.Patterns.Diagnostics.NLog didn’t like the latest version of Nlog, but Gael 
fixed it recently(
The installs haven't changed the content of PSPROJ files and I had  to manually update them.
1. Deleted old references to DLL and inserted dg:LoggingProfiles profile element
 <!–<Using File=”……..packagesPostSharp.Toolkit.Diagnostics.NLog.”/>
  <Using File=”……..packagesPostSharp.Toolkit.Diagnostics.” /> –>
2. After advise from Gael  I’ve  removed the Task element and change <Data Name="XmlMulticast">into simply <Multicast>.
3. I’ve also replaced namespace and DLL names in LogAttribute xmlns properties to be “clr-namespace:PostSharp.Patterns.Diagnostics;assembly:PostSharp.Patterns.Diagnostics”
The psproj file becomes similar to the following and seemed to work.
<?xml version=”1.0″ encoding=”utf-8″?>
< Project xmlns=”; xmlns:dg=”clr-namespace:PostSharp.Patterns.Diagnostics;assembly:PostSharp.Patterns.Diagnostics”>
  <Property Name=”LoggingBackEnd” Value=”nlog” />
  <Using File=”..packagesPostSharp.Patterns.Diagnostics.3.0.26toolsPostSharp.Patterns.Diagnostics.Weaver.dll” />
  <Using File=”..packagesPostSharp.Patterns.Diagnostics.NLog.3.0.26toolsPostSharp.Patterns.Diagnostics.Weaver.NLog.dll” />
    <dg:LoggingProfile Name=”Exceptions” OnExceptionOptions=”IncludeParameterType | IncludeParameterName | IncludeParameterValue | IncludeThisArgument” OnEntryLevel=”None” OnSuccessLevel=”None” />

      <LogAttribute xmlns=”clr-namespace:PostSharp.Toolkit.Diagnostics;assembly:PostSharp.Toolkit.Diagnostics” AttributeTargetAssemblies=”Applications.MyApp” AttributeTargetTypes=” Applications.MyApp.MyCustomer” AttributeTargetMembers=”*” OnExceptionLevel=”Warning” OnExceptionOptions=”IncludeParameterValue” />



It was deployed to CI test environment, where we noticed delays and timeouts. I found that despite that only  OnExceptionLevel and  OnExceptionOptions were specified, the new LogAttribute generated verbose trace information, which caused severe performance hit.

4. I had to change LogAttribute to LogExceptionAttribute and remove OnExceptionLevel and OnExceptionOption properties.