CMS version is 9.7.0.

Also tried to rewrite to not use the GetItems method. I did this:

var pages = contentRepo.GetDescendents(ContentReference.StartPage);

var list = new List<PublicContentPage>();

foreach (var page in pages)
{
    var p = contentRepo.Get<PageData>(page);
    if (p is PublicContentPage)
    {
        var pcp = p as PublicContentPage;
        list.Add(pcp);
    }
}

And then the Get method returns the same error. I have never come across this before and I haven´t found an explaination.

//P

Maybe you have a content item where you have removed the class in solution? Try running it on part of the tree to locate the failing item and you will likely figure it out. Turn on logging on All and see if that gives you information about which item is falling. Work around is looping through them and use contentRepo.Get instead. That method with GetDescendents on start page will load the entire content tree btw so will crash on a large site. So be a bit careful...and filter on access rights etc 

I know that using StartPage as the root for GetDescendents isn´t the best idea, we´re trying out how to do what we want when we stumbled onto this problem :) I actually narrowed the the page tree to a part where there´s only around 10 pages and then it worked. Can´t really see what page would be of a type that might have been removed in the solution but it is our dev environment so it might be possible. I´ll see if I can narrow it down.

Thanks for your input!

//P

In that foreach loop up there with .Get you should be able to find out the offending page if you add some logging / patience and debugging...

<p>Hi,<br /><br />Found this here&nbsp;http://world.episerver.com/Modules/Forum/Pages/Thread.aspx?id=121537<br /><br />So I guess call add this method and call&nbsp;<br /><span></span></p> <p><span>var list =&nbsp;</span>FindPagesByPageTypeRecursively&lt;PublicContentPage&gt;(ContentReference.StartPage).ToList();</p> <p><span></span></p> <pre class="brush:html;auto-links:false;toolbar:false" contenteditable="false"> private IEnumerable&lt;TPageType&gt; FindPagesByPageTypeRecursively&lt;TPageType&gt;(PageReference pageLink) where TPageType : IContent { var criteria = new PropertyCriteriaCollection { new PropertyCriteria { Name = "PageTypeID", Type = PropertyDataType.PageType, Condition = CompareCondition.Equal, Value = _contentTypeRepository.Load&lt;TPageType&gt;().ID.ToString(CultureInfo.InvariantCulture) } }; return _pageCriteriaQueryService.FindPagesWithCriteria(pageLink, criteria).Cast&lt;TPageType&gt;().ToList(); }</pre> <p><br /><br /></p>

OR Try changing PageData to IContent in your Get method. 

var pages = contentRepo.GetDescendents(ContentReference.StartPage);
 
var list = new List<PublicContentPage>();
 
foreach (var page in pages)
{
    var p = contentRepo.Get<IContent>(page);
    if (p is PublicContentPage)
    {
        var pcp = p as PublicContentPage;
        list.Add(pcp);
    }
}

Thanks for all your input. I haven´t found the root cause yet, all the page types are available in the solution so that can´t be the issue and I haven´t had time to deep dive into logging and debugging because it works for some parts of the page tree so it´s nothing wrong with the actual code which was what I thought from the beginning. I have refactored the code to use Episerver Find instead and thus skipping the GetDescendents method call with StartPage as root so the performance should be ok.

With Episerver Find there should be no performance problems no. Root cause is probably that you have some content in tree that isn't pagedata so assume it's IContent and check using "is" keyword or with OfType extension in the future and you should be fine. Might be good to get rid of those anyway to avoid future issues...