Powershell Error: Cannot uninstall the LanguagePack 0 because it is not deployed.

Powershell: languagepack 0

Have you ever run into this, very non-descriptive and weird SharePoint error message “Cannot uninstall the LanguagePack 0 because it is not deployed”? You could encounter it while running some PowerShell scripts – most typically, when trying to update a wsp solution.

I have, and luckily often easily solved!

Symptoms

Assume you’re trying to install, update or uninstall a SharePoint solution (.wsp package) using PowerShell-commands Install-SPSolution, Update-SPSolution or Uninstall-SPSolution (respectively). Operation fails with the following (or similar) error:

Error: Cannot uninstall the LanguagePack 0 because it is not deployed

I have actually seen this also in the form of “Cannot uninstall Language Pack 0 because it is not deployed”. However, I think the more relevant form of the error is the one that pops up in the PowerShell. See below for an example!

Error "Update-SPSolution : Cannot uninstall the LanguagePack 0 because it is not deployed."

Error “Update-SPSolution : Cannot uninstall the LanguagePack 0 because it is not deployed.”

In Central Admin the solution is in Error state.

151117_ca

Problem

Not really clear, to be honest – most likely, it’s an issue in how SharePoint localizes some of the content types or other declarative artifacts.

Solution

You can find quite a lot of solutions online, but they weren’t really working for me. I tried restarting services, removing the package and meddling with the dll-files, but to no avail. However, the actual “last operation details” on the CA page hinted, that the problem was in fact in one of the features. The feature in question included some content types, and toying around with them is like playing baseball with hand grenades, so you have to tread carefully in cases like these.

Continue reading

“Server Error in ‘/’ Application” or “Parser Error” – it’s actually a malformed web.config killing your ASP.NET-application or SharePoint

Malformed web.config causing a Parser Error

This post describes how to resolve a kind of cryptic and oddly misdescriptive error message about Parser Error on your ASP.NET application or (On-Premises) SharePoint site. I ran into this after deploying wsp-packages to a SharePoint farm, but you can apparently get this on ASP.NET MVC sites, too.

Symptoms: Parser Error from a random-looking location

Once you navigate to your web- or SharePoint site, you only get an error like this:

Server Error in ‘/’ Application.

Parser Error

Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.

Parser Error Message: Index was outside the bounds of the array.

The next few rows (the actual source of the error) seem to vary wildly. The exact source depends on what went wrong in the parsing or latest deployments. In any case, they’re usually something like this:

Parser Error
Line 3: <WebControls:XmlUrlDataSource runat="server" AuthType="None" HttpMethod="GET"> 
Line 4:  <DataFileParameters> 
Line 5:   <WebPartPages:DataFormParameter Name="RequestUrl" ParameterKey="RequestUrl" PropertyName="ParameterValues"/> 
Line 6:  </DataFileParameters> 
Line 7: </WebControls:XmlUrlDataSource>

Okay, that doesn’t tell us that much! So how to get rid of it?

Continue reading

Quickest way to download all the wsp-packages in a SharePoint farm

PowerShell logo

Sometimes – pretty often in the good old on-premises world, actually – you’ll need to have a copy of all the packages that are deployed to a certain farm.

So – how to download all of the deployed farm solutions (essentially, cabinet files renamed to .wsp) from a farm? Luckily, it’s quite easy!

Solution

To download all deployed farm solutions (wsp-packages) from a SharePoint farm is pretty simple using PowerShell. No need to download individual packages through cumbersome interfaces! You don’t even have to open the Central Administration! 🙂  Continue reading

Simplest way to create a thread on SharePoint

Stock photo from pixabay.com

This post describes the (probably) easiest and most straightforward way of creating a new Thread in your SharePoint (or any other .NET) server-side / desktop code.

Solution: how to create a new Thread

Let’s face it – one should not create new Threads lightly when developing SharePoint solutions, but sometimes it’s difficult to avoid. Or sometimes it’s just the simplest way to get around weird framework limitations. Continue reading

Programmatically creating readable internal names for new SharePoint fields

SharePoint Field Name Problems

This post is about a small programmatic workaround to creating new SPFields for SPLists in SharePoint with human-readable internal names. This is mainly a usability improvement for your editors (and doesn’t change your life that much), but at the very least they will probably appreciate it!

In short, I’ll show you how to avoid SharePoint’s dirty encoding (like replacing a space with “_x0020_”). This appliesto when you’re using server-side code to generate fields.

Problem: non-readable internal names for SharePoint list fields

When you create a new field in SharePoint, SharePoint accepts the following syntax:

string internalName = list.Fields.Add("Field name - in a readable way.", SPFieldType.Text, false);

However, this will result in the internal name to be something like “Field_x0020_name_x0020__x002d__x”. That’s not super readable, but rather quite horrible to look at, or use anywhere at all. It actually mostly consists of dirtily encoded characters, automatically generated by SharePoint.

The worst part is that all this actually doesn’t only mess up the internal names of fields created programmatically. Also when creating fields using the SharePoint GUI, you get the same kind of malformed internal names.

These horrible internal names will haunt you in all reports, when doing things programmatically, using CAML or configuring things. Not good! Not fun.

Luckily, there’s a nice and straightforward way to solve this issue and produce nice and readable internal names for SharePoint list fields!  Continue reading