Deployment Issue with Custom FIeld Types

Question

SHORT DESCRIPTION

Custom Field Types are not being correctly deployed/activated on all but one Virtual Machine.

1. I have several VMs with identical SharePoint environments.
2. I have a Visual Studio solution with 8 projects.
3. I can deploy and activate all of the features from each project.
4. Only one of the VMs successfully creates the actual field types in the SharePoint environment for use in Lists and Libraries.

LONG DESCRIPTION

So I have this solution that is using several custom fields that I have created.

I have created several projects in Visual Studio that I am trying to have all deployed at once from a single deployment project called Deployment. In my deployment project I have included all of the features from my other projects and have also added a Feature Receiver to the main Deployment project for the FeatureActivated asynchronous event that handles the creation of several lists, a Document Library, a bunch of Content Types, creates and assigns lookup fields to various lists and adds about a half dozen custom fields to my Document Library.

The issue is that the VS project (called "Controls") that defines all of the custom fields (including all related controls, editors and form templates) must be deployed before the main Deployment project because when the FeatureActivated event is fired from the Deployment project's EventReceiver it will attempt to programmatically create a Document Library which references the custom fields from the Controls project and if the Controls project and it's features are not deployed and activated first then the custom fields will not exist when the Deployment project attempts to reference them in it's FeatureActivated EventReceiver code.

I do not wish to have the Controls project as my main deployment project because of all the other "order of operation" and dependency issues. The primary goal of creating the Deployment project in the first place was so that I could consolidate and streamline the entire deployment process.

It also seems that no matter how I configure the package deployment and Feature Activation Dependency settings all of my requests seem to be ignored! I have tried manipulating the project build order, I've even installed the MaventionActivateSelectedFeatures Visual Studio Add-In extension to use in a custom deployment configuration that activates on specific features as opposed to the all-or-nothing approach that VS limits me to. By using this extension I can essentially deploy all of the features and then purposely activate all of them EXCEPT for the Deployment Feature that contains all the code to create the document library using the custom field types that were deployed in the Controls project. I then have a post-deployment command run which executes a PowerShell script that takes care of programmatically activating the final Deployment feature. My thought was that this should guarantee that the Controls feature containing the custom field type gets properly deployed and activated prior to being referenced by the Deployment project's FeatureActived event. Again, this works on my main VM but does not work on any of the others. Meaning, the outcome is EXACTLY the same as if I were to just deploy and activate all of the features in one shot and leave out the post-deployment PowerShell script!

I've recycled App Pools, restarted IIS, rebooted all of the VMs and much, much more! I checked to make sure that all of the features were removed from web, site and farm before trying anything new. Nothing works!

I've been working on this for weeks already and am at a total loss. Any assistance would be most appreciated. Thanks.

Answer 1

So as it turns out, there was no other way to get the projects all deployed and activated correctly without using the Visual Studio extension that is available on CodePlex that allows you to create a custom deployment where you can choose to activate ONLY the features you want to activate (as opposed to all or nothing).

This allowed me to get all of my project features deployed AND activated -with the exception of my main deployment feature that takes care of actually creating all of my lists, libraries, content types AND makes use of the custom fields defined in one of my other project features.

The reason why I had to leave the actual main deployment feature deactivated is because that is the only way the custom fields were able to actually exist in SharePoint prior to being used! Even though my custom deployment configuration instructed the deployment package to deploy and activate the feature that contained the custom fields FIRST and was ALSO instructed to recycle the application pool it still didn't work! I actually had to create a post-deployment script with PowerShell that would execute an IIS reset from the command line and then finally activate the main deployment feature. Apparently recycling the app pool is not enough to get those custom fields recognized by SharePoint so you can use them in another feature.

If however, I would have deployed the VS project containing the custom field type definitions, controls etc. FIRST, reset IIS and THEN deployed the main deployment project, then everything would have worked. The thing is though that I wanted to be able to have everything deployed from a single project and the only way I was able to do this was via the method described above.

Lastly, the reason why I wasn't getting all of the features deployed and activated properly from the main deployment project the first time around was because I had only included the features from the other projects and totally forgot to include all of the SharePoint mapped folders (i.e. XML, XSL, images, CONTROLTEMPLATES, ISAPI etc.) in the main Deployment package. As a result, none of the field definitions from the other project or any of the code related to the fields, field editors etc. were actually being deployed when attempting to deploy everything from the main deployment project. Sure everything worked when I would deploy the other projects individually because each project was using it's own Package file that automatically includes all of the necessary mapped SharePoint folders and accompanying files. But once I created an all-encompassing deployment project it never occurred to me that I would have to include all of the mapped folders and stuff from the other included projects in the deployment project's Package file. I just assumed that by simply referencing the other projects' assemblies that all of their package files would be executed as well!

I was obviously wrong.