5

We've just started getting some errors when trying to publish pages (.NET) - in Tridion 2009. It started off with intermittent, classic "RenderComponentPresentation exceeded maximum number of render failures 0" errors, and then progressed to complete failure.

We can preview the pages correctly, so I'm loathe to believe it's anything to do with the actual templating code.

Unfortunately I don't control the box this is running on, so I won't be able to run any debug code, etc... so this is a shot in the dark of sorts!

Stack trace is below:

Event Type:        Error 
Event Source:        Publishing 
Event Category:        None 
Event ID:        100 
Date:                22/05/2012 
Time:                14:28:22 
User:                N/A 
Computer:        XXXXXXXXXX
Description: 
Exception has been thrown by the target of an invocation. 
Old format or invalid type library. (Exception from HRESULT: 0x80028019 (TYPE_E_UNSUPFORMAT)) 


Component: Tridion.ContentManager.Publishing 
Errorcode: 0 
User: NT AUTHORITY\SYSTEM 

StackTrace Information Details: 
   at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType) 
   at System.RuntimeMethodHandle.InvokeConstructor(Object[] args, SignatureStruct signature, RuntimeTypeHandle declaringType) 
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) 
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) 
   at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) 
   at Tridion.ContentManager.Session.GetObject(String uri) 
   at Tridion.ContentManager.Publishing.Publisher.QueueMessageHandler.HandleMessage()
mpaton
  • 789
  • 3
  • 14
  • I remember having similar errors in 5.3 due to my assemblies being compiled to "ANY CPU", the server being x64, and somehow Tridion trying to load them would break it. After forcing it to compile to x86 I stopped having the error, so didn't bother investigating further than this. – Nuno Linhares May 24 '12 at 11:47

1 Answers1

6

It looks like you have an old DLL somewhere on that system. Check if all your dependencies (so DLLs that you put into the GAC or Tridion*\bin directories) on the box are up to date and have them restart the Tridion-related services, COM+ applications and IIS application pools.

Edit: actually if Template Builder works, it looks like the DLLs may be up to date already and you just have to restart the services+COM+apppools. If your team doesn't know how to do that, simply have them restart the machine or have a look at this script that does a brute force restart of everything Tridion-related.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Thanks Frank - it's been done and it's working again. Would you happen to have any advice as to the root cause of this problem? – mpaton May 22 '12 at 13:55
  • 1
    It seems that one of those processes was hanging on to an old version of a DLL. Since Tridion automatically reloads the assemblies that you upload, it was most likely a dependency that was recently updated. Did you by any chance recently install any add-ons. – Frank van Puffelen May 22 '12 at 14:08
  • Hi Frank, we've not installed anything onto the servers - the most recent deployment was it's a pretty vanilla install of 2009. We deploy our TBBs via Tridion as unfortunately we cannot use the TcmUploadAssembly as the Content Manager is behind a reverse proxy. Would this be possibly related to the root cause of this problem (i.e an assembly deployed is being used concurrently during a publication request and requires a restart before it can be reloaded?) – mpaton May 22 '12 at 14:58
  • 1
    Whether you do TcmUploadAssembly or Load From Disk from the CME, the result to the assembly loading is exactly the same. So that should not cause the problem. I was talking to Nuno about it and he mentioned something about 64-bit/32-bit or universal DLLs. What target do you use in the DLLs when you build them in Visual Studio? – Frank van Puffelen May 22 '12 at 17:10
  • hi frank, we are platform agnostic - we use "Any Target" in the build step. – mpaton May 25 '12 at 14:10
  • 1
    That is what Nuno recalled to sometimes cause problems before Tridion 2011. So if this happens again, consider setting the target to the correct number of bits - or upgrading to Tridion 2011 of course :-). – Frank van Puffelen May 25 '12 at 14:13