When creating an uninstaller for a Windows app, should I remove an event source?
I'm not looking for a philosophical discussion, I'm looking for specific technical reasons why it may or may not be a good idea to remove an event source, esp. given that events written to that source will be left behind.
Good:
Regarding to manifest-based event generation, it may be good idea to leave the source in the system so other event consumers can properly render messages generated by the source after the program is removed.
Bad:
Orphan event sources choke up the system registry.
It is impossible to create new event source with the same name even in different channels. Hence, you will have to somehow manage conflict situations on re-install.
Related
I am trying to develop an application for monitoring operations on a particular folder which includes creating, deleting, modifying, moveing, duplicating and renaming.
After referring to the FileSystemWatcher API, I found that it does not provide a Move event, instead it will generate a separate Delete and Create events for the same file. Of course I can wait for a Create event each time a Delete event is detected and decide whether it is a Move event or not, but it is a little bit strange to me and the appropriate time to wait for is also a problem.
Actually I find that Dropbox is able to detect the Move event correctly even when dropbox process is not running. Nice work for Dropbox team and I wonder how do they make it work on earth.
So my purpose is quite clear : Filtering Move event from other events and making it work offline (which means when the procedure is stopped)
Well, a move operation is basically a "copy & delete" from the FileSystemWatcher's point of view. Without knowing details about the implementation I bet DropBox stores a hash for each file. If a file is removed in one place and created with the same hash in another place, chances are it was moved. You could actually do the same thing.
I want to know if a extension (for example: joomfish) is really used or not used at all before i disable it / uninstall it.
Is there a way to check ?
First, in Joomla plugin has a specific meaning, so what you want to know is whether a component, module or plugin is used.
This is a common problem when you inherit sites. A lot of times users install tons of extensions and never use or uninstall them.
The simplest first step with modules and plugins is to see if they are published or not. Also you can look at modules and see if they are assigned to any positions or menu items.
In terms of extensions, if they are a kind of extension that would be used to create content and you look at the manager you can see if any content was ever created. If not it is probably safe to uninstall. IF there is content then you will want to figure out whether you need o preserve it.
The problem with Mike's answer is .. how do you know if you have tried every possible combination of things or possible events with enough certainty to say for sure that something is not running ever. For example you may have a component that you never use as a menu item but then some module is running a query against its data.
Well you cannot know that. To be absolutely shure you could write a system plugin which gets triggered on plugin calls and logs the triggering plugin names.
I was wondering if it was possible to intercept or disable different Visual Studio commands or features from an extension?
For instance, could you stop a user from accessing the File -> Open command? I'm trying to work on an extension that will help enforce some coding standards and as part of that I'd like to disable or intercept a few different things when users try to do them. For instance, maybe disabling the ability to edit project properties or something similar to stop users from checking in their local changes and breaking the build or messing up other team members.
Do hooks exist for this in the Extension API or are we stuck with the old Word document asking people to play nice?
You can, but I do want to echo Greg's comment before I give details: you are better off spending your time making a really awesome tool that developers can run to catch "bad problems" than playing whack-a-mole to disable commands. Disabling commands could be dangerous because there are often multiple commands that might do the same "bad" thing. Also, disabling might cause other parts of VS to destabilize. Using your example of project properties, write a tool that runs across your codebase and looks for project files that are "bad", and spits out a build warning. Have this run every time your developers hit build. That way they still get the near-real-time feedback, without having to make sure they have extensions installed. (plus, you can check that tool into your codebase to ensure everybody is synced)
That said, implementing a IVsRegisterPriorityCommandTarget might be the right option here. The performance ramifications can be significant, so you need to make sure your implementation is fast or else you'll slow down VS. If you return E_NOTSUPPORTED from the handlers, that will result in normal routing. Returning S_OK but not forwarding would block routing from happening.
In visual studio, one can create "tasks" by inserting comments like this:
//TODO: Make me a sandwich before looping.
These tasks can then be viewed under the View > Task List menu. But these tasks are entirely independent from Team Foundation Server.
It would be extremely useful to be able to automatically create a new Team Foundation work item when a TODO task is added, so that the work item can be assigned, commented, attached to, linked, and associated with check-ins, etc.
Anyone know if this is possible?
My suggestion - even if it was somehow possible:
Don't do that :)
//TODO: is very lightweight, you can add/remove/modify those lines as you like with no impact besides being source controlled.
TFS work items are much more heavyweight and process oriented (only so-and-so many state changes are allowed according to a process template).
Synchronization and keeping track would be a nightmare. Therefore I think nobody I know of does it.
We use:
//TODO: for developer comments/reminders. - Internal/developer only
WorkItems for Bug/Feature/Task tracking (Inprogress/Complete/etc.) - Team/developer/tester only.
Help Desk Request for End User visibality. - All/End Users
I don't think they should be mixed as they server different purposes.
I completely agree that turning TODO items into work items is the wrong way to go.
But considering this as a tool capability exercise I think it can be achieved.
You can define a dummy build with a custom build activity in it.
Here is a series of blog posts by Ewald Hoffman teaching how to customize Team Build.
http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx
Part 5 discusses how to automatically increase assembly version with each build. He does this by including a custom activity in the build which scans through code files to catch a text pattern (in this case the assembly version xml tag) and update it.
The same approach could be used to catch TODO items (for the sake of the exercise) and work items could be created through TFS API.
Again, I do not recommend doing this but this technique could be used to solve other similar problems.
In the list of Visual C# 2010 Breaking Changes there is an entry on "Event synchronization" which states that you must now create a local copy of a delegate to check for null (before calling it) in order to avoid a race condition. Wasn't this already the "best practice" pattern anyhow?
Does this change make any difference in the StackOverflow discussion on C# Events and Thread Safety?
Well, you didn't have to take a copy if you used exactly the code they'd got there - because it was locking on this. However:
locking on this is a bad idea to start with
holding a lock while you execute event handlers is generally a bad idea
So code which was already bad practice is now actively broken. Ho hum. The normal implementation of events (which doesn't hold a lock but does copy the variable) isn't changed by this.
See the Chris Burrows blog post about event best practices for more information.