24 September 2010

How do I – Install FeatureBuilder for Visual Studio 2010 Ultimate

FeatureBuilder is an awesome addition to Visual Studio.  If you wish to give it a spin (highly recommended by the way), it’s easy to do.
  1. Start by getting the Visual Studio 2010 SDK located here:http://www.microsoft.com/downloads/details.aspx?familyid=47305CF4-2BEA-43C0-91CD-1B853602DCC5&displaylang=en 
  2. Double click the installer.  On the dialog prompt, click “Run”.

  3. On the Welcome screen, click “Next”.

  4. On the EULA screen, click the “I accept the terms of the License Agreement” check box and click “Next”.<

  5. On the Destination page, accept the defaults and click “Next”.

  6. Wait while Setup installs the SDK.

  7. Once the SDK installation is complete, click “Exit”.image18_3A0AA7BD
  8. Now go ahead and get the FeatureBuilder vsix by downloading it from here:

  9. After downloading, double click the .vsix file.
  10. When prompted to open with an application, select Visual Studio and click “OK”.

  11. On the Target page, select Visual Studio 2010 as a target for the vsix install.
  12. Click “Install”.

  13. Wait while the extension is installed.

  14. Upon install completion, click “Close”.

Start using and enjoy FeatureBuilder!  In future blog articles, I’ll show you how to use FeatureBuilder.


22 September 2010

Things that make you go hmmm

I saw this list of the supposed top 50 influencers in the SharePoint world as far as Systems Integrators/Consultants are concerned…

Now I can go into a long outburst over how they picked their criteria etc. for the list, but I won’t. I agree with SOME of the names on this list. My friends Andrew Connell and Scot Hillier absolutely belong on this list, as does long time SharePoint genius Ted Pattison, but some of the people on this list, I don’t even recognize… and I have been in the SharePoint world for almost a decade now… Lots of notable names are not on this list, like Todd Baginski, Gary LaPointe, Robert Bogue, Bil Simser among others… Suffice it to say, I think the list isn’t correct. Now before I get accused of bias, I’ll prove my point simply… riddle me this…

Is ANY list of the Top SharePoint influencers complete or correct without… Joel Oleson???


03 September 2010

How do I – Resolve the failure to load a module into PowerShell when using the Import-Module cmdlet

If you’ve ventured into the world of PowerShell extensions and modules, and more specifically, that world, targeted at SharePoint, then you have probably run into this error before.
Import-Module : Could not load file or assembly 'file:///C:\cjvandyk.SharePoint.PowerShell.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. At line:1 char:14+ import-module <<<< .\cjvandyk.SharePoint.PowerShell.dll + CategoryInfo: NotSpecified: (:) [Import-Module], BadImageFormatException + FullyQualifiedErrorId : System.BadImageFormatException,Microsoft.PowerShell.Commands.ImportModuleCommand
This error is thrown by PowerShell when you are using the Import-Module cmdlet to import a PowerShell module (redundant, isn’t it?) that was built using the .NET Framework 4.0. The ugly error looks like this:


If you’re trying to use that module on a SharePoint system, the odds are that the server does NOT have the 4.0 version of the Framework installed. You can easily confirm this by simply checking the sub folders under the C:\Windows\Microsoft.NET\Framework location.


In the above example, you can see that 1.0, 1.1, 2.0, 3.0, 3.5 and 4.0 are all installed on the server. If you find that 4.0 is NOT installed, you can quickly install it following this guide.
Once it’s installed you only have one more thing left to do. By default, PowerShell will run under the 2.0 Framework. We need to force it to default to the 4.0 Framework and only revert back to 2.0 if it doesn’t find what it’s looking for in 4.0.
That is easily done using a .config file for the PowerShell executable. Browse to the C:\Windows\System32\WindowsPowerShell\v1.0 location.


You may not have the two .config file on your system. If you don’t, you need to create them manually. Name the files exactly the same as the .exe files, but with a .config extension at the back. Create them as text files, but you will need to show extensions from your Folder Options in Windows Explorer in order to get rid of the .txt extension. The two config files should be named “PowerShell.exe.config” and “PowerShell_ise.exe.config”. The content of the two files is a simple XML snippet that simply points PowerShell to default to 4.0 and fallback to 2.0. Copy and paste the following snippet into the .config files.
Now when you restart PowerShell, attempting to load your module should yield no errors (if your module is compiled correctly and valid), and you should be able to implement the functionality from the module without any problem.


Installing the .NET Framework 4.0 on your Windows Server 2008 R2 x64 server with SharePoint 2010

As we all know, SharePoint 2010 is still using the .NET Framework 3.5.  That means that your servers may not have the latest .NET Framework 4.0 installed.  This could cause some issues if you’re trying to use APIs from 4.0, or if you are trying to build some new tools using 4.0, like PowerShell management extensions for example.  The solution is to install 4.0 on your server.  Here’s the quick Step-by-Step for doing this on a Windows Server 2008 R2 x64 system with SharePoint 2010 installed.
  1. Begin by downloading the full version of the Framework from here:
  2. Once downloaded, double click the installer file named “dotnetFx40_Full_x86_x64.exe”.

  3. Windows may require you to confirm that you wish to launch the EXE.  If it does, simply click “Run”.

  4. You’d have to accept the EULA.  Check the “I have read and accept the license terms” check box.
  5. Click the “Install” button to commence the installation.

  6. The installer will crunch away for a while as it installs the Framework.

  7. Once installation complete, click the “Finish” button.

  8. No server restart is needed. 🙂


SharePoint Remote Event Receivers are DEAD!!!

 Well, the time has finally come.  It was evident when Microsoft started pushing everyone to WebHooks, but this FAQ and related announcement...