I'm interesting with statistic and motivation of using task list in VS. Why are you use it or not? Some people i asked even want a tool, that can synchronize VS ToDo with Outlook. What do you think?
IMO you can use Todos for:
Remember that you must do something like "Todo: implement this interface"
To mark a line/block of code as instruction for another coder if your are code in a team like "Todo: you can use foo instead of bar because ..."
If you review your code you can mark any code that he can be improved like "Todo: use Linq instead of foreach"
You can replace the default tasklist-window from visual studio with plugins:
Tasklist replacement for Visual Studio
http://genne-develop.com/
I used TODO for two purposes:
To mark enhancements that can be
done at a later stage. So whenever,
there is slack time, you can pick
one of them out of your pending TODO
list.
Things that are still need to be done while I am coding - so that I can re-visit those places and fix them. This is something like bookmarks except they are visible to other folks even if I forgot to fix them.
I use TODO comment syntax - it's there in code and not in .suo file as mentioned by Benjol.
I use TODO sparingly - only when I have something that I'm not the master of (something another team-member is working on etc.). I treat it as I treat bugs - max 5 at any time.
If I need scaffolding - I create temporary classes with Fake as a prefix in the class-name.
I guess, I don't want my production code to also act as my scrum-board/task-list.
One thing to be wary of about Task Lists in VS is that they are stored in the .suo file, which (I believe) most people tend to exclude from source control.
Related
Does it use modification timestamp or/and does it check whether the actual content has changed (e.g. by comparing the checksum)?
Edit: I need to know this since I use Git for source control and often change branches. It appears that sometimes even if I change the branch back and force (e.g. from develop to master and then back to develop), the VS rebuilds half of the sources files. I wonder why this happens and why does it happen sometimes and does not happen the other times.
Since Visual Studio is a closed-source project, I bet only developers would be able to give a definite answer on how exactly does it work. However, for my purposes it is enough to test some scenarios.
I have tested it with a small solution and a couple of files in it (one header and two source files). Test results bring to the following conclusion. Visual Studio looks for modification date and time. Even if the file content is the same - it compiles this file and also any other files that include it. If the modification date and time are the same - it won't recompile it even if the content is different. Visual Studio ignores creation and access dates and times.
I'm guessing it uses FileSystemWatcher on the project directories and linked files (if any), just because it's the right way to do this kind of thing.
Some googling finds for more about this class (or just look it up yourself):
http://www.techrepublic.com/article/use-the-net-filesystemwatcher-object-to-monitor-directory-changes-in-c/6165137
http://www.dotnetperls.com/filesystemwatcher
Of course when the source file is open, it's content by the time of editing, as wel as any user changes (even not saved) are loaded in the RAM, but it doesn't compare it to disk content (that'd be too slow), it listens to a system event when the system tells it the file changed.
Update:
Probably not that class itslf, but the Win32 version of it, you know most of the system related .NET functionality classes are just Win32 wrappers.
From this StackOverflow answer: How does FileSystemWatcher work on another computers directory?
I think it wraps this API (not sure): http://msdn.microsoft.com/en-us/library/aa365465.aspx
Update 2:
This is Microsoft's approach to monitor file changes:
http://msdn.microsoft.com/en-us/library/chzww271(v=vs.80).aspx
Update 3
This is an old answer, and it was mentioned above that it was a guess, as Visual Studio is closed source as mentioned in other answers. It's worth mentioning that the accepted answer suggests Visual Studio looks for file modification dates instead, which suggests it doesn't use the approach guessed in this very answer, and that it was wrong.
I hope the reader didn't mind the effort given to rationalize possibilities in this answer (causing reader discomfort or down votes). Keeping it for archival reason only.
When programming a big project, you often need the same pieces of code in different pages. calling methods, returning references, ...
Now, I always need to open a page, and copy paste parts from that. but I'm getting tired of that. There should be a better way to list very often used code. I've read about snippets but they seem a lot of work. How do you manage that?
Snippets are not a lot of work if you use one of the handy snippet-easing extensions to Visual Studio. I happen to like this one http://visualstudiogallery.msdn.microsoft.com/B08B0375-139E-41D7-AF9B-FAEE50F68392 by Matt Manela. Once it's installed, you can right-click a block of code and make it into a snippet. You can also set up replacements just like when you do an if or for block with the built-in snippets.
I thoroughly enjoy the amazing power of LINQPAD (thanks, Joseph Albahari!) and particularly LINQPad's Dump method. Frequently I take an existing Visual Studio project and move it into LINQPad for the sole purpose of adding a couple Dump statements to see what the data looks like--though Visual Studio's data popups are certainly useful, the Dump output is just much easier to digest. To do this, I open each file I need from the current project, copy and paste the individual classes over to LINQPad, add assemblies and using statements, attempt to run so that LINQPad will tell me what I missed, and repeat until I find all the orphan references.
This method seems antithetical to the elegant, streamlined nature of LINQPad. Is there an easier way? Any chance of seeing "Import Project" on LINQPad's File menu any time soon? If not, I may end up writing a utility myself...
If you just want to call .Dump() in VS, check out this:
http://code.google.com/p/linqpadvisualizer/
Importing an entire VS project into LINQPad might be impractical... but I'm going to look in to whether just references can easily be copied over from a .csproj.
LINQPad is awesome and I also manually import projects occasionally. I haven't heard Mr. Albahari mention anything about "Import Project" functionality. And I'd be surprised if he would be interested in implementing something like this anytime soon.
Of course, he is very receptive to suggestions so I recommend posting your idea in his Nutshell forum which he frequents.
Additionally, check out the TypeSerializer in Service Stack libraries. I believe its Dump extension method is wrapped by LINQPad's which then encodes the output in XHTML. It might just be easier for you to use it directly in your code.
I've been looking into obfuscation software, but wondered if one could do it easily with a macro.
If you go into the class diagram in visual studio 2010, you can easily click on class names, properties, fields, etc, and rename them from something meaningful to a, aa, aaa, abc, whatever.
In a really small project, this would be really easy, but not so in larger projects. Could one just write a macro that looped through the set of classes, field, properties, etc. in the class diagram, and renamed them.
I couldn't immediately figure out how (given I haven't written any macros in studio).
Any direction would be helpful. I'm happy to post the final macro code.
Thanks!
Wayne.
Doing this via a macro does not guarantee correctness - many times, VS fails to rename a class/method- what would happen in that case?
Also, "writing" a macro" sounds simple to the ears, but you are essential writing a complete obfuscator - you must decide what you must rename classes/methods to, avoid conflicts, take care of special cases like virtual methods, exclude some classes/methods, and countless other rules.
You are much better off using an obfuscator. Try Crypto Obfuscator.
Any reason why you'd go with a macro instead of Dotfuscator? It's free in VS2010, and has more features with a commercial license.
If you wanted simply to push a button and have your sourcecode obfuscated on-the-fly, you could write a macro. Dotfuscator commercial does boast "Visual Studio Integration".
I have MANY small "Test Projects" where I put together just enough code to prove or disprove some idea I'm working on. Some time (sometimes several months) later, I need to use some of this code. It can take hours searching through poorly named folders to find the gem of code I'm looking for.
It's not enough to be worth a Blog or wiki entry. I'd just like to have something that includes a description, maybe a screen shot and the zip file of the project (or pointer to version control)
Is there a feature I'm missing in Visual Studio to track projects? Is there a template that can be used to search based on project comments etc?
Has anyone come across something like this?
How long before this question gets closed?
Yes, there is such a feature: it's in the "New Project" dialog, and it is called "Name". This will allow you to give your project a meaningful name, that will aid in your finding it later.
There's a related feature, borrowed from the operating system, called "Folders". This allows you to group various projects that are conceptually related, and put them together into a "folder", which you can give a meaningful name related to the conceptual grouping.
The combination of these two will serve all of your needs. The trick is to avoid the mentality which leads to "poorly named folders". Good working habits will save an absurd amount of time in the future, and it really doesn't take that much longer to come up with a meaningful name, rather than TestProject426
Why not use a version control system (like subversion) for that purpose?
You can put your test projects under version control, and by using a log message you have something you can later search for keywords and check out a project in case you need it again.
Once you have put a project under version control, you can remove it from your local disk (so you have less stuff lying around).
If a wiki is really to much hassle, why not search the root of your project folders with something like
findstr /I /S "nifty comment" *.cs
This would just require you to leave a comment with some keywords inside your code.