Rick van den Bosch - Blog

... on software development, architecture and more

"Some of the properties associated with the solution could not be read"

Next to the message in the subject, one of the symptoms we encountered is that although the solution contains some test projects the 'Create private accessor' menu has disappeared. Also, selecting 'Create unit tests...' produces an error. And when editing a testrun config and selecting the 'Code coverage' option, the settings dialog simply closes, without any message.

All these (and probably more) symptoms can occur because of a corrupt solution file. In our case the nested projects section was corrupted. Chances are this is because of some project or solution folder not being removed the way it should have been. Anyway, I tried fixing the solution file by hand but because of too many projects and solution folders this wasn't the way to go. Those GUIDs don't make a file very readable... I made a new solution file, containing the same solution folder structure, and added the existing projects. I overwrote the existing solution file, and that was that. So when you're experiencing any or all of the above symptoms, try building up a new solution file.

Hope this helps.

Technorati tags: , , ,

Posted: Thu, Dec 6 2007 9:43 PM by Rick van den Bosch | with 17 comment(s)
Filed under: , ,

Comments

Stoney Meyerhoeffer said:

We had the same error in our project.  The MS knowledge base article on teh issue about making sure there are no relative paths to Source Control Provider was fruitless.

Turns out it was caused by a second "GlobalSection(TeamFoundationVersionControl) = preSolution" block in our sln file.  We removed the block that was in error, and the properties couild nto be read message went away.

# December 13, 2007 4:41 PM

Joe said:

This worked for me too. Thanks!

# January 25, 2008 9:58 PM

Further Proof I Lack Self-Control : An Experiment in Scotch said:

Pingback from  Further Proof I Lack Self-Control : An Experiment in Scotch

# March 25, 2008 2:39 PM

Jay said:

I also had 2 TeamFoundationVersionControl GlobalSection's in my sln file, removing one fixed my issues as well.  Cheers.

# April 14, 2008 3:57 PM

Dai Clyant said:

Excellent, exactly what I was looking for too!!

Not to do with Team, but older fashioned VSS 6.0. Duplicate SoureControl section was the cause.

Nice one.

:o)

# May 6, 2008 12:30 PM

Mike Brown said:

+1 on the duplicate globalsection

# August 6, 2008 7:56 PM

Steven Berkovitz said:

That also did the trick for me, thanks.

# October 27, 2008 5:50 PM

Rossa MacM said:

That was our exact problem too. Thanks.

# November 25, 2008 10:41 AM

Matt said:

Bravo!  Problem fixed with removal of the second source control section.  

I had renamed the root namespace on a bunch of my projects and had removed/readded to source control (VSS2005).  I wonder why VS causes this error?  

# February 6, 2009 5:46 PM

Oleg said:

Thanks! this helped!

# March 3, 2009 12:29 PM

Crabby Leg said:

I found two duplicate sections in my solution.  Removing the incorrect ones solved the issues.

# March 13, 2009 11:25 AM

Ravi said:

Good one!!!

# April 2, 2009 2:40 AM

Digga said:

Exactly That!

Duplicate removal fixed the problem, thanks :0)

# April 3, 2009 9:54 AM

City Folk said:

Same thing here, found 2 TeamFoundationVersionControl sections, deleted one and the error went away. Thanks

# April 7, 2009 4:06 PM

Paul said:

Thanks for the solution.  We had this problem once, and somehow got rid of it, but it came back on me recently, highly appreciated!

# May 7, 2009 3:36 PM

Keegan said:

Thanks, that did it!

# June 22, 2009 11:02 PM

Edijs said:

The same solution worked for me.

In my case it started when two developers added new projects at the same time and when both tried to check-in code. Obviously code was not "auto merged" correctly and hence the unpleasant message.

Thanks a lot!

# June 23, 2009 3:53 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Please add 6 and 4 and type the answer here: