I would say: use log4net. You could try hooking into Tridion.Logging, but this DLL is not intended for implementer usage, and its configuration is buried deep in the Tridion.ContentManager.Config file which I would really only modify when absolutely needed.
The events are always fired by the CM kernel (or Publisher in some cases), which means that they are independent from the client.
So, yes, all events will be triggered by your Core Service application.
Bart's comment made me think about two processes trying to use the dll, and that made me think about two processes trying to write the same log file.
So that seems to be the real problem, not GAC versions but two processes trying to write the same log file; I used two different log files for Save and Publish events and then I got both log files.
I still ...
Be careful here - you are seriously changing the default behaviour of Tridion - the ability to republish all pages where a component is used by publishing the component is very useful for editors who may not know where a component is used, but want to make sure that it is up to date all over their website. Why is it that you do not want the pages to be ...
The only obvious problem is that you should subscribe to EventPhases.Initiated instead of EventPhases.TransactionCommitted. Other than that it looks fine, unless you are calling component.Save somewhere down the line.
As Nuno commented, that error is about the old legacy VB event system. You can disable that if you are not using it and just have your new .NET assembly running instead (which doesn't require any further configuration).
I have no problems running and debugging that code (attaching to TcmServiceHost.exe) so the problem is likely that your extension hasn't ...
This is a great example of the evil that is the "As" cast
If you wrote your code like this:
var configuration = (NameValueCollection)ConfigurationManager.GetSection("custom.events");
Instead of a Null Reference exception, you'd get an Invalid Cast Exception when GetSection returns a ConfigurationSection. Of course, you should still implement a null ...
The Event System is one of two official places where you can (and should) use TOM.NET in Tridion 2011 / 2013 (the other place being C# Templating).
So you should not use Core Services here as they are intended for external applications only (such as the Console application you wrote).
The event system code loads when the Tridion Content Manager Service Host service loads, and you can see this in the Windows Event Viewer. As each event handler loads you will see the status showing that the TCM Extension has been initialized.
What we implement most of the times (for .NET front-end apps):
a table on the front-end DB to store the sitemap information
create a custom deployer to store sitemap information at publishing time
create a custom .NET sitemap provider using this custom table.
This way has (imo) following advantages:
sitemap is always up to date (each publish/unpublish ...
Generating a big XML on publish time is the easiest option but can be a time consuming action, specially as you will need to trigger republish on every page publish/unpublish. I have seen some sitemap publish taking minutes.
There are many options, but my favorite approach consists on 2 steps:
publishing small XML fragments with every page publish/...
How do you connect to the core service? Are you using a netTCP binding or a wsHttp/basicHttp binding? In case of the former the app.config file would be TcmServiceHost.exe.config and for the latter it would be web.config in %TRIDION_HOME%\webservices...
In the UnPublishEventArgs there is a member UnPublishInstruction.
This will have a property - StartAt - If StartAt property is set to DateTime.MinValue that means the Unpublishing is scheduled for Immediate unpublish and if it is set to a particular datetime, that means it is schedule to unpublish at some other time.
Unless you're trying to implement really granular permissions (more on that in a minute) it makes more sense to handle this on the check-out event instead. The rudimentary issue that I see - and this also applies to implementing granular permissions (e.g., treating check-in and check-out as two separate permissions) - is that by the time the check-in event ...
What have you tried? If you're just starting your search then the docs references below are a great start.
Both the TOM.NET and Core Service APIs are available but it shouldn't be about what's easiest. It would be interesting to understand if there some technical or business reason you want to consider using the Event System?
If you have Alchemy installed,...
From the title of your question "Event System Alternatives (Memory Leakage)", it appears that you may be looking for alternatives to using the Event System due to a memory leak that you have in some existing code. If this is the case, then I would strongly recommend that you fix the source of the memory leak problem, rather than finding workarounds.
You can do that (alert) without a GUI extension, simply by using Event System (OnComponentSavePre event). The GUI extension framework is very different in 2011 and 2013, I would not recommend doing a real extension for 2009, as you would have to rebuild it once you upgrade.
Creating a Tridion 2009 Event System is not as simple as 2011 or 2013, but ...
I may just not be seeing it in the code, but you're not implementing IDisposable and there's nothing in your code calling Dispose(). If you're not disposing of the subscription it never actually finishes executing, as Dispose is what enables garbage collection to clean up all of your references. Have your class implement IDisposable.
Check for the following:
1) IN Tridion Content Manager config file on CMS server, ensure that all correct EventSystem DLLs has been subscribed, there is no unwanted DLLs registered and the path of the desired even system dlls is correct
2) As Nuno suggested, check in SDL Tridion Configuration Manager, that older COM+ event system are not enabled
you might want to take a look at Dominic's post here : http://www.dominic.cronin.nl/weblog/tridion-explorer-reports-system.servicemodel.serviceactivationexception and try the web.config settings he describes as a test?
To add to Nuno's answer, indeed using the COM based event system through .NET has a lot of potential (memory related) issues if not done correctly. I always use the following code examples to explain what needs to be done:
It sounds like your custom resolver is not working - you can check which items are going to be published by clicking the See Items to Publish button on the bottom left of the publish popup - if your resolver is working this will only show the one component. If you want to debug your resolver, then attach to the publisher process (TcmPublisher.exe - I think) ...
Since way back I have been working with a batch file (which calls a script for COM+ shutdown) called from a post build event in Visual Studio to deploy to my development environment (note this only really works if run on the server itself - but I typically develop event system code on the server, in order to debug it). As it works fine, I never made an ...
It sounds like you are hooking into the Processed (or later) phase of the Save operation, which will only be called after the save has happened.
You should instead hook into the Initiated phase of the save. This one occurs before the save and so giving the field a value will satisfy the mandatory requirement of the field when the save does occur.
For #1 publishing priority is the way to go. Maybe changing the default priority to "low" will give you enough of an override to push things through quickly. Using publishing priorities in conjunction with the information I share in the blog post on keeping threads available.
Item #2 might need event system, but you should be careful of performance impacts. ...
You can try the below events related to Workflow:
1.Event for Workflow process starts
EventSystem.Subscribe<ProcessInstance, StartWorkflowEventArgs>(OnProcessInstanceStart, EventPhases.Initiated);
2.Event for Workflow activity starts
EventSystem.Subscribe<ActivityInstance, StartActivityEventArgs>(OnActivityInstanceStart, EventPhases....
If all you want is to modify component metadata on save (as you mention in a comment) then using the CoreService is complete overkill.
Set your event to run on Component,Save,Initiated
Then do something along these lines:
ItemFields metadata = new ItemFields(...