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.
Related
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.
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.
Is there a way to disable the 'Keep my changes' button during check in?
For example:
When person A is altering class x.cs in visual studio 2010 that is under source control (TFS 2010), and person B is also altering class x.cs in VS2010.
And person B does check in his code, and after that person A wants to check-in his code, Visual Studio comes up with a message that there are conflicts:
Check In
No files checked in due to conflicting changes. Please use Conflicts Channel to resolve conflicts and try again.
Then person B can compare the code, discard his changes, but there is also a button to 'Keep Local Version'. If that button is clicked, the changes made by person A are lost.
To prevent this, I really like to know if it is possible to disable this button.
Or make a check-in policy or something to prevent this example from happening.
There's an old* saying that technical solutions to social problems rarely work. What you have here is a social problem - Person B is performing an action which is probably not what they intend. The solution should be a social one - encourage all your People to take responsibility for their checkins and above all to think while they're interacting with the shared source control system. All the policies in the world can't substitute for thinking.
Sure, you might say, but it would be nice to have a 'safety catch', or a warning mechanism, or whatever. To which I say - there already is one, and it's being explicitly acknowledged!
Also, what should happen when Person B's changes include and subsume Person A's, so they really do want to throw away the delta contributed by Person A?
(*) I found this reference from 2002, which is practically in Renaissance times for software development - I'm sure there are older
I'm a little confused. I've never seen the "newer version" message-- at least not for .cs files. Are people checking out the files they are editing, or simply marking read-only files as writable so they can make changes?
Make sure in your source control options, that it is set to either automatically check out, or prompt you to check out when files are edited.
Overall, your best bet here is training and the use of frequent forward integration. Essentially, developers should be trained to always "get latest", resolve any conflicts, and then check in. That will eliminate this problem completely.
I'm actually working on a tool that need some configuration before it can be used. To save some time a hard coded some values into the text boxes of the configuration tab, so I don't have to renter them every time I do some testing or debugging.
As we're using TFS to manage our solutions I'm wondering if there is a way to mark those hard coded elements in some way so that TFS or Visual Studio 2008 will remind me to remove/replace them before I do a check in.
UPDATE:
The todo comments won't be a real solution as we're already using it to mark code segments which have to be reworked. We use it as a reminder for longterm tasks. And we have plenty of them so this might become a little bit unclear.
Some options:
write a custom checkin policy
use the existing FxCop checkin policy and write a custom rule (if you're marking TODOs with something that gets actually compiled, like an Attribute)
ditto, but via the StyleCop checkin policy (if your TODOs are source comments)
Probably not the perfect solution, but Visual Studio let's you add TODO comments that may work well enough for you.
You could write a unit test that fails when the hardcoded stuff is found. Obviously, you won't get a reminder before checking in but you do get a build failure afterwards.