You said that the code is working as expected on your local machine but suddenly fails to produce the desired results when you move it to a different server, so even with the incomplete code you posted I would exclude the possibility that your service contains mayor logical errors.
You also stated that on the new server the code reaches the
foreach (SPListItem spListItem in spList.Folders) line, but then "fails" at enumerating the discussions items (aka the Folders) on the list. This means that we should be able to safely ignore the missing part in your sample (the "
//DO WORK" line) since it is never reached.
Your code is finding the list, but failing to enumerate its item. You also seem performing correct elevation using
SPSecurity.RunWithElevatedPrivileges, recreating all the SPWeb and SPSite instances you use inside the elevated context.
Under these assumptions, I can think of just two solutions:
- The list does not contain folders in the first place: I expect this is the first thing you would have checked, but it is worth mentioning anyway. Maybe the list is empty or whoever configured the "siturl" parameter made it point to the wrong list?
- Your elevated context lacks permissions to actually read the available discussion/folder items.
You may ask how an elevated context may lack permission to do something. Remember: when you use
SPSecurity.RunWithElevatedPrivileges your code will basically run under the Application Pool identity. The call is not performing any "permission elevation" magic other than that - so anything the Application Pool can't do, you will not be able to do even after the elevation.
Your first line:
string siteUrl = ConfigurationManager.AppSettings["siturl"];
shows that you are reading the url of the site that hosts the list from a configuration parameter. I would check two things:
- is the target site running under the same Application Pool account the service is running on? It is not uncommon for development environments to just use one account for everything, but this is not usually the case for production ones
- even if the Application Pool identity is the same, is this identity actually able to perform the read (this should be the case, but sometime miss-configuration can happen and cause situation where a web application App. Pool identity isn't able to actually read all data).
Based on the details you provided, I think you may be in case 1) - your services tries to access data found in a site that runs under a different, unrelated application pool identity and so elevation is failing. If that is the case, maybe you can try to re-impersonate the actual SystemAccount identity from the site the list is found on.
SPUserToken sysAccountToken = null;
using (SPSite rwepSPSite = new SPSite(siteUrl))
sysAccountToken = rwepSPSite.SystemAccount.UserToken;
using (SPSite saSPSite = new SPSite(siteUrl, sysAccountToken))
using (SPWeb saSPWeb = saSPSite.OpenWeb())
// your code here.
The above code should get the
SystemAccount.UserToken and then use the token to perform elevation. If even this approach fails but you still believe that the problem is permission related, another possible approach would be storing some credentials in SharePoint Secure Storage... but this would be a lot more difficult and require more work so I would try this simpler approach first.
I hope this info may be useful. Sadly, as now, your question is pretty open-ended. Free to ask for more help if you find out any new useful detail about the issue and I will try to answer as I can.