Creating Powershell pre-build and post-build events for Visual Studio projects

I had a need to create a cab file containing the files from two project folders, plus a file at the root. Instead of learning Visual Studio addins, I created a PowerShell script that ran on Visual Studio’s pre-build event.  Using the post-build would have meant that the cab file was created after the SharePoint wsp package. The pre-build event is the way to go here.  So, first thing I did was create a PowerShell script that in turn, created a cab file. This script makes use of the makecab utility that ships with Visual Studio. To create a cab with this utility, one needs a Diamon Directive File, or ddf. This file contains a set of instructions followed by a list of files.  I’ll post the script at the end of this article, but it’s not really my focus. What really got me tripped up was (1) getting powershell to run and (2) getting parameters into the script correctly – as it turns out, a space makes a difference!  Here are the steps:

First, to do this, you’ll need PowerShell v2 (or better). Version 2 contains the -File cmdlet, which lets you run a script (*.ps1 file) from a powershell prompt. If you run Windows Server 2008 R2, then you have PowerShell v2. Otherwise, you may need to download it.

 Second, you’ll need to set the execution policy. Assuming you are on a dev box (Visual Studio and all), you can set the execution policy to unrestricted, via set-executionpolicy unrestricted. To check your current policy, use get-executionpolicy.

Third, keep in mind Visual Studio is 32-bit, while powershell has both, 32 and 64-bit versions with their own policies. The 32-bit VS should call the 32-bit version of PowerShell. Here is a screenshot showing the different powershell prompts and different execution policies.

Fourth, here is my script that will render arguments to the console. Yep, that’s all it needs to do.

Finally, the passing of parameters from Visual Studio is quirky. When I used “($ProjectDir)” “($ProjectDir)\bin”  Visual Studio passed that to PowerShell as one parameter. When I added a space  “($ProjectDir) ” “($ProjectDir)\bin”  Visual Studio passed that as 2 parameters. Here are the screenshots.

Finally, here is the script that will make the cab file. It’s all about making the ddf file. Enjoy!!

Note: If changing the execution policy at a powershell prompt does not seem to work (ie, Visual Studio still returns an error such as:

------ Rebuild All started: Project: SPProject, Configuration: Debug Any CPU ------

Compile complete -- 0 errors, 1 warnings
  File C:\MakeHCCab.ps1 cannot be loaded because the execution of scripts is disabled
  on this system. Please see "get-help about_signing" for more details.
      + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordE
     xception
      + FullyQualifiedErrorId : RuntimeException

 then you can use

powershell -command "set-executionpolicy unrestricted" 

in the prebuild event before the -file command.

Versioning InfoPath Forms

Almost everyone working with InfoPath forms knows that each time they publish a form, it creates a timestamp and a version number for the template. In InfoPath, go to Form Options and you’ll see this dialog:

InfoPath Form Version Dialog

Well, if you need to keep track of the version number for your form, you can make it easy on yourself and others by adding a small field at the bottom of your form. Then in the default value of this field, insert the formula

substring-before(substring-after(processing-instruction()[local-name(.)
  = "mso-infoPathSolution"], 'solutionVersion="'), '"')

Formula for Displaying the version number of a form

Here is a simple screenshot that shows the control

InfoPath Form Version Control

 

And here is what it renders like (screen clipped a lot):

InfoPath version control rendered in InfoPath Forms Services

 

I hope this helps you keep track of InfoPath forms version numbers. I know it will me.

SharePoint’s Field Level Security – The Overview

If you’re like me, you’re very frustrated that SharePoint doesn’t have a way, out of the box, to handle field-level security.  However, there are several ways to extend SharePoint to make this happen.

1. Custom Field Controls
2. Custom Forms (Edit, Display, New Forms)
3. Custom Event Handlers

I’m going to cover each of these in seperate articles. They cannot be adequately covered in one blog post. Well, they probably can, but I cannot adequately cover them all at once!

To start, I’ll offer just an overview of each before writing up posts for each of them.

 

Custom Field Controls

These are the truest form of Field Level Security. No matter where the field is used, the control will apply the same security rules — whatever those may be, as this is a custom control you’ll write your own rules. This can be good, or bad. Imagine designing this control to work with multiple sites, site collections, even web applications. How do you design it to function properly across the entire farm?  Answer: you’ll have to wait until that blog post is written! Another issue with using custom field controls is that you have to write a custom control for each type that you’d like to have secured — types being single line of text, multiple lines of text, dates, booleans, etc.

Custom Forms

(Note: I’m focusing on the Edit Form)
The custom edit form is not one that is designed with SharePoint Designer. While you could design one-offs this way, we’re interested in scalable and repeatable designs. The custom edit form that we’re interested in designing is one that can easily be packaged and deployed. This method is more flexible, but isn’t the truest field level security. We’re going to look into custom templates.  This allows us to use a single control (ascx file) that works for multiple forms.  Just point your content type to this control, and viola! A secured edit form!

Also, one could create a custom form that is an application page, deploy it, and then point a content type to that form. TO do so, just update the Form’s <Form> xml node within the Content Type. While that provides a lot of flexibility in the code, ultimately, I’m not looking to replace SharePoint functionality here. I’m really just trying to get Field Level Security implemented.

Custom Event Handlers

Custom Event Handlers are my least favorite method of the three. On the plus side, they are by far the easiest to grasp and implement, they work for any content type, and they are the most familiar to SharePoint developers. So why are they my least favorite? Because they don’t provide any forewarning to the user that security rules exist. The user can interact with the control and seemingly make edits. But when they click the Save button, the security rules get applied, and suddenly the user is told they don’t have the priviledges to make their changes. Imagine making changes to a Word document or Excel spreadsheet, getting all the right info into it, and then when the user saves it, the application throws a message and discards the changes.  Not a great approach, IMO. Another negative is the hassle of dealing with Before and After Properties. Sure, those work for list items in most cases. But what about document libraries?  Document libraries require special attention because the ItemAdding and ItemAdded method must both be used, since AfterProperties aren’t available in ItemAdding while BeforeProperties aren’t available in ItemAdded.

Also, how do you handle the case where the user can update FieldA but not FieldB? Do you keep the changes for FieldA and not FieldB? How do you inform the userFieldA was indeed changed, but FieldB was not? Keep in mind, you can display a message if and when you use the Cancel. If you don’t Cancel the change, you can’t display the message. So you can discard all changes (in this case to A and B) and let the user know. Or, you can accept the change to A and not B, but the user won’t explicitly be told.

I’d love to hear your thoughts on these three options. Another type of workaround would be workflow, but that’s a lot of hassle.

OneNote 2010 Requires the Windows Desktop Experience

I’m trying to copy some code from Reflector into OneNote 2010. Unfortunately, OneNote requires the Windows Desktop Experience. What a bummer. Now my VMs need to have the DE feature installed.

Speaking at HDNUG

This Thursday, 1/13/2011, I’ll be speaking at the Houston .NET User Group, HDNUG. I’ll be speaking on SharePoint development.

I’ll update this post with the links that will be in my presentation.

Information Worker Virtual Machine:

http://go.microsoft.com/?linkid=9728417

There are about 20 videos here on Channel 9 for developers:

http://channel9.msdn.com/learn/courses/SharePoint2010Developer

More to come…