I resolved the issue. It appears based on the Microsoft Knowledge Base information that:
Some document-conversion services in SharePoint Server are not secure when they run in a particular environment
In order to allow the services to continue to run, the following registry key needs to be added:
im presuming that the feature is in a wsp so you should be able to do this:
Update-SPSolution –Identity YourSolutionName.wsp –LiteralPath “C:\YourSolutionName.wsp” –GacDeployment
forgot to mention you need to change the version number ;) for a more finer detail you can follow this:
In this scenario you have to be clear about ,
If the solution contains the same set of files and features , that
is no new features or files been added in the existing Installed
solution then you can use
2.If any new files been added or features been in the existing installed solution then you you need to foloow below steps:
Based on the information found on this blog you actually have to attach to the PowerShell process if you upgrade your feature like you did.
. Simply pressing F5 in Visual Studio will deploy the solution, launch the browser window and attach the debugger to the w3wp.exe process.
However, upgrading the feature is done in PowerShell. Running the PowerShell ...
I implemented similar behavior some time ago, I used xml file with following structure:
<?xml version="1.0" encoding="utf-8" ?>
You can call Upgrade method on desired SPFeature object.
Depending on the feature scope you might need different code to fetch that SPFeature object.
Example for site scoped feature:
$id = new-object System.Guid("<feature_id_here>")
$site = Get-SPSite "<site_url_here>"
$feature = $site.Features[$id]
Interesting. It had to do with how I was accessing the SPListItem objects. I needed to explicitly get myList.Items[i] as an SPListItem.
Once I changed the inner part of the for loop to be
// loop through items by index instead of foreach to avoid the "collection was modified" error
for (var i = 0; i < myList.ItemCount; i++)
SPListItem item = ...
There are only a few instances where you get any real benefit from the CompatibilityLevel having both 14 and 15. If you have a solution where you are adding ghosted files to a site, you will get health analyzer warnings that the files don't exist in the 15 HIVE if you only deploy in 14 mode. Another instance is having site definitions for both 2010 and ...
I am here considering that you are asking about the upgrading sandbox solution's features.
To update the solution in SharePoint Online, first we will need an
updated WSP. It should have the relevant sections specified in the
UpgradeActions Feature XML element.
Kindly check below article which describes the same.
Install and Update Sandbox Solutions ...
We had the same problem couple of months ago, after digging too much we open a MSFT case. Here how we solve it.
After updating the wsp, we check if new dll deployed.
We also check if updated DLL loaded
Recycle the SharePoint timer services on all servers.
We use the decompiler tool to find which assembly loaded.
In our case, even after updating( many time ...
We have exactly the same case as yours, our production and beta environments are not in our hand and we have to do deployments using WSP solution package (even if those are updates to existing solutions)
We also use content types, site columns and list definitions and instances, all declarative..
For the updates (I'm not sure if this is the best method but ...
I was still having the same error, even after adding the registry entries.
It turns out that the Net.Tcp Port Sharing Service was disabled, once I enabled it and started, I re-ran the Configuration Wizard again and it went past stage 5.
Since you have custom Site Definitions in your 2010 environment, you need to address these first. Especially if you plan to use them in your 2013 environment.
First step in porting the custom site definitions to SharePoint 2013 is to identify what site definitions will cause the upgrade to fail and prevent the self service site collection upgrade. Unless ...
I tried the same thing. But as we do not have any means to upgrade the feature in O365 still I wrote the UpgradeActions tags in the feature.xml anyway. But as expected it threw an exception.
Then it struck me that whenever you go to update the wsp in SharePoint Online, it asks you to deactivate and upload then activate again.
Deactivating the wsp causes ...
Lists defined via XML get wiped out if you choose "Deploy" from Visual Studio, but remain intact using Update-SPSolution. If you are only changing deployed files, pages, or code in your assembly, your changes should get pushed through with an Update-SPSolution.
The only thing you may need to consider is that files that were deployed to SharePoint via ...
Usually when you have to do a deploy (install, upgrade, enable/disable features, and so on) you want do that with a Powershell script written before.
In this way you will be able to check your feature (hidden or not), disable it (if you can), upgrade, and etc.
Instead of having a completely new feature, as Arsalan proposes, you can use the Feature Upgrade framework (which is actually mentioned in a comment by tyshock above).
Basically, what you have to do is using the Feature Version attribute, and then implement code to handle the FeatureUpgrading event in a Feature Event Receiver. See best practices here
For such cases, we usually have a Code Upgrader feature which adds new columns to the list, set default values and so on..
You need to grab the existing list and add the new columns, it should work fine.. And you just need to activate this Code Upgrader Feature
Although Ali Jafer gave a very comprehensive answer but in my case these commands using Feature Name did not work. I used Feature ID and here is how my powershell commands look like.
Update-SPSolution –Identity "Example.wsp" –LiteralPath "E:\Visual Studio 2015\Projects\Example.wsp" –GacDeployment
$featureId = new-object System.Guid("FeatureID here")