2

I'm a newbie at SharePoint 2010. I right-click on the project, select Deploy if I want to deploy locally. The Site URL on the project is set to my local machine. If I want to deploy to the QA server, I select Deploy, navigate to the Debug/Release folder, grab the .wsp file, logon to the Central Administration on QA, retract the solution, then do Add-SPsolution <path to wsp file> through powershell, go back to Central Admin, the click on Deploy solution for that package. Works fine.

The web.config on my local machine has a custom connection string, and appsettings. When I deploy the package on the QA server, I'm manually changing the connection string and appsettings specific to QA. I want to automate this process. I want the web.config to be part of the package with it's own custom connecting string (one for local, one for QA, and for Production) and appsettings. How do I do it? The goal is on a new machine, I should be able to deploy the wsp and appsettings+web.config should all be correct without modifying anything manually. How do I accomplish this?

tempid
  • 7,838
  • 28
  • 71
  • 101

1 Answers1

1

I am pretty sure web.config modifications can't be done with just package files / CAML.

However, what can be done is to deploy a WebApplication Feature Reciever which modifies the web.config through SPWebApplication.WebConfigModifications.

Here is a snippet of code from my project, see the the Code Project KB for more details: (This first bit is just a handy function with some notes.)

// For WebConfigModifications access,
// see http://www.codeproject.com/KB/sharepoint/SPWebConfigModTool.aspx
// Hints:
// app.WebConfigModifications.Add(new SPWebConfigModification
//    {
//        Type =     [add/update child node?]
//        Path =     [XPath of parent node]
//        Name =     [XPath to identify child node UNIQUELY]
//        Owner =    [Use GUID to identify as ours]
//        Sequence = [Sequence number, likely 0 for only one]
//        Value =    [XML node to add/update]
//    });
void ModfiyWebConfig (SPWebApplication app, string path, string name, XElement node)
{
    app.WebConfigModifications.Add(new SPWebConfigModification
    {
        Type = SPWebConfigModificationType.EnsureChildNode,
        Path = path,
        Name = name,
        Owner = OwnerId,
        Sequence = 0,
        Value = node.ToString(),
    });
}

Get/init SPWebApplication

var app = properties.Feature.Parent as SPWebApplication;

Queue/setup modifications

ModfiyWebConfig(app,
            "configuration/system.webServer/modules",
            "add[@name='ASPxHttpHandlerModule']",
            new XElement("add",
                new XAttribute("name", "ASPxHttpHandlerModule"),
                new XAttribute("type", aspxHandlerModule)));

Apply modifications

app.WebService.ApplyWebConfigModifications();
app.Update();
  • Appreciate the quick and detailed response! I'm slightly confused, though. If I take this route and modify the web.config specific to QA, I'll need to make the change again for web.config specific to Production, correct? If so, then it's still the same as changing the web.config directly instead of doing it using this code. Pretty sure I'm missing something here. – tempid Nov 13 '12 at 19:30
  • @tempid Ideally the QA/Test and Production environments would mimic each other. But you are correct in that this still doesn't address one-off settings as presented; what it *does* do is allow for the process to be *automated*, should such a "common" configuration be found. –  Nov 13 '12 at 19:37
  • I see what you're saying. Thanks for pointing me in the right direction. Much appreciated. – tempid Nov 13 '12 at 19:48