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
Related
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 am in the process of upgrading from Orchard 1.7 to 1.8. Everything seems fine locally, but when I deploy my site, 1 of my custom modules is disabled. When I click the "Enable" link in the modules section of the dashboard, the page refreshes, but the module is still disabled. My local instance is connected to the same database and shows the module enabled so not really sure what is happening. I don't see any details in the standard error logs.
Is there any way to see any errors that could be causing a module to fail being enabled?
Thanks
This turned out to be due to a case mismatch in my feature name vs my module folder name. My module was originally named in Pascal case ie. 'MyModule'. Somewhere along the way my folder had gotten renamed to 'Mymodule' while the Module.txt file still listed the primary feature as 'MyModule'.
I finally hunted this down by copying the Orchard.Modules.pdb file into the bin folder of my precompiled web application and attached the VS debugger to it to see what was going on. The issue presented itself inside of Orchard.Modules.Controllers.AdminController.Features() where a comparison of FeatureDescriptor.Id == ShellFeature.Name failed to match on account of the case mismatch. The result was that my feature was being shown as disabled even though it is enabled in the database.
Not a direct answer to your question but did you do a complete rebuild before publishing your orchard site (assuming that is how you deployed it)? I have found that sometimes you have to do a rebuild all before publishing.
I just attempted to update the site map provider from 3.3.6.0 to 4.0.14. I followed the instruction on the wiki however my SiteMapPath now renders empty. I made no changes to the mvc.sitemap file other than updating the schema to 4.0. When I debug into the SiteMapPathHelperModel I find that the model has no nodes defined. I am using the internal DI container (I would like to get this working before switching over to the application container).
When I check the sitemap.xml file it is well populated which makes me think that the mvc.sitemap is being read.
I'm out of ideas on this one and would be happy to provide any additional information which may be useful. I'm not even sure where I can hook into debug this problem. Literally the only thing I changed between a working 3.3.6.0 and a not working 4.0.14 was what was prescribed on the wiki.
Ok, since your /sitemap.xml endpoint appears to be working, you are correct the sitemap is being populated and loaded correctly.
There are a couple of things I know of that can cause this to happen:
If you are using Dynamic Node Providers, they must be added to a node that is not otherwise part of the sitemap. See my question here - I am trying to figure out why this is the case as well.
Your routes don't match your nodes - please read Routing Basics and/or post your routes and Mvc.sitemap XML.
If you check the above and everything appears to be correct, please make a small demo project showing a sample of your configuration and open an issue on GitHub, as it is highly likely your specific configuration has something to do with the problem.
BTW - You can debug by cloning the current repo on your system or downloading the solution as a zip, enabling NuGet package restore on your solution (right click the solution > Enable NuGet Package restore), add the MvcSiteMapProvider project to your solution, and then in your project remove the reference to MvcSiteMapProvider and add the reference to the newly added MvcSiteMapProvider project from your MVC project. Then you can add breakpoints and step through the code. I suggest making a backup of your solution (or ensure you can roll back another way) before doing this, and reverting back to your current state when done.
I have documented the whole procedure here: http://www.shiningtreasures.com/post/2013/08/21/debugging-an-mvcsitemapprovider-configuration
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.
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 :)