I am deactivating a feature through stsadm tool. I have an event reciever enabled for this action. If i deactivate the feature manually from the site the event is getting triggered but not when running stsadm command.
Please help...
Here is the code Sylvain:
public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
Logging.Log(_componentName, "The document library feature has deactivated successfully.");
}
In the code of your event receiver, do you use SPContext.Current (or other Web-Context objects)... ?
If so, your code works on the site, but not out of web-context (like stsadm or command line) because SPContext.Current is null.
Check this point, but there's a good probability that's the problem.
As Sylvain Reverdy pointing out it is more likley your feature receiver to fail than not beeing called. Check out SharePoint logs - all feature activation/deactivation/installation steps are traced there (Location - c:\Program Files\Common Files\Microsoft Shared\web server extensions\14\LOGS, see Where is the default log location for SharePoint/MOSS?).
Make sure you are not using "-force" option of StsAdm command - it makes stsadm to ignore failures during deactivation.
Related
When I try to open a form published from InfoPath I now get this error:
"The following location is not accessible, because it is in a different site collection:
https//portal/sites/forms/Daily%20Activity/Forms/template.xsn?SaveLocation=https//portal.alamedacountyfire.org/sites/forms/Daily%20Activity/&Source=https//portal.alamedacountyfire.org/sites/forms/Daily%2520Activity/Forms/AllItems.aspx&ClientInstalled=false&OpenIn=Browser&NoRedirect=true&XsnLocation=https//PORTAL/sites/forms/Daily%20Activity/Forms/template.xsn."
Correlation ID:12c0ab9c-caff-80a8-f1b4-64d81dcfa6ea
Following are some options that you can try:
1) Save the form template (.xsn) as the source files in the publish options. Look at the manifest file in notepad and see if you can find a reference to the incorrect location. If so, correct it and Republish the form.
2) Clear the InfoPath cache on that machine. Start->Run "infopath /cache clearall"
3) See if the site collection has a managed path, if so, give the proper url while publishing. The XSN might be getting deployed on the root site and throws error since the intended list does'nt exist.
I found this worked for me. Got the answer from another post.
"I had a similar problem and found it was due to the request management service routing from my web application host header to the server name.
There was a routing rule in my request management settings. I just disabled routing and the problem went away. I used the following powershell to disable it. "
$w = Get-SPWebApplication "http://webapphostname"
$r = $w | Get-SPRequestManagementSettings
$r.RoutingEnabled = $false
$r.Update()
You may want to configure it rather than disable it. Here’s a good resource to get you started:
http://www.harbar.net/articles/sp2013rm1.aspx
I am not able to find out how to see azure diagnostics logs. Code which I wrote is as follows.
DiagnosticMonitorConfiguration config = iagnosticMonitor.GetDefaultInitialConfiguration();
System.Diagnostics.Trace.Listeners.Add(new Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener());
config.Logs.ScheduledTransferLogLevelFilter = LogLevel.Information;
config.WindowsEventLog.ScheduledTransferPeriod = System.TimeSpan.FromMinutes(1.0);
DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);
then I added Trace.WriteLine("some message"); in the code. Now where do I find those messages. I checked in Visual Studio server explorer, where I added my storage account reference. wad-control-container has only config files.
You might want to take a look at this blog post by Michael S. Collier. A setting in your cloud project might cause the logs to end up in an other place than you would expect them to:
http://michaelcollier.wordpress.com/2012/04/02/where-is-my-windows-azure-diagnostics-data/
Update:
Note that you'll have to take care of every small detail to make everything work.
Where are you writing Trace.WriteLine("some message"); ? Is it in your WebRole.cs? If that's the case, you'll need to configure the trace listener for the WebRole.cs (this runs in an other process, different than your actual web application).
Here is an example how you can set up the trace listener in the WebRole.cs class:
System.Diagnostics.Trace.Listeners.Add(new Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener());
System.Diagnostics.Trace.AutoFlush = true;
After setting that up, you can use Trace.WriteLine.
This is a good step by step on how to enable diagnostics:
http://www.windowsazure.com/en-us/develop/net/common-tasks/diagnostics/?sec=commontasks
I wrote a tool that allows you to view Azure Diagnostic information.. check it out
AzTools - Azure Diagnostic Viewer
Click here to see how you could use this tool
We have a farm with 2 servers.
I have applied some changes to the web.config on both servers. (I have a specific web application i.e. I have applied the changes in the web.config of my sharepoint web application and NOT the default Sharepoint site or the central admin site)
But it seems that Sharepoint does not take into consideration these changes!
For example I added an assembly reference .... but sharepoint was still throwing an assembly reference exception. i had to add the assembly reference to each and every control.
I have also increased the execution timeout but it still gives timeouts.
This happens in the production environment only.
In the test (where there is a single server) I update the web.config and all changes work.
Is it because I should not be updating the web config. I have noticed there is an SPWebConfigModification class. Do I have to use this ? won't it do the same changes as I would have done manually.
Update ....
I have now used the SPWebConfigModification and also did an iisreset ... but the changes were simply ignored!
Update 2...
Some more details on my web.config updates
I had added an assembly reference under assemmblies sectuion, somethign like this:
This did not work as Sharepoint was still throwing an exception that the assembly cannot be found.
This problem only happens in the production environment. In dev and test, I was also receiving the exception but when I added the assembly reference above, the error disappeared.
Another thing which did not work is the executionTimeout. I have added this to the production environment but sharepoint is still giving timeouts an a long request wich we have. Again, this entry solved the problem in the test and development environments.
I wrote this for this for Sharepoint 2007, I think you need to modify the impersonation (RunWithElevatedPrivileges) but the rest should work:
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
SPSecurity.RunWithElevatedPrivileges(delegate() {
try
{
Trace.WriteLine("Try to modify web.config");
SPWebApplication myWebApp = ((SPWeb)properties.Feature.Parent).Site.WebApplication;
WebConfigModifier mod = new WebConfigModifier(myWebApp, OwnerString);
mod.AddModification(
"SafeControl[#Assembly='Elsni.WorldsBestProgram, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e7639c2c71f2f003']",
"configuration/SharePoint/SafeControls",
"<SafeControl Assembly='Elsni.WorldsBestProgram, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e7639c2c71f2f003' Namespace='GFA.UniversalListSyncSolution' TypeName='*' Safe='True' />"
);
mod.AddModification(
"add[#key='PropertiesSiteUrl']",
"configuration/appSettings",
"<add key=\"PropertiesSiteUrl\" value=\"http://iei-developersy/sites/gfaadmin/\" />"
);
mod.Update();
Trace.WriteLine("Done.");
}
catch (Exception ex)
{
Trace.WriteLine("ERROR while activating feature: " + ex.Message);
}
}
});
}
As you have pointed out, you need to make these changes using the SPWebConfigModification class. It is possible to make the changes manually, however, this usually results in random issues caused by replication issues etc ....
The SPWebConfigModification class will ensure the change is stored in the SP database and amend the web.config files on your behalf.
I am having a nightmare trying to debug the event receiver of a Sharepoint list.
This is the code of what I am doing:
//Add an event receiver to the list
list.EventReceivers.Add(SPEventReceiverType.ItemAdded, "DatasEvent, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = 6f4db1e1fedbed57", "DatasEvent.DatasEventReceiver");
public override void ItemAdded(SPItemEventProperties properties)
{
try
{
int itemIdSql;
SPListItem item = properties.ListItem;
...
}
catch (SqlException ex)
{
Debug.WriteLine(ex.Message);
}
}
If I place a breakpoint in the event receiver it will not stop.
go to your visual studio Debug -> Attach process -> attach all available w3wp.exe in the list. Now try activating the feature in the web browser. Your breakpoint should be loaded and hit.
I personally prefer adding System.diagnostic.debug.WriteLn() messages to the event receiver code and view them using DebugView on the server. Attaching to worker processes every time is annoying.
First of all ensure that the latest assembly version gets to the GAC. The easiest way for it is to use the "Deploy" option from the context menu of the project or simply hit F5.
Then please let us know where this code is allocated
//Add an event receiver to the list
list.EventReceivers.Add(SPEventReceiverType.ItemAdded, "DatasEvent, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = 6f4db1e1fedbed57", "DatasEvent.DatasEventReceiver");
if it is placed in a feature receiver then make sure that it is activated before you try to attach to w3wp.exe that corresponds to the app pool your target web application corresponds to.
I would try:
Debugger.Launch();
Only in a development environment, otherwise it will try to debug for every request.
I would put it before adding the event receiver.
ItemAdded handles the asynchronous event that occurs after an item is added. The execution is carried out via timer job (and not in current worker process w3wp). So you should attach to OWSTIMER process to debug it.
You should enable debugging of sharepoint in two web.config files.
You should use Debugger.Launch() to stop the runtime.
E.g. After deployment and Activation event fires (in EventReceiver's code there is a Debugger.Launch() command) and VS asks you to debug the code.
There is no need to use "attach to process", but it's another possible way to debug.
this links helped me a lot
how can i perform logging in sharepoint. i want to use tracing.
so that it logs in the 12 hive logs.
Microsoft provide an example:
http://msdn.microsoft.com/en-us/library/aa979522.aspx
This sample writes to the ULS log using the native trace methods, so a bit of pInvoke is used in the code.
You can then control the type of logging event in your code such as:
TraceProvider.WriteTrace(0, TraceProvider.TraceSeverity.High, Guid.Empty, "MyExeName", "Product Name", "Category Name", "Sample Message");
The event throttling settings in central admin will still be honored with this approach.
My preferred approach is to write a custom HttpModule to trap and log all errors. After logging the error, you can redirect the user to an error page - this is the approach I've seen most used for custom error handling in SharePoint.
In your HttpModule, you can use an approach such as the one described by Daniel to write the exceptions to the ULS logs.
Here's a simple example of doing this:
Create a class that implements IHttpModule, and wire up the appropriate event in the Http pipeline:
public void Init(HttpApplication context)
{
context.Error += new EventHandler(context_Error);
}
In the context_Error event, go through all the errors and log them ...
void context_Error(object sender, EventArgs e)
{
TraceProvider.RegisterTraceProvider();
foreach (var ex in HttpContext.Current.AllErrors)
{
TraceProvider.WriteTrace(0,
TraceProvider.TraceSeverity.Exception,
Guid.NewGuid(),
Assembly.GetExecutingAssembly().FullName,
"<your application name>",
"<exception category>",
ex.ToString());
}
TraceProvider.UnregisterTraceProvider();
HttpContext.Current.Server.ClearError();
HttpContext.Current.Response.Clear();
HttpContext.Current.Server.Transfer("/_layouts/Error500.aspx");
}
You of course have to wrap this all up into a feature (scoped at the Web Application level) and deploy it to SharePoint.
Note that your entry in the section of web.config for this custom error http module needs to be first in the list. The order in which the http modules are listed in the section matters, and the custom error http module should always execute first.
(SharePoint 2007?) From Central Admin, go to Operations->Diagnostic Logging, "Trace Log" and "Event Throttling" are what you're looking for.
Select a category in "Event Throttling" and select least critical errors for both the event and trace logs. Then, select a path for the trace logs (mine was defaulted to ..12\LOGS) and supply a max number of logs and the number of minutes to use each log file.
I wrote some blog posts that will help you out. What i suggest is using the BCL logging classes (System.Diagnostics) and creating a custom TraceListner that writes to the SharePoint ULS logs.
http://sharepoint.nailhead.net/2008/04/instrumentation-logging-for-sharepoint.html
If you´re using MOSS, you can use this:
Microsoft.Office.Server.Diagnostics.PortalLog.LogString("Message");
Keep in mind that according to Microsoft documentation - LogString is reserved for internal use and is not intended to be used directly from your code.
For more details refer this link -
https://msdn.microsoft.com/en-us/library/office/microsoft.office.server.diagnostics.portallog_members.aspx