tags:

views:

61

answers:

2

Hi -I have a WSS site on a shared third-party host.

I have a solution with some custom controls -I then use the SmartPart web part to show these controls.

Here is the problem -I update the code and publish the solution to the remote host. But then I see the results of the "old" assembly.

I tried everything and the only solution is to change the name of the controls' classes.

I am not sure where this is being cached -and how could I clear it.

Thank you for your help.

A: 

If deploying the assemblies to the GAC you will need to restart IIS. SmartPart web parts can also cache data in memory so again IIS reset might help. It depends on how the issue is manifesting. Is it that the page content is just not updating, or is it that the old code appears to be running?

TheCodeKing
Thank you that was really useful -I added a comment to my question explaining how could I solve it.
Bruno Ligutti
+1  A: 

Usually there is no caching anywhere when you follow a complete retract/delete/add/deploy cycle of the solution package. But first of all I would make sure that the package you are deploying actually has the proper version of the code. To do so rename the package to *.cab, extract the assembly and check the changed code in Reflector. Once you know that you have the correct assembly in the solution package make sure to retract and delete the previous wsp on the SharePoint server. For only updating an assembly a solution upgrade should be fine - but try the full retract/delete/add/deploy thing just to be on the save side.

I take it that you do not have physical access to the SharePoint server. But in case the above fails your assembly might be cached in the frameworks' temporary ASP.NET files or not properly removed from GAC/BIN folder. To reset those you need an administrator to do an IIS reset and then delete (before the site is being used again) this folder: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files and check BIN/GAC folders for the assembly.

Let me know if this helps...

Bernd
That's not entirely true, assemblies are cached in memory by the timer job which can effect deploying updates to feature receiver code. Also depending on the WSP manifest IIS may or may not reset automatically. In the case of files deployed to the GAC this therefore may require manual reset in order to see changes. An assembly is never cached in the temporary ASP.NET folder this is only used for dynamically complied ASPX or ASCX files for example.
TheCodeKing
Thanks for pointing that out. I guess you are right on the temporary ASP.NET folder. What you are saying about the timer job I am not sure about. Why and how should the timer job cache any assemblies? Regarding the IIS reset I am not quite sure either what you mean. As soon as you deploy the solution using a timer job (not with -local) you are guaranteed that all WFEs in the farm run an iisreset (that's what MSDN says...).
Bernd
@Bernd Yep the timer job can cache assembly code in memory when certain commands are executed via stsadm. In this case depending on the command they can run in the context of the timer process. It's sometimes necessary to restart the timer process in order for updated feature receiver code to be executed. I know because I spent many hours on it. Regarding the IIS reset there is an option in the WSP manifest for controlling the behaviour called ResetWebServer. Granted I think by default they would always be restarted if deploying code to the GAC.
TheCodeKing
Thank you Bernd that was really useful.
Bruno Ligutti