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

Powershell: languagepack 0

Thi s post offers a solution to the very non-descriptive SharePoint error message “Cannot uninstall the LanguagePack 0 because it is not deployed”, which might appear while trying to update a wsp solution.

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:

I have actually seen this also in the form of “Cannot uninstall Language Pack 0 because it is not deployed”, but I think the other form of the error is the one that pops up in the PowerShell.

Powershell: languagepack 0

In Central Admin the solution is in Error state.

151117_ca

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

Malformed web.config killing your ASP.NET-application or SharePoint (“Server Error in ‘/’ Application” or “Parser Error”)

Malformed web.config

Symptoms

Once you navigate to your site, you only get en 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 (source of the error) seem to vary wildly, but they’re 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>

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 Thread

Let’s face it – one should not create new Threads lightly when developing SharePoint solutions, but sometimes it’s difficult to avoid. This one time we were developing a pretty simple functionality, where we needed to create a few fields on a certain title when user activated a feature. However, because of the complexity of the environment, we encountered problems changing the title of the new field. Now, it’s usually pretty simple, but this time some other functionality, most likely developed by someone else, was changing it to the internal field name – which doesn’t look to good.

To be honest, we’re not even sure, why this worked. We suspected it might be because of the current culture of the thread, but changing it didn’t have any effect. Any way, we’re glad this worked, whatever the reason for that is.

Programmatically creating SPFields with readable internal names

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 an usability improvement for your editors, but they’ll probably appreciate it!

Problem: non-readable internal names for SharePoint list fields

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

However, this will result in the internal name to be something like “Field_x0020_name_x0020__x002d__x” which is hardly readable, but rather quite horrible to look at, or use anywhere at all.

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

Solution

If you need to get readable internal names (like when your editors actually use the internal names for something) for your fields, you can use a code similar to this:

Continue reading