If you’ve been developing custom web parts on and off for a while, more often than not you’ve seen this particular error pop up from time to time:

“Error occurred in deployment step ‘Add Solution’: A feature with ID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX has already been installed in this farm. Use the force attribute to explicitly re-install the feature.”

And this happens because you’ve been working on this particular webpart or feature, you’ve deployed it, you’ve made changes to it, and now you want to deploy it again to a site that already has that feature installed.

When working with Visual Studio, I usually have my deployment/debug do the full install and retract of the solution so won’t see this too often since the feature/solution is removed every time I stop debugging – however developers don’t always have that luxury in an integration or QA environment.  Or sometimes we need to go through the Central Admin UI to schedule our deployment.

Quick sidebar here…. let’s face it, the Update-SPSolution command is just about worthless for anything but the most minor of changes, which I think even Microsoft admits to:

“The Update-SPSolution cmdlet upgrades a deployed SharePoint solution in the farm. Use this cmdlet only if a new solution contains the same set of files and features as the deployed solution. If files and features are different, the solution must be retracted and redeployed by using the Uninstall-SPSolution and Install-SPSolution cmdlets, respectively.”

Now usually when this error pops up to block the deployment it’s easy enough to drop into PowerShell on the server and pull out our handy-dandy PowerShell toolkit and do our own “-Force” on Install-SPSolution in order to get this deployed onto our farm/sites.  But depending on your environment you may not be able to do the recommended uninstall/reinstall or use PowerShell on the server in order to pass the commandlet a -force flag.  This might also occur when you have SharePoint admins who need to deploy the features  from Central Admin and don’t have access to remote onto the servers.

But, there’s an easier way…you build it into your solution from the start.

Within your Visual Studio project, go ahead and expand your Features node and find the .feature item and double click on it.

Then go ahead and modify the manifest by clicking on the Edit options.

https://msdn.microsoft.com/en-us/library/office/ms475601.aspx

When you look at the <feature> element it has a lot of interesting attributes, the one we’re interested in is “AlwaysForceInstall”

AlwaysForceInstallOptional Boolean. TRUE if the Feature is installed by force during installation even if the Feature is already installed. For example, if set to TRUE, Feature deployment event handlers will always fire anytime a user tries to install the Feature (even if it is already installed) by using either the scanforfeatures or installfeature command-line operation. This attribute equals FALSE by default. The AlwaysForceInstall attribute affects Features of all scopes.

Just add the attribute AlwaysForceInstall=”TRUE” to your <feature> element and now every time that you deploy your solution if will always assume the -Force flag parameter, even if you are doing your deploy from Central Admin.