Alright. I have just made changes to a custom webpart that was already deployed to Sharepoint. I made a few deploys, some changes... and suddenly, a code that was in the front-end of the webpart didn't update. I found it strange, and I added a comment to the HTML code.

Guess what? I made another deployment, and I still can't find that comment on the source code. Then, I proceeded to try to get this exactly same code to another machine, and deploy it in the same way I tried to deploy - create the WSP in Visual Studio, and deploy it with Sharepoint 2013 management shell.

The deploy was successfull, and I did find my changes in the HTMl code and in the JS functions.

I have already tried to retract the solution, deploy with visual studio, delete my site collection, recreate it, generate a new WSP file, and deploy it... nothing worked on my machine. On other machines, it all runs well. Even if I generate a new package on these machines with the same solution.

What's going on? Is there any way I can solve this?

EDIT: I tried doing as Amal suggested, to no avail. I tried once more generate a new deploy on a different machine, and the changes went on all fine. What can I try next?

More Clarification:

I am still trying to gather more information on the problem. I saw similiar problems in Stack Overflow but with sharepoint 2010. So I tried updating a JS file with one space more, and generating a new WSP file. I opened the file, and... the timestamp date to 08/12/2014. And I have just updated it!

Why is Visual Studio generating the WSP file with this old solution? How can I solve this?

Final Edit:

So, after reading your comments, and some forums and consulting the seniors from here... I did not managed to solve the problem. Full steps:

  • Deleting the site collection, web application, and remaking the deployment using Visual Studio.
  • Same as above, but with Sharepoint Management Shell.
  • Same as above, but stopping all services, restarting then one by one, and deleting the sharepoint cache before that.
  • Restarting the services and re-deploying;
  • Checked the WSP and insert unto it manually a different version of my script;
  • Restarted the vm, database, host machine.
  • Cleared the SP solution in visual studio, deleting obj, pkg, and even deleting visual studio cache.
  • Manually adding the solution with powerShell, then activating the features.
  • Simple Deployment in visual studio, after it was done, deactivated features, deleted cache, stopped timer service, reactived then.

Well... nothing worked. I uploaded the changes to my git repo, then I have restored my VM to a previous point. Guess what... It worked again.

To this date I don't know what happenned. If someone look this question for future reference, I could not find a solution - if you meet this problem yourself, it would be wise to not waste much time on it, if you use a simple and fast solution, like I did. If someone find an answer, do answer here for future reference.

  • 1
    Try to remove the webpart from the page and then from the gallery. Then deploy and check. Dec 15, 2014 at 14:18
  • Is your server a single server farm? The webpart in question is a visual webpart? Dec 15, 2014 at 15:37
  • Yes, it is a Visual Web Part. Single server.
    – Malavos
    Dec 15, 2014 at 15:52
  • 2
    Have you tried whether activating/deactivating your webpart feature updates the files?
    – Mauro
    Dec 15, 2014 at 16:01
  • 1
    You can check your dll in GAC: C:\Windows\Microsoft.NET\assembly\GAC_MSIL. Do you know how to use RedGate Reflector? Dec 15, 2014 at 16:10

2 Answers 2


I think Update-SPSolution should work.

Update-SPSolution –Identity solution.wsp –LiteralPath “C:\solution.wsp” –GacDeployment

An IISReset I've found is important for making sure it's updated. Like Waqas said, resetting the timer service and admin service in services.msc is also helpful to ensure the reloading of updated assemblies.

  • Thanks Mike. This knowledge will be useful for the community. One of my work colleagues ran to a similiar problem, and has been using Update-SPSolution for it. The only problem is that it takes a lot longer, right? Can we improve somehow this speed?
    – Malavos
    Dec 29, 2014 at 12:53
  • This depends on the solution that you are updating, the hardware of the web servers, and the like. The speed of this shouldn't be relevant for normal use. How are you using it? Are you using it in a script or batch?
    – Mike
    Dec 30, 2014 at 14:52
  • Hey Mike. In a script. We develop webParts and have to deploy them for testing purposes. As I stated, it's running in a virtual machine, so hardware is really lacking. Common deploy takes something around 3 minutes, update sp solution takes around 12 or so. I don't know why it's way longer. But as a coleague from work found a similiar problem to mine, and UpdateSPSolution worked, I'm marking your answer.
    – Malavos
    Dec 30, 2014 at 17:34
  • It's replacing the dll in the GAC, recycling the application pools that associate with that solution, and any web application assemblies across the WFEs.
    – Mike
    Dec 30, 2014 at 19:28

We had the same problem in our environment couple of months of ago, when ever you try to update the solution it says successfully deployed but still no changes showed. Almost same steps we followed as you mentioned.

Finally we use some tool to check which Dll load in the Timer services and here we found our problem.

SO in our case easy fix was Restart the SharePoint Timer Services and Admin Services from Services Console.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.