David Frette's Blog

Where the mind and SharePoint sometimes meet.

An error occurred during the compilation of the requested file, or one of its dependencies. ; expected

Posted by David Frette on February 11, 2013

On one of my current SharePoint/ASP.NET projects, I started receiving this error:
An error occurred during the compilation of the requested file, or one of its dependencies. ; expected.

To solve this, I started removing chunks from my ASPX page until the exception went away. The cause?
It was a typo. I needed to use and forgot the =.

My faulty code:

Working code:

Posted in ASP.NET, JavaScript | Tagged: | Leave a Comment »

SharePoint 2013 training for developers

Posted by David Frette on July 26, 2012

SharePoint 2013 training for developers



Note: Thanks to Brian Bedard for sending me this link.

Posted in Uncategorized | Leave a Comment »

SharePoint Server 2013 Download

Posted by David Frette on July 16, 2012

Some valuable SharePoint 2013 links

SharePoint Server 2013 Download

SharePoint 2013: presentation: IT pro training

SharePoint 2013 Software Requirements

Eric Harlan’s Installation blog post

Downloadable eBook: Deployment guide for SharePoint 2013 Preview

SharePoint 2013 training for developers

Please note: If you’re building a new VM, be sure to check out the requirements. For instance, you’ll need SQL Server 2008 R2 SP1.

And get used to building new machines for your upgrades. The only way to upgrade to SharePoint 2013 is via content database migration. In other words, you need a new 2013 farm. No more in-place upgrades (for those of you who’ve actually done one).

Posted in Uncategorized | Leave a Comment »

SharePoint 2013 Beta was just announced

Posted by David Frette on July 16, 2012

If you haven’t already heard, SharePoint 2013 has been announced. If you want to play with it, log on to msdn and download the img file.

I’m looking forward to using the new application deployment model with Windows Azure.

I wonder if MS will have improved upon the Managed Metadata Service. If not, I may just take it upon myself to do so!

Posted in Uncategorized | Leave a Comment »

Posted by David Frette on June 13, 2012

Here’s the deal, sometimes when you write SharePoint code on your dev machine, it deploys just fine. When you package it and deploy it on another server, it doesn’t always work so hot. Furthermore, you might sometimes experience this exception on dev box:

Error occurred in deployment step ‘Add Solution’: Failed to load receiver assembly “…”.
System.IO.FileNotFoundException: Could not load file or assembly ‘…’ or one of its dependencies. The system cannot find the file specified.
at …
at …
at Microsoft.SharePoint.Administration.SPFeatureDefinition.get_ReceiverObject()

So what’s going on here? Well, it’s quite simple, and yet, it is almost haunting. The fact is, Visual Studio doesn’t always pick up your changes when it builds your solution. It seems to think that that if you haven’t changed the code, when you build your solution it shouldn’t compile a new DLL. That annoys me because sometimes I actually need it to rebuild that DLL for me. If I tell VS to build, I’m thinking it’s going to recompile all of the DLLs for me (note to self: build != recompile). As my friend James S. says, “There’s your problem.” In other words, “stop thinking; start doing.”

So, I’ve been paranoid about packaging my code. First, I intend to clean up my dev box and run a test deployment on it as an ITPro would on his/her Test environment. Second, I deploy to a Test farm. So the goal in VS is to get a fully compiled .sln file. To confidently get that, I perform a manual clean, build, package, and then test it.

Here are my steps:
1. Right-click the project and Retract
2. Verify the feature is gone from the filesystem, the DLLs are no longer in the GAC, etc.
3. In Visual Studio’s Solution Explorer window, click Show all files
4. Control-click bin, obj, pkj, pkjobj
5. Delete and confirm delete
6. Right-click the project and Build
7. Right-click the project and Package

Now I know for sure that everything in the package is using the latest code, settings, etc.
And yes, I realize there is a Clean function. I don’t trust it. Do you?

Posted in SharePoint, Visual Studio | Leave a Comment »

Deploying Custom Help with SharePoint 2010

Posted by David Frette on June 6, 2012

Custom help in SharePoint 2010 is not difficult to install, once you’ve been through it. I found some helpful blogs for using the SharePoint utility HCInstall. However, I didn’t want to use a command-line utility on a FeatureActivated receiver. So I decided to dig into it and see if I couldn’t just do in code what it does. If you intend to install help thru an install script, use the utility provided by Microsoft. If you intend to install help thru features (ie, install help on demand as needed), then this post is for you.

If you haven’t used HcInstal, no worries. I’d like to walk thru what the HCInstal.exe code does. It’s not a lot, actually. You can use it as a stand-alone utility. Or, you can drop it in your project with a Reference.

By doing so, you’ll need a using declarative, namely Microsoft.SharePoint.Help.HcInstaller.


Hcinstall has one public class (HcInstaller_Main) and one internal (HiGovernor). Here’s an adjusted view from Reflector.

The real work is done in ParseArgs and StartIt().

* ParseArgs() does just that, parses the command line arguements, or your arguements if you’ve referenced the EXE in your project and utilized the HcInstaller_Main class’ Main() method.

* StartIt() then uses the SharePoint help object model. Did you know that it existed? In the online SharePoint 2010 SDK, found on MSDN here SharePoint help, there is little reference to it. [Notice it's found in the Administration section. However, the namespace is not within the Administration namespace, and the dll containing the namespace is not the Admin dll, either, it's just the Microsoft.SharePoint.dll.  Back to our work...]  So StartIt() then does the work based on the arguments. If you chose to install a help file, then it calls the Microsoft.SharePoint.Help.SPHelpMerge() method. The SDK content is here, SPHelpMerge. Notice there is no SP2010 version of this SDK helpfile, which is a bummer. But that’s okay, it appears that nothing has changed in it.

The SPHelpMerge class has 4 main methods.

  1. InstallOneHelpCollection
  2. InstallAllHelpCollections
  3. UninstallOneHelpCollection
  4. UninstallAllHelpCollections

In my current testing, I have not found UninstallOneHelpCollection to work. So, on my vm, I’m using UninstallAllHelpCollections for removing the help collections. I’ve noticed this carries thru to hcinstal.exe ( hcinstal.exe /act uninstallonehelpcollection) as well. If anyone has any info on this, I’d appreciate it.

For now, however, I’m using the SPHelpMerge.InstallOneHelpCollection() and it’s working great. If you need a sample help collection to install, you can start with this one from Code Project

Using the SPHelpMerge class, you’ll have code like this:

Using the SPHelpMerge class to install an HCCab file. Do NOT include the .HC.cab in the parameter as it is for namespace not filename.

The parameters are hardly documented. Changing most of them did not affect my install.

And there you have it. It only takes a couple of lines of code to install your help content file! Now you can include these lines into a Farm-scoped feature wrapped up in a Visual Studio SharePoint Feature project, and viola!

Posted in SharePoint Help, Uncategorized | Tagged: , , , | Leave a Comment »

SharePoint Connections at the SharePoint Conference

Posted by David Frette on September 19, 2011

Mark Freeman posted an article on the social events at SPC.


Edit: If you have news of any other events, please post them in the comments and I’ll be sure to update this post and Mark will probably update his as well.


Posted in SharePoint Conference 2011 | Tagged: , | Leave a Comment »

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

Posted by David Frette on January 20, 2011

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
      + FullyQualifiedErrorId : RuntimeException

 then you can use

powershell -command "set-executionpolicy unrestricted" 

in the prebuild event before the -file command.

Posted in Uncategorized | Leave a Comment »

Versioning InfoPath Forms

Posted by David Frette on January 19, 2011

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

  = "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.

Posted in Uncategorized | 1 Comment »

SharePoint’s Field Level Security – The Overview

Posted by David Frette on January 18, 2011

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.

Posted in Uncategorized | Leave a Comment »


Get every new post delivered to your Inbox.