Ryan McIntyre

Changing the App Pool Identity using STSADM

2008-10-13T18:39:00Z

Ok, ok...I didn't write it. But I was in the room when it was written!!

My co-worker Gary Lapointe presented last week to the Colorado Springs SharePoint User Group on customizing STSADM and his "demo" was actually writing a new, functional STSADM command. Very simple to do. Visit his site for the details.

Not only did I learn some more about Gary's tools, I won the raffle for an MSDN Premium license (with Team Suite!) Well worth the trip. Thanks Gary!

MCS Co-Worker Finally Blogging

2008-09-09T21:20:00Z

It took him a while, but Sameer Surve finally has a blog! He's been my MCS counterpart at my current client for the last year and a half (give or take), and he definitely has lots of SharePoint and BizTalk info worth sharing. I guarantee you'll have at least one subscriber, Sameer!

Web.Config FeatureReceiver Update

2008-07-21T17:09:14Z

After my previous post outlining my custom Feature Receiver used to update any section of a web.config file, I had some follow up email conversations with Mike about his post and us possibly collaborating on a combined CodePlex solution. Well, that hasn’t happened yet. However, during that discussion, we talked a bit about security. Mike referred me to a post by a colleague of his inspired by this very topic. The gist of the discussion and post is that modifying the web.config with a Feature Receiver really only makes sense, from a security perspective, when the Feature is scoped at the web level. I agree, so I needed to make a small change to my custom FeatureReceiver.

The change I needed to make was simply to make sure that it did not update the web.config if the Feature was not deployed at the web scope. This was a pretty simple change, but I took the opportunity to do a bit more research on the topic to see what others had done. The best nugget I pulled out of this research time was a change in the way I was applying the updates. Turns out there is an issue applying an update using

SPFarm.Local.Services.GetValue< SPWebService>().ApplyWebConfigModifications();

Using that method, the changes don’t get applied to the entire farm. Since we’re in a farm environment, I would’ve run into that at some point. The solution is to use this instead:

webApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();

Continue to the end of this post for some more reading on the topic. For now, here is the code update I made:

        1: private void UpdateWebConfig(string XPathLocation, string ElementName,  

       2:     Dictionary<string, string> Attributes, bool removeModification)

       3: {

       4:     try

       5:     {

       6:         SPWebApplication webApp = null;

       7:  

       8:         //Get the web app

       9:         webApp = _properties.Feature.Parent as SPWebApplication;

  

        if (webApp == null)

            throw new SPException("Error obtaining reference to Web application. A feature must " +

                "be deployed at the WebApplication level to use the WebConfigChanges feature.");

  

        SPWebConfigModification modification =

            new SPWebConfigModification(ElementName + CreateAttributeString(Attributes), XPathLocation);

            //new SPWebConfigModification("authorizedType[@Assembly=\"Company.Moss.Activities, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9eed2245513232a4\"][@Namespace=\"Company.Moss.Activities\"][@TypeName=\"*\"][@Authorized=\"True\"]", "configuration/System.Workflow.ComponentModel.WorkflowCompiler/authorizedTypes");

  

        modification.Owner = "Company.Moss.FeatureReceiver.FDFeatureReceiver";

        modification.Sequence = 0;

        modification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;

        modification.Value =

             string.Format(CultureInfo.InvariantCulture,

             CreateModificationValueString(ElementName, Attributes),

             CreateModificationValueArgs(Attributes));

  

        if (removeModification)

            webApp.WebConfigModifications.Remove(modification);

        else

            webApp.WebConfigModifications.Add(modification);

  

        //Changing from SPFarm to webApp as advised by http://www.crsw.com/mark/Lists/Posts/Post.aspx?ID=32

        //SPFarm.Local.Services.GetValue<SPWebService>().ApplyWebConfigModifications();

        webApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();

        webApp.Update();

  

    }

    catch (Exception ex)

    {

        System.Diagnostics.EventLog el = new System.Diagnostics.EventLog();

        el.Source = "WebConfigFeature";

        el.WriteEntry(ex.Message, System.Diagnostics.EventLogEntryType.Error);

    }

}

Like I said, this is going to look a lot like the code in my previous post. The first change is in the first few lines of the try block. I assume the parent of the Feature is a Web App. If it gets a reference, great. If it doesn’t, it logs an error and doesn’t do anything else. It would be nice if there were a way to actually stop the Feature from being deployed, but that can’t be done in a Feature Receiver (it happens after the Feature is activated.)

The second change is at the end of that code snippet, and is to account for the Farm update issue I mentioned earlier.

That’s it. Like I said, not much has changed, but I wanted to put out an update in case others are using this approach.

For further reading, here are some references:

Reza Alirezaei – SPWebModification’s Top 6 Issues
Mark Wagner – How To Modify the web.config File in SharePoint Using SPWebConfigModification
Serge van den Oever – SharePoint Features – elements, scope and other info

(That last one is useful because he lists the types of features that are allowed at each scope. Can save you some time so you don’t implement this method to deploy something that can’t be deployed at the WebApplication level.)

InfoPath Master/Detail with SharePoint List Sources

2008-07-02T21:19:38Z

I picked up some InfoPath requirements after one of our consultants had to leave so this one had to be done after dusting off the InfoPath brain cells. I’m still not convinced this is the best way to get this done so please leave a comment if there’s a better way.

The InfoPath form needs to connect to two different SharePoint lists. The first list is a list of Orders and the second is a list of Versions that apply to an Order. There can be multiple Versions for each Order. The goal was to create a master/detail type action where a user selects an order from a drop down, which then reloads the form with all of the version(s) and version details for that order displayed in a repeating table. Doesn’t sound too hard, but I ran into some road blocks and had to resort to code.

Both roadblocks had to do with SharePoint lists as a source. I don’t know if this is specific to SharePoint sources or just external sources in general, but you can’t use a SharePoint source in a master/detail relationship. After dragging it onto the form, right click on the repeating table and view the properties. The master/detail section is grayed out. The second thing I ran into was trying to filter the SharePoint connection. No luck there either, it’s not available.

After some searching, I found a post on implementing master/detail for a web based form which detailed some steps to pull in SharePoint data using a different method. Instead of using the SharePoint List option when creating the connection, you use the XML option and point it to a URL which outputs the list data in XML format. I won’t cover the details of that here as he covers it his post very well, but it’s using owssvr.dll. That post solved my issues completely, but it was using code for InfoPath 2007. I needed to convert that to be 2003 compatible.

Since the 2003 compatible code is probably the only useful part of this post, here it is:

        1: public void OrderName_OnAfterChange(DataDOMEvent e)

       2: {

       3:     //Capture the new value for Order so we can filter the data just for that order

       4:     string newOrder = e.NewValue.ToString();

       5:  

       6:     //Get a reference to the Card Version Adapter

       7:     XMLFileAdapterObject cardVersion = thisXDocument.DataAdapters["Card Version owssvr"] as XMLFileAdapterObject;

       8:  

       9:     //Modify the Card Version adapter URL to append the filter

      10:     cardVersion.FileURL = cardVersion.FileURL + "&FilterField1=Order_x0020_Name&FilterValue1=" + newOrder;

      11:     

      12:     //Re-query

      13:     cardVersion.Query();

      14:  

      15:     if (e.IsUndoRedo)

      16:     {

      17:         // An undo or redo operation has occurred and the DOM is read-only.

      18:         return;

      19:     }

      20:  

      21:     // A field change has occurred and the DOM is writable.

      22:     // Write your code here.

      23: }

Pretty simple, but it took some SDK searching to find the right classes. I’m using the XMLFileAdapterObject to grab the “Card Version owssvr” data connection, then I change the URL using FileURL similar to how Ishai modified the FileLocation property of the FileQueryConnection object. Like I said, nothing fancy, but I thought it may come in handy for folks looking for a solution similar to Ishai’s, but who can’t use InfoPath 2007.

Test Twitter Notifier from Live Writer

2008-06-30T21:50:21Z

Trying out the Twitter Notifier using Live Writer. Found in the Live Writer SDK for Technical Preview. This should show up on my Twitter feed.

FeedReader Update

2008-06-30T17:21:00Z

Tim just put together a new release for his FeedReader web part which includes the code contributions I made a few months ago. He details some installation steps on his blog here.

Thanks again for the opportunity to contribute, Tim!

Drill Here, Drill Now!

2008-06-17T02:36:27Z

I guess if you sit and wait long enough, someone will do something to solve a problem. In my eyes, the problem is our dependency on foreign oil. There are two angles of attack to solve the problem. First, reduce our dependency on oil regardless of source through alternative fuels. This is a great idea and it's awesome to see work done in this area, including my uncle creating a home-brew hydrogen cell as an example. Second, increase our production of oil so we don't need to depend on foreign sources. If both of these could be done at the same time I think we'd be well on our way to solving the problem for good.

Not much is needed to increase our production. The oil is there, we just need to go get it. To that end, I came across a petition earlier which was started by Newt Gingrich called "Drill Here, Drill Now, Pay Less" which is meant to collect signatures which will be presented to the Senate. He's already delivered 350,000, and the site is up to 805,000. One of those signatures belonging to Chuck Norris! Take a look at americansolutions.com and sign the petition if it looks like a good solution to you!