Obfuscation, Code Analysis, and Check-In policies

As mentioned before, we’ve started to use SmartAssembly to obfuscate some of our products. We also use Team Foundation Server (TFS) as source control and build server. Using obfuscation with code analysis caused some issues, which were compounded by our check-in policies. Continue reading “Obfuscation, Code Analysis, and Check-In policies”

Obfuscation, Code Analysis, and Check-In policies

Adding SmartAssembly obfuscation to a Visual Studio Project

We’ve started to use SmartAssembly to obfuscate the code for some of the SharePoint products that we’ve been working on, and I’d had a few problems with it. Continue reading “Adding SmartAssembly obfuscation to a Visual Studio Project”

Adding SmartAssembly obfuscation to a Visual Studio Project

Getting levels of the SharePoint Heirarchy and their Exceptions

Something that I have to do time and again is get some element of SharePoint’s heirarchy, such as a site collection, site, list or item. This is pretty typical – that’s why we all use USING to ensure proper disposal of SPSites and SPWebs, right? But what happens if the thing you’re after isn’t there? What exception get’s thrown? Well, this should be pretty clear:

try
{
    //FileNotFoundException if doesn't exist
    using (SPSite site = new SPSite(siteGuid))
    {
        //FileNotFoundException if doesn't exist
        using (SPWeb web = site.OpenWeb(webGuid))
        {
            //SPException if doesn't exist
            SPList list = web.Lists[listGuid];

            //ArgumentException if doesn't exist
            SPListItem item = list.GetItemByUniqueId(itemGuid);
        }
    }
}
catch (System.IO.FileNotFoundException fileEx2)
{
    // Site or Site Collection Not Found
}
catch (SPException spEx2)
{
    // List not found
}
catch (ArgumentException argEx2)
{
    // Item not found
}

Hopefully that might prove useful to someone – and a good reminder for me.

Getting levels of the SharePoint Heirarchy and their Exceptions

Make Visual Studio break on all Exceptions

I’m a big fan of not raising exceptions if possible – rather than throwing and catching ‘expected exceptions’. To me, that phrase is an oxymoron – exceptions should be, um, exceptional, and it can make the wood hard to see for the trees when looking for proper exceptions.

Anyway, that aside – you can make Visual Studio break on any exception, not just the unhandled ones. Use Ctrl-Alt-E to edit – there is supposed to be some way to get to it though the menu, but I’ve not found it. Discovered in a blog post here.

Make Visual Studio break on all Exceptions

C# Code to send an email

I’ve been doing some testing of email enabled lists, and I needed to send quite a lot of emails, so I wrote a little console app to do it. Here’s the core of the code I used, in case I need it again, or it’s useful to someone. It uses System.Net.Mail:

SmtpClient smtp = new SmtpClient(@"vm-moss2007.virtual.local");
for (int i = 1; i <= 100; i++)
{
    MailMessage message = new MailMessage("administrator@virtual.local", <a href="mailto:testlist@sharepoint.virtual.local">testlist@sharepoint.virtual.local</a>);
    message.Subject = string.Format("Message {0}", i);
    message.Body = string.Format("This is message '{0}'", i);
    Console.WriteLine("Sending {0}", i);
    smtp.Send(message);
}
C# Code to send an email

Event Properties AfterProperties – what should they be?

While working on pre-filling ListItem fields on an item, I became a bit puzzled. The SPItemEventProperties.AfterProperties collection is a dictionary which can contain the named value for one of the fields of the item. In other words, if we wanted to set a value “Tax Area” to “Europe” we’d do:

properties.AfterProperties["Tax Area"] = "Europe";

In our case, however, we didn’t know what these properties were before hand. Rather, we were ‘inheriting’ values from a parent folder. Thus, we were going to use the parent folder’s SPField object for each field to define the value. I started out using:

properties.AfterProperties[parentField.Title] = parentItem[parentField.id];

But is Title the right property to use? Well, having looked through a number of blog posts, this seems to be the subject of some confusion.

At first Title is okay to use. However, you can change the display name of the field. For example, we could change our field’s Title to ‘Tax Region’ – but we still need to use ‘Tax Area’ in our AfterProperties collection.

So, InternalName is the right property of the SPField to use – but there is a hiccup. The InternalName is encoded – Tax_x0020_Area – so you have to unescape it like I’ve talked about before.

The summary is, then, use the unescaped InternalName in your AfterProperties collection.

Event Properties AfterProperties – what should they be?