If it were up to Microsoft, farm solutions would be long forgotten, and not without a good reason.
Farm solutions are extremely invasive, they are not subject to any monitoring or resource allocation throttling, and they can create memory leaks and unexpected behaviors. Without any effort, they can bring down an entire SharePoint farm.
However, they are also the most powerful way to customize SharePoint. Although this saying is definitely overused, with great power comes great responsibility.
But as we know, despite the sandboxed solutions, the SharePoint Add-In model legacy code is still around, and for on-premise, farm solutions are still a fact of life. So how can SPDocKit help you deal with these troublemakers?
Back up current farm solutions
Using snapshots you take manually or the SPDocKit service takes, current farm solutions can be backed up in a location of your choosing. To back up your current farm solutions, follow these instructions:
- Navigate to the Backstage Actions Screen and click Load Farm Settings.
Image 1 – Backstage Actions Screen
- Under Mode, click Custom load mode. Click Next to continue.
Image 2 – Select Custom load mode.
- Under Options, select the Features and Solutions check box.
Image 3 – WSP Back up options
- Select the Back up and Analyze Solution Files check box and choose a back-up location. Click Next to continue.
- Under Target, select your preferred scope. Click Next to continue and start your loading process.
Image 4 – Select objects to load.
Please note that these settings do not apply to sandboxed solutions.
If you do not want to set this option every time you perform a load, you can set the default load options in Options dialog to apply your settings to the SPDocKit service and the default manual load.
To apply the default load settings, follow these instructions:
- Navigate to the Backstage Configuration Screen, then click Options.
Image 5 – Backstage Configuration Screen
- In the SPDocKit Options dialog, select Default Load Options.
- Select Back up and Analyze Solution Files check box and select a location for your solution files. Click Save.
Image 6 – Default Load Options
- After configuring these settings, your backed-up solutions will appear in the backup folder listed by date and time.
Image 7 – View your backed-up solutions.
Please note that redeploying an older version of a SharePoint WSP is not recommended if significant changes were made. On the other hand, having farm solutions provides us with some options when trying to deal with specific issues.
Analyze DLLs contained within the WSP
SPDocKit can inspect the DLLs contained within the WSP. There are two ways to access this functionality:
- The Solution Assembly Deployment Validation Tool
- The Best Practices report, which is available if the Backup & Analyze Option was selected.
Solution Assembly Deployment Validation Tool
The Solution Assembly Deployment Validation tool is used to find DLLs on your servers that differ from the DLL contained within the WSP. The compare process for a DLL within the WSP is repeated for each server if the DLL is deployed to GAC or for each Web Application zone (for each server, each deployed web app) if it is deployed to the web application.
The validator tool works on live data; however, you have open the Settings file to access the tool.
- Navigate to Farm Explorer > Farm > System Settings > Farm Management > Solutions on the Home ribbon.
- To extract the selected WSP in the grid from the SharePoint farm, click the Extract WSP button.This will work directly with the SharePoint farm and not the backed-up version.You can also do this in PowerShell:
$farm = Get-SPFarm
$file = $farm.Solutions.Item(“yoursolution.wsp”).SolutionFile
- After you open the Solution Assembly Deployment Validation tool, you can see your current solutions on the SharePoint farm.
Image 9 – Select a solution to determine whether the DLLs deployed on your servers are the same as the ones in the WSP.
In the preceding image, you can see that somebody messed with the DLL for the SharePoint Learning Kit on the SP2013-WFE1 server, replacing it directly in GAC.
Having a different DLL version on a single server can cause difficulties. If that happens, you should find the person responsible and determine the correct course of action. You can copy the DLL to all the servers to redeploy the solution if you can do so without repercussions. However, the SharePoint state could be incompatible with the old binaries and deployed artifacts. Whatever action you take, at least you know you might have a problem.
Sometimes an Error or Missing value can appear in the State column. In most situations, this means SPDocKit could not access the location where the DLL should be. To resolve this issue, please ensure that the user account running the tool has the necessary permissions to read from the file system for the servers in the farm. In cases such as this, you might find an answer in these articles.
Manually checking every farm solution in the Solution Assembly Deployment Validation tool is not how you want to spend your day. Instead, you can use the Best Practices report.
As with every best practice, Solution Assembly Deployment Valid errors will show up on the Best Practices Dashboard once you have loaded your farm or opened a previous snapshot.
As in the Solution Assembly Validation tool, click the item to see the Best Practices report and find out exactly what kind of problem you have.
The only difference is that in the report, all the solutions are shown in a single grid and the results apply to the time at which the snapshot was taken.
Again, we can see that SP2013-WFE1 has a different DLL than what was supplied in the WSP.
The future of farm solutions does not seem bright. But even as they fade away, we still have to deal with them. SPDocKit is here to help.
If you have any additional questions, feel free to contact our support.