3

Here is a complicated one I have been banging my head against for months.

I have a SharePoint 2010 site feature with a custom navigation provider. I have created a feature receiver that will add the navigation provider to the web.config:

[Guid("a2ecd7e8-8eac-401e-a9c8-e635e93da58a")]
public class MySiteEventReceiver : SPFeatureReceiver {

    private const string WebConfigModificationOwner = "MyCustomUniqueString";

    private readonly static SPWebConfigModification[] Modifications = {

        // Modification for the custom site map provider

        new SPWebConfigModification {
            Path = "/configuration/system.web/siteMap/providers",
            Name = "add[@name='CustomNavigationProvider']",
            Owner = WebConfigModificationOwner,
            Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode,
            Value = "<add name='CustomNavigationProvider' type='" + typeof(NavigationProvider).AssemblyQualifiedName + "' NavigationType='Global' />"
        },

        // I have a small handful of other web.config modifications here that are not causing me any problems
    };

    public override void FeatureActivated(SPFeatureReceiverProperties properties)
    {
        try {
            SPWebApplication webApp = ( (SPSite)properties.Feature.Parent ).WebApplication;
            Collection<SPWebConfigModification> webConfigModifications = webApp.WebConfigModifications;

            foreach ( SPWebConfigModification modification in Modifications ) {
                if ( !webConfigModifications.Contains(modification) ) {
                    webConfigModifications.Add(modification);
                }
            }

            webApp.Update();
            webApp.WebService.ApplyWebConfigModifications();
        }
        catch { }
    }


    public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
    {
        try {
            SPWebApplication webApp = ( (SPSite)properties.Feature.Parent ).WebApplication;
            Collection<SPWebConfigModification> webConfigModifications = webApp.WebConfigModifications;

            for ( int i = webConfigModifications.Count - 1; i >= 0; i-- ) {
                if ( webConfigModifications[i].Owner.Equals(WebConfigModificationOwner) ) {
                    webConfigModifications.RemoveAt(i);
                }
            }

            webApp.Update();
            webApp.WebService.ApplyWebConfigModifications();
        }
        catch { }
    }
}

Everything is working perfectly.

A few releases later, we decided to go ahead & clean up a lot of our code. The assembly & namespaces for the custom navigation provider & feature receiver changed. We removed the old feature & deployed the new one with the new namespaces.

I never hard coded the assembly name or namespace into the feature receiver. I always used the typeof(NavigationProvider) like the code above. I expected no problems with this migration.

To my surprise, when the feature is activated, the old namespace was added to the web.config, & the site would not work. When I manually fix the web.config to use the new namespace, all is well. But as soon as i redeploy the feature, the new namespace is replaced with the old namespace, & the site breaks again.

In an effort to debug, I have removed the above feature receiver entirely. I now have no feature receivers or any other code that edits the web.config. The web.config still gets modified with the old namespace every time I deploy, just as if the old feature receiver was still in place.

I have checked the GAC. Only the new assembly is present; the old assembly is nowhere to be found.

What could possibly be going on? Where could this old code be? Was there something horribly wrong with my feature receiver code? Is there anyway to track what assembly or feature is writing to the web.config?

2
  • Do a reset of the sptimerv4 service with net stop / net start, as well as an IIS reset. Could very well be a caching issue Sep 11, 2013 at 17:25
  • I am afraid the server has been rebooted many times since I started having this problem.
    – Markus
    Sep 11, 2013 at 20:30

1 Answer 1

1

I had a similar issue that resulted in having to do a rebuild of my dev box.

What I think happened was that the feature reciever I was deploying was not being retracted correctly on all the sites it was being deployed too. It had been deployed to service application sites, web applications, site collections and sites. My guess was because I had changed the deploy scope.

Anywho, I suggest getting a full list of all the features installed on all web apps, sites, and collections using power shell and see if you can find any with the same guid as your feature.

I also searched the database to see if I could find references, which I did, but don't change the database. That was my mistake and what I ended up with was a corrupt sharepoint install which couldn't be uninstalled and I had to rebuild my dev box. Lesson learned.

Hope this helps

1
  • Unfortunately, both the old feature (with receiver) & new feature (without receiver) have the same GUID. Not sure what the consequences are of changing the GUID is.
    – Markus
    Oct 24, 2013 at 14:09

Your Answer

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

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