I’m working in 10.1.600.4 and when I make a change to a dashboard and redeploy it, the changes won’t show up unless I clear my cache. What’s weirder is, it will show up the first time, but if I close the dashboard assembly and reopen it, it reverts back again. I can clear my cache (and loose all of my options settings) get it to show up with the new one for one click and then it goes back. The only way I have found to get it to stick is an IIS reset. That’s not a huge deal now while I’m testing before the upgrade, but when we go live that will be a problem.
Anyone else run into this? Any ideas on how to fix it?
I need to figure out how to get this to work correctly since we are now live with 10.1. It’s still holding onto the old .dll. The more frustrating part is, I’ve done an IIS reset, and it’s still holding onto the old one.
Can someone tell me where the local copy of the .DLL is stored so I can try to delete that one to get the system to forget the old one?
I have not, but is that any different than deploying it from the dashboard creation screen? I’ll give it a shot to see if it makes a difference though.
No, other than the aforementioned slowness the first time as they get reloaded from the server. As every environment is unique, I’d still move them somewhere safe, just in case there are issues until you know for sure.
I’ve noticed that despite a clear cache, a favorites and recents click pull
up the original version after changing a customization. I tend to make it
habit to remake my favorites and clear recents
This workaround did not work. It still is getting the old one from somewhere. I had a call with support and they recreated the problem in 10.1.600.7, so hopefully they will get a fix for this soon.
I have suffered from this a lot, the only way I have found to resolve this is to copy the dashboard definition and create a new version. I intend to create mine with V1,V2 etc on the end to keep the name the same.
This will create a new dll and should resolve the issue