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:
When you install the executable for a Cumulative Update (CU), you have not actually upgraded your servers yet. The PSConfig.exe (Command Line), or the SharePoint Products Configuration Wizard (GUI), will need to be run to upgrade both the running binaries, and make any changes to the SharePoint database schemas provided in the CU.
In this case, you have the ...
You could loop through all the existing sub-sites with a PowerShell script, and use the feature cmdlets to activate the feature on existing sites. Using this method you could also insert some logic/conditions to enable or not enable the new feature if that is useful.
While it is possible to upgrade features while upgrading solution, it is a very bad practice, so only consider this as a warning of how not to do it:
Using -force parameter on Install-SPSolution will force solution to be installed and underlying features to be enabled even if they were already enabled. Forcing a feature to be enabled will also trigger ...
As Chris explains in Feature upgrade (part 1) - fundamentals
Feature upgrade does NOT happen automatically (including when the
Feature is deactivated/reactivated)! The only way to upgrade a Feature
is to call SPFeature.Upgrade()
So, on first deployment you'll activate the Feature and the Feature_Activated event will run.
Now you make some changes ...
If you wanted to do it the "right" way then you should have used Feature Upgrading.
It's unfortunately not simple but gives you a lot of control of what happens when you deploy a new version of a feature.
In your case it would have involved:
Add the elements.xml files for the new web parts inside <ApplyElementManifests> inside <UpgradeActions> ...
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]
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 ...
You should use Feature Upgrading to register the new EventReceiver.
Just creating the code will not tell SharePoint to call the EventReceiver you have to do that in either an Elements.xml file using <Receivers> element or through code by creating a new element in the right EventReceivers collection
For the following examples assume you're upgrading ...
You will need to re-activate the web parts from web part Gallery
go to site Actions> Site settings
under Galleries > Web parts
in the Web parts Gallery documents >new document
you will fine the new web parts select the new web parts and click Populate Gallery
in the new web part Edit Properties Change the group to Custom and click save
after that you will ...
I've found updating wsp's can be a little tricky sometimes. Sometimes doing a full Uninstall-SPSolution/Remove-SPSolution will help if you are experiencing strange behavior.
In my experience deploying form visual studio usually goes off without a hitch. Because of this, I will try to match it's deploy process as closely as possible if I am having a deploy ...
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.
I implemented similar behavior some time ago, I used xml file with following structure:
<?xml version="1.0" encoding="utf-8" ?>
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 ...
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 = ...
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")
I had faced the same problem. I used the Install-SPFeature command after Disable-SPFeature and it worked for me.
Write-host "Disabling Web Parts feature" -ForegroundColor Cyan
Disable-SPFeature "Intranet.WebParts_Site-WebParts" -Url $site.Url -confirm:$false
Install-SPFeature "Intranet.WebParts_Site-WebParts" -Force
Write-host "Enabling Web ...
You need to develop what I call a "service pack" to deploy against the existing sites. In this case your service pack would contain a module with the site pages and any other resources that might be required.
If your solution is only adding new artifacts to the site, the process is pretty straightforward. If you are changing things like list structures, ...