From your code it would seem that you are trying to set a web-application property from a site collection scoped feature.
If you are using SharePoint 2010, I can assume that you are experiencing the effect of the new "RemoteAdministratorAccessDenied" security setting, which among the others by default block any attempt to alter a web app property from a ...
As EStruyf said, you can change the deployment configuration and debug the code for your Feature Event Receivers. But, you can also attach the event receivers after making sure List is created, so put this code after your list is created.
public class Feature1EventReceiver : SPFeatureReceiver
public override void FeatureActivated(...
Your plan is good, and respects good practices (at least the practices I've been following for ages).
Your approach is to:
Create the solution in VS
Create one feature (scope: Web)
Create two classes for the event receivers (both inheriting from SPItemEventReceiver)
Add a feature event receiver on the feature (inheriting from SPFeatureReceiver)
In the ...
Short answer: you can't. And why would you create the database using a feature? If you are creating an installer anyway, create the DB there using a db create script or a custom seetup action.
As for storing the DB connectionstring and or DB credentials: Use the SecureStore Service Application. See this article for information on how to configure the ...
The code compiles and runs fine for me as long as there is a reference to Microsoft.SharePoint (2010). Are you building a console application? In that case make sure you are using the .NET 3.5 framework (not compact or anything else) and set the platform target to Any CPU in the build section of the project properties.
BTW. note that you are leaking a site ...
You need to use the Update() method on the SPListItem object.
Also, you want the line:
listitem["Activated Time"] = DateTime.Now.TimeOfDay;
to be simply:
listitem["Activated Time"] = DateTime.Now;
otherwise you'll get an unhandled exception.
This is the code I have, which works (the method being the same one you've selected):
SPSite site = SPContext....
I would recommend to use the first method - Create the Form in SPD, save it in .aspx and include it in a List definition feature.
Creating the form in SPD and doing the modifications required are pretty much easy. For eg.- Adding a list view web part or modifying an XSLT would be quiet easier in SPD.
Now, adding .aspx in a list definition in VS ...
Try running a check on the parent web to see if the feature is activated. Since this is only applying to sub webs and it is in the FeatureActivated event, it will already be activated on the parent for you to verify.
Code added to check if web.ParentWeb != null
bool isChild = false;
if (web.ParentWeb != null)
foreach (SPFeature parentFeature ...
If I remember correctly the flow is:
Site Collection Scoped Features
Web Scoped Features
Your stapled features would be shot in after Site collection scoped features or Web scoped features (depending on scope) and hence the lists is not guaranteed to be created before the lists.
Found a source here:
Looks like it is a DLL caching issue. When you start Powershell command line window, it loads all DLLs available in the GAC. So, if you have updated DLL for the feature receiver, and deploying it within the same PS session then it will not reload updated DLL. I had experienced similar behaviour before. To tackle it, I created two seperate PS1 files. First ...
Well. It really depends on which feature you have to activate.
The id of a feature does not change during its life. This means that if you can find out the id you will be sure it stays the same, regardless of the specific SharePoint farm instance. That said, you can "hardcode" your ID in a support class, much like SharePoint does with fields id in the ...
My solution to the problem was to change assembly version from 184.108.40.206 to 220.127.116.11 and build the SharePoint project. After that I deleted feature receiver and added feature receiver again so that feature manifest XML file gets updated with correct version of feature receiver assembly.
More details on http://slavensemper.blogspot.hr/2015/08/failed-to-load-...
You could use SystemUpdate instead of ProcessBatchData. False should mean modified date doesn't change:
SPListItem item = ???;
item["myField"] = "my value";
Of course, this means you have to update each item one at a time instead of the batch process which may lead to performance issues.
See also, how to temporarily disable email ...
I experienced a similar issue. Upon creation of a new site, the features included in the <WebFeatures> node of the ONet.xml were not activated upon site creation. When navigating to '/_layouts/ManageFeatures.aspx' these features would appear to be activated but their code would not run (no files were placed from modules, breakpoints set in event ...
The ReceiverAssembly should be the Fullname of the assembly
FeatureBuilder, Version=18.104.22.168, Culture=neutral, PublicKeyToken=xxxxxxxxxxxxxxxx
If developing using SharePoint templages in Visual Studio 2010 use $SharePoint.Project.AssemblyFullName$
I would go for Deepu's explanation in general.
For more details rather, you need to consider, assuming you build a WSP package via VS2010:
Your own custom list? - if yes, you could do it declaratively in the
List Definition (is a bitch to do that XML declaratively for the
views - but is doable).
Another list? - use Deepu's explanation with the caveat ...
The 3rd option is InfoPath - if you're in such a position in which you can enable the SharePoint -> InfoPath integration features. Especially useful if forms will later be maintained by staff who are more familiar with Word or Office as the UI will be very familiar to them.
A quick way is to set the value of the active deployment configuration from Default to No Activation (in the properties of the project). That way you need to manually activate your features and you can directly see what goes wrong.
I dont think you will need Event Receiver for your purpose, please find this thread of stackexchange SP 2010 Custom Access Denied Pages
For help with command you may find this MSDN Article helpful
For details steps please go through this Customize the Access Denied Page
If your class is:
in the same project
inherits from SPFeatureReceiver
has the right [Guid(xxx)] attribute
then it should work, but I would consider it a bad practice. A better solution woulc be to have two destinct feature receivers calling common functions, then if at some point you need to differentiate (could be in regards to FeatureUpgrading),...
Please check this link to see how to set your home page.
If this does not work, please try to debug and check if your FeatureActivated event gets fired.
Hope this helps
My bad that I did not see that. Anyways can you please try below,
Please use this in feature activating,
SPWeb web = properties.Feature.Parent as SPWeb;
if (web != null)
I'm not sure this will work, but I would try this:
public override void FeatureActivated(SPFeatureReceiverProperties properties)
SPWebApplication webApplication = properties.Feature.Parent as SPWebApplication;
//Get current user from any sitecollection and rootweb
SPUser user = webApplication.Sites.RootWeb....
You are using the rootweb of the site, not the current web, so any changing you are making is always to the rootweb. Instead of using webTemp to get rootweb, just use webTemp as the web.
private const string QuicklaunchHeader = "Saksmappe";
public override void FeatureActivated(SPFeatureReceiverProperties properties)
SPWeb web = properties.Feature....
You should be able to use event recievers to do this, more specifically the SPWebEventReciever.
An event receiver is a piece of managed code that responds to SharePoint events when specific triggering actions occur on a SharePoint object. Triggering actions include activities such as adding, updating, deleting, moving, checking in, and ...
Often this is due to the SPTimerV4 holding a cached reference to your solution .dll:s
net stop SPTimerV4
net start SPTimerV4
in PowerShell or cmd when you have retracted your .wsp before reinstalling them
You should use Delete() method of SPWeb.Lists
SPWeb webSite = properties.Feature.Parent as SPWeb;
SPList myCustomList = mySite.Lists["MyCustomList"];
You should also create a new SPSite object while running a code as elevated privileges:
Ended up getting things to work
After getting SPSite site = properties.Feature.Parent as SPSite; I found out that all I needed to do was add the rest of the url which was could be something like "/NewPage" to the rest of the url since I already had the full site url from the properties.
Created a method that passed in the site and the weburl to get my ...