My new blog is setup at http://blog.coderoom.net/.

Don’t forget to subscribe to the new RSS feed.

Download here: http://www.jetbrains.com/resharper/download/?41nl

Read release notes here: http://www.jetbrains.com/resharper/releaseNotes41.html

Just received my results for Software Engineering degree I did @ Kingston University: First Class.

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.Data")]

[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.

About an hour ago I received an invitation from Microsoft Connect to try out Live Mesh. Having watched the preview videos on Channel 9, I was looking forward to this opportunity for some time, so I immediately downloaded and tried to install it.

About a second later I was greeted with the following: 

Apparently, Live Mesh client requires UAC to be switched on during installation and operation. This is due to a technical constraint imposed by the COM layer in Vista and should be fixed in the next beta release.

There is a post on the Live Mesh Blog that provides some more information.

You can get it at: http://www.jetbrains.com/resharper/beta/beta.html

Via Laughing Squid:

Update: It looks like the video has been pulled from the site.

I was curious to see what all the buzz is about, so I’ve signed up.

You can “follow” me @ http://twitter.com/arnie_z

If you’re a developer, here are some people you might want to “follow”:

• Scott Hanselman (http://twitter.com/shanselman)
• Jeff Atwood (http://twitter.com/codinghorror)
• Rob Conery (http://twitter.com/robconery)
• Jeff Sandquist (http://twitter.com/jeffsand)
• Jon Galloway (http://twitter.com/jongalloway)
• Phil Haack (http://twitter.com/haacked)
• Max Pool (http://twitter.com/mpool)
• Dare Obasanjo (http://twitter.com/Carnage4Life)
• Dan Fernandez (http://twitter.com/danielfe)

If you are are in need of some RSS icons Katrin Wegmann has posted some of her work on http://www.beargraphics.de/.

All graphics listed there are free for non-commercial use.

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.