Without a specific error message, it's difficult to diagnose this problem properly; however, if it's failing while resolving then it's not likely to be an issue with the CT but, if you have a lot of Component Links, a possible culprit is an exponential tree of dependencies causing a timeout when resolving items to publish (off the top of my head I think the stored procedure in question is called something along the lines of EDA_GETPUBLISHITEMS). You can test for this by choosing "Show Items to Publish" on the Publish dialog and seeing how long it takes to resolve all of the Component Links.
We've encountered this in a production environment in the past and after trying various other things (service packs, configuration, database maintenance), we ended up implementing an event handler to subscribe to the ComponentPublishPre
event and override Component Link resolution so dependencies (except Multimedia Components) aren't published.
/// <summary>
/// Disable link resolution for component publishing
/// </summary>
public void OverrideLinkResolution(Component component, PublishEventArgs args,
EventPhases phase)
{
var targets = args.Targets.Cast<TargetType>().ToArray();
args.PublishInstruction.ResolveInstruction.IncludeComponentLinks = false;
// If this component uses any multimedia components then publish them too
foreach (var item in component.GetUsedItems())
{
var relatedComponent = item as Component;
if (relatedComponent != null
&& relatedComponent.ComponentType == ComponentType.Multimedia)
{
item.Publish(targets, true, false);
}
}
}
This has the drawback that content editors will have to publish dependencies manually in order to get Component Links (particularly in Rich Text fields) to work, though in our case this wasn't undesirable as there was such a rich network of links that publishing any dynamic Component Presentation was likely to take all sorts of unready content with it.