Archive for the ‘VS 2008’ Tag

How to Access Nonpublic Types of a Referenced Assembly

Most of the solutions I work with consist of at least 3 projects: data access layer, business logic layer, windows app, etc. Each of those projects contains at least a few instances of code that throws exceptions. Typically, these exceptions are used to indicate invalid parameters or internal errors that cannot be handled locally. I tend to use resource files to store assembly messages because it allows me to enforce a common exception message format.

In small and medium-sized solutions, the number of exception messages in the resource file is small: (15-20) and they are not very likely to be reused. Large solutions (5+ projects), on the other hand, often contain 50+ messages and messages are likely to be reused. The logical thing to do, in this case, is to put all exception messages in a separate assembly (ProjectName.FeatureName.Resources) and reference it.

This sounds like an easy thing to do and it is. Except for one minor issue… The designer.cs file generated by the Visual Studio resource editor is marked internal and so are it’s members. It is possible to edit the file manually to change resource visibility to public, but these changes are lost the moment you edit the file using the designer because it re-generates the designer.cs file.

There is a little known attribute in the .NET Framework that helped me get around this problem: InternalsVisibleTo.

This attribute makes all nonpublic types in an assembly it is applied to visible to another assembly.

Example: AssemblyInfo.cs


[assembly:InternalsVisibleTo(“ProjectName.FeatureName.Services, PublicKey=2e049ab9234d98234“)]

The first line specifies that all nonpublic types are visible to assembly ProjectName.FeatureName.Data (version and culture of the assembly are not taken into account).

The second line specifies that all nonpublic types are visible to assembly ProjectName.FeatureName.Services that has public key 2e049ab9234d98234.

NCover Ignores C# 3.0 Automatic Properties

I’ve spent a good half hour trying to set up TestDriven.NET to analyse code coverage of my tests.
Here’s the scenario:

  • A new installation of VS 2008
  • A new installation of R# 4.0 (EAP build), TestDriven.NET 2.0 and xUnit 1.0 RC2
  • New solution with two projects project A (main project) and project B (xUnit unit tests)
  • Project A contains one class (MyClass) with three automatic properties
  • Project B contains one codefile with a test class testing automated properties of MyClass
  • I launch a test session with code coverage analysis
  • NCover Explorer shows absolutely no coverage for Project A

Puzzling. I immediately started googling to see if anyone else has had this problem and have gone through at least a dozen sites (including NCover FAQ page). Nothing. Not even close.

As a last resort, I’ve added an existing .cs file from another solution to Project A to see if that will trigger the coverage analysis to work correctly. And guess what – it did. Sort of.

Looking at the coverage results, it appears that C# automatic properties have no effect on the outcome of code coverage analysis – they are simply ignored.

Is this is a good thing or a bad thing? I haven’t decided.

Visual Studio 2008 and .NET Framework 3.5 just shipped!

Visual Studio 2008 and .NET Framework 3.5 now available on the Microsoft  website:

More info on this is available here and here.

Channel9 video is also available: Soma, Carol Grojean, Jeff Beehler: Visual Studio 2008 RTM!!! (31 min. 15 sec.)