Importing PowerShell Modules from GAC DLLS in order to use their CmdLets

What I am writing here is nothing new, just a consolidation of attempted answers I found when trying to do as the title of this post describes.  Now to set the stage, this is a DLL deployed as part of a SharePoint solution which is why it gets dropped to the GAC and then the CmdLets are used to configure the solution once the SharePoint WSPs are deployed.

Import-Module will take a full path to a DLL in the GAC or anywhere in order to use the CmdLets within it, but I didn’t want to be mucking with resolving the GAC path for a DLL, I just wanted to give it the assembly name without version and what not.  In looking at other people comments to loading DLLs with partial name, the obvious “LoadWithPartialName” was mentioned, however that will load the DLL into memory, but doesn’t load them as modules for CmdLet use…

Chaining the two commands together does work nicely though:

$assembly = [System.Reflection.Assembly]::LoadWithPartialName(‘MyProject.PowerShell’)

Import-Module -Assembly $assembly

New-ObjectToPerformTask -Url $url

It’s nothing special, but a nice complete way to load PowerShell cmdlets using partial names from the GAC, so its great for SharePoint deployed DLLs.

 

Advertisement

Refreshing SPWeb object during enumeration

This arose for me during a PowerShell script, when I had to enumerate each web, add a field to the content types used by a particular SharePoint List in each web, and then query the list items to set the values for that newly added column.

Updating the content types (including child types) was fine, however since I had already accessed the List’s content types to find the root types, the changes made weren’t reflected in memory within the List object. Attempts to update the list items for the newly added field failed with an error that they don’t exist or may have been deleted, even if I queried the new field specifically.

Getting the List again didn’t seem to help, and calling Update on the List threw a save conflict (possibly because the List’s instance of the content types had just been updated by the hierarchical save from the parent content type).

I didn’t want to just reopen the web since I was enumerating them and that would have required alot of messy code to track where I was and use more memory doubling up the references to the web (every little bit matters).

Unfortunately SharePoint doesn’t provide a way to “refresh” the in memory objects, I guess since they usually have very short life spans.

It does however provide a Close method, but no open method. Well after a bit of decompiling I found that there are a handful of properties that will trigger the same internal initialization as opening the web the first time. I decided to try the one with the smallest footprint, Exists.

So with the code (PowerShell, but would be same in C#, etc):

$spWeb.Close()
$exists = $spWeb.Exists

I was able to make some heavy changes, then Close and reopen the web (via Exists), and run some queries and updates, all without mucking up the web enumeration (for each loop in this case).

Essentially, a SPWeb re-open procedure maintaining the same SPWeb object referenced in memory.

SharePoint – An unexpected error has occurred or Object Reference Error in a site collection after reattaching a Content Database

After removing a content database from a SharePoint 2010 web application, so that I can restore a backup (for development purposes), upon reattaching the content database I was being plagued with an assortment of error message.

These included when trying to load the site, seeing both an “An unexpected error has occurred” and a simple server information block returned, and upon checking the logs seeing:

“System.NullReferenceException: Object reference not set to an instance of an object.    at Microsoft.SharePoint.SPSite.PreinitializeServer(SPRequest request)”

This would occur on a single web front end server in the development farm (yep, I have multiple WFEs in my development environment), while the other WFEs would load fine.

After a couple different investigations, I found out that one cause of single server site corruption after reattaching a SP content db is… it’s the PowerShell SharePoint CmdLets.

If you are running PowerShell and are using the SharePoint CmdLets (SPSite for example) to connect to that site (for the content database in question), if you try to reattach the content database while that PowerShell session is still open, the reattach goes fine, but the servers where PowerShell was open will fail load the site thereafter… even after reboots and all.

You need to close the PowerShell window and then reattach the content database (either by the Central Admin UI or from a new PowerShell window if you are using scripts).

Additionally, the W3SVC and SPADMIN and SPTIMER services can all cause the same problem, so I have found that restarting those also (I bundled it up into a single PowerShell cmdlet) ensures that I never saw this issue again.