I have created a feature and i am auto activating it whenever 'My Site' gets created.
I am activating it for the template SPSMSITEHOST.
This feature changes the Picture URL property of User Profile.
Now, the problem is my feature gets activated but it seems it does not execute the code by default and and does not change the picture URL property.
When i deactivate the feature and activate the feature again then feature works absolutely fine as expected.
P.S: I am facing this issue on Production server, surprisingly this work fine on Staging server , i mean the same code !!
Any help ??
Thanks.
Sounds like something becomes out of sync on your production environment. Could it be caused by load balancing?
Are you doing this through STSADM commands?
I would stick the following line after after each command:
stsadm -o execadmsvcjobs
This will make sure processing for previous commands is done before moving on.
If thats way off then I would think its something to do with:
a) The way you're activating the feature... if you're using feature stapling, are you sure that the latest version of your stapling mechanism is in place?!
b) Assuming you have some sort of feature receiver in your code behind. Are you sure there isn't an error occurring thats being hidden by a try catch? If there is then you need to see what the exception is...
If it works when you deactivate/activate the feature, that almost eliminates security issues.
Hope this helps..
After long investigating and search for this problem i tried to rearrange the features at package file depending on the features dependencies, it seems SharePoint activate these features one by one as it's arranged in the package file and this is worked for me :)
Related
We are transitioning to DNN 9.01.01 build, but it seems that the import/export feature is not working properly. I submitted an import but it has been sitting on submitted status for the last 8 hours.
Is this a known issue or is there configuration on the server that preventing the import/export to work?
Our instance is installed on Azure
Thanks
This thread hasn't been touched in a long time but I dug around and found the problem. I fixed this problem by directly editing the DNN database. I'm on version 9.4 although, I'm sure this would work with any version as this issue is apparently caused some wonky code in the Azure AppService deployment packages.
To resolve, I just had to manually edit the dbo.Schedule table. I use Azure Data Studio because I'm on a Mac but SSMS or any other manager will work as well. I'm sure you can even use the DNN built-in editor although I'm not very familiar with it.
While digging through the dependencies I noticed that unlike the non-operational Export/Import job, all the working jobs had a NULL value in the "Server" field whereas the Export/Import job had the Azure server name written to it. I manually changed the value of this field to NULL and the Site Import job that had been perpetually spinning, started immediately.
Also, for posterity, you will want to make sure you don't have 15 different import jobs queued up before you do this because they will ALL begin processing once you commit the new value to the DB. If it took you a few times to figure out they were spinning you will probably want to go to the scheduler and delete anything you don't want to run prior to the DB edit.
Hope this helps save someone else some time. Cheers!
We contacted support as well and looks like it was an issue with installing DNN as Azure webapps.
We had to delete all the unused server and set the task to run on the current active server and start the import/export feature manually on the scheduler tab.
I had this issue, when checking the other task scheduled for execution I noticed the server field was empty while on the import/export there were comma separated inputs. When I cleared the import/export field the task ran correctly.
I believe they left out coded for this I'm DNN 9. I tried using it for a customer and it was useless.
I inquired and got a response that said it was an oversight.
To add to the possible issues that can cause this, We had renamed our server and the scheduled task still had the original name of the server. Once we changed the name to the new one under the task, it started running as scheduled.
HTH
Dave
I was trying to make changes to a module. I couldn't get the site to seem to reflect those changes. I thought I could possibly disable the feature, and re-enable the feature and it would force whatever module caching is happening to reload the module. However, it broke the site entirely, and now I can't even enable the feature from the orchard.exe command line tool. I am getting the same error. It's basically Autofac complaining that it can't find a type that was part of the feature. However, if the feature is removed, I am not sure where/why it is still trying to load.
Exception :
None of the constructors found with 'Orchard.Environment.AutofacUtil.DynamicProxy2.ConstructorFinderWrapper' on type 'RCAM.Products.Drivers.FeaturedProductsWidgetPartDriver' can be invoked with the available services and parameters:
Cannot resolve parameter 'RCAM.Products.Services.IProductService productService' of constructor 'Void .ctor(RCAM.Products.Services.IProductService)'.
I cannot get in the admin portal to re-enable the feature. I cannot use the command line tool. I tried setting the [Settings_ShellFeatureStateRecord] to Up in the database, but that didn't change anything at all. It must be file driven as well as database persisted.
This is a production site and is currently down. Any help you can give would be greatly appreciated.
Your question doesn't make it clear if you changed the code directly on your production site or if it crashed after a proper deployment, so here are my two cents:
If you make changes to your module in a live environment you should delete the contents of your App_Data/Dependencies-Folder afterwards. No need to re-enable the module.
This will only work, if you haven't disabled the Dynamic Module loader, which should be done though in a production environment.
Otherwise, make sure your module actually compiles. You should probably add your Module to Orchard.Webs build dependencies to make sure it actually re-compiles every time you run Orchard on your dev machine.
For removing the feature, instead of just disabling it, it should be enough remove your module folder and delete YourModule.dll from App_Data/Dependencies
I am deploying a SharePoint 2010 web part that uses the microsoft .net charting tool to build charts. I need the chart handler added to the sharepoint web.configs automatically. I've been told that when you create the wsp the package can be told that when the program is installed it needs to modify the web.config to add these handlers.
I have seen a couple options out there:
-WebConfigModifications
-Safe controls
I don't know which, if any, that I should be using. I don't know for sure if this will be a first time installation for the application (we're moving sharepoint environments at the same time we are updating this. I think that it will be a first time installation on that new environment but can't be sure.)
And I definitely do not know how to implement this correctly. I would appreciate any advice.
Also it may be important to know that I do not have any privileges on the server. I can't even deploy myself.
For example, this seems like good info: http://platinumdogs.me/2009/07/08/using-the-mschart-controls-in-sharepoint-moss-2007/ Except that I can't just write to the webconfig and restart IIS. It has to be automated and not a direct edit to the file.
Thanks all!
I would recommend that you use a Feature Receiver attached to your WSP to create the appropriate SPWebConfigModification entries when your solution's features are activated. Likewise, the SPWebConfigModification entries should be removed when your solution's features are deactivated.
Step 1: Create a Feature Receiver
MSDN has an overview of how to add a Feature Receiver: http://msdn.microsoft.com/en-us/library/ee231604.aspx
Note you'll want to handle both the FeatureActivated and FeatureDeactivating events.
Step 2: Use Feature Receiver events to add or remove SPWebConfigModifications
In those two events, you'll need to programmatically add or remove one or more SPWebConfigModification entries. These affect SharePoint's web.config file, but unlike a manual edit of the config file, they are stored in SharePoint's content database. This means that if the web.config is reset for any reason (and it happens), SharePoint can and will reapply the modifications, thus preserving your changes.
MSDN has an overview of programmatically creating and removing SPWebConfigModifications: http://msdn.microsoft.com/en-us/library/office/bb861909(v=office.14).aspx
It is very important that the FeatureDeactivating event properly clean up all modifications made during FeatureActivated, or you will end up with a proliferation of duplicate config entries. This means you need to really understand how to use the Path and Name properties of the SPWebConfigModification.
This article gives a good overview of how Path and Name are combined to create an XPath expression pointing to the node to be added or removed: http://smindreau.wordpress.com/2013/06/12/finally-the-way-to-add-web-config-modifications-to-sharepoint/
Step 3: Test, test, TEST!
Lastly, test activating and deactivating your solution's feature in your local development environment to make sure everything is working properly. Note that the modifications will be applied via a timer job, so you may need to wait a minute or two to see the changes show up. Be sure the feature deactivation cleans up your modifications! (If you get into a mess in your development environment with duplicate modifications, you can always wipe the slate clean with a little PowerShell action.)
I have somehow got into a strange situation with my CRM system.
A plugin I have developed is not getting updated correctly when the solution is imported. When I choose to maintain the customisations the plugin updates dont get applied, but when I choose to overwrite customisations the steps get doubled up and so the plugin gets fired twice.
Has this happened to anyone else? How do I stop this from happening?
Thanks
I've had a similar situation where I had plugins registered twice after importing.
I believe the way I solved this was:
Use the plugin registration tool to remove the plugin from the server you are deploying to.
Reimport the solution.
I can't see you doing any major damage here, but I would suggest backing up the server first because I'm not 100% on this one.
Are you assigning a strong name to the assembly? I've seen this kind of thing happen in CRM 4.0. If you don't assign a strong name with a key, CRM doesn't seem to see that it is the same assembly.
If you deploy the plugins using the plugin registration tool, solution deployment will duplicate all of the steps as it does not recognise the deployed plugin steps as their ID is changed.
If plugin assembly is deployed without the steps, you've forgotten to add the steps into the "Sdk Message Processing Steps" section of the solution.
#JamesWood approach will always work but is very heavy handed for a production environment, an IIS Reset and restart of the MSCRM services (in services.msc) usually clears any cached plugin assembly, while a redeployment should only be needed/used in dire situations.
The following issue just crept up on me. The steps mentioned below had worked just fine until about 2 days ago.
When I deploy a update to a solution (of web parts) to a SharePoint 2010 server I don't see the update. The solution does get installed, but from what I can tell the installed web parts are over a month old (nothing new is installed).
I do the following steps through PowerShell:
retract the solution from the web app
remove the solution
add the solution
install the solution to the web app
I have tried restarting the Web App, restarting IIS and also restarting the server. Nothing seems to work.
I notice that after I remove the solution it does get removed from the GAC. After I add/install it the solution does reappears in the GAC.
Am I missing something? Am I overlooking a step that I should be doing? Something to try?
I never deactivated/reactivated the Feature.
After following the same steps I mentioned in my question I just deactivated, then reactivated, the Feature and everything started to working fine.
This is an easy thing to I can start to implement with my solution updates. However, why did I never have to do this step before?
In general, you should check your ULS log to see which version of your solution is running. If you see the old one, then you can be sure that your activated site feature is still bound to the old version. In this case you have to Inactivate the site feature indeed to loose that tie and then Activate to bind to the new one (it appears Activate always ties the site feature to the newest version of the solution).
Maybe you had not to do this earlier, because you did not change the version number of your solution, appearing as the same version in GAC on the server. In this case you had your site feature already pointing to the correct version of your solution, therefore didn't have to reset the feature.
You have probably checked, but just in case. Make sure that the powershell script is not adding a month old package.
Is the problem in the web part code or the configuration? The configuration usually unghosts itself sooner or later and refuses to update from the solution - you can update the file in the gallery manually if anything has changed there. For most updates there won't be any changes because existing web parts won't get updates applied anyway - they will use new code but old configuration.
If the problem is the code itself, does the assembly appear to the system to be unchanged? All the hardcoded full name references in SharePoint config files mean that usually you are deploying a new assembly but with the same version numbers. This can mean that the system doesn't bother making the update. I have found it very useful to update AssemblyFileVersion (which does not affect binding) on every build and have a page in _layouts that displays the file versions of all the loaded assemblies so I know exactly what is running.