No. The binaries generated do not belong in your repository. You need to keep them in some kind of store, but committing them to your history is a bad idea.
All VCS systems I'm aware of have some kind of issue with storing the resulting binaries, although the particular problems will differ depending on the implementation. Some are common to both systems though.
Centralized systems, like TFS, need to frequently compare the files on your local system to the latest version on the server. They have a harder time comparing binaries than than regular text files, so making it constantly check those binaries for changes will slow down your development environment.
Git, on the other hand, uses hashes of the repositories content to determine if a file has changed. (Fun fact: The sha is actually the resulting hash of the entire repo.) That makes the check very quick, but because Git stores the entire file at every commit, instead of just the delta, storing slightly different binaries will bloat the size of your repository greatly.
All systems fall to the same flaw when it comes to storing build outputs in your repository though. Its an utter PITA to have your VCS think something has changed just because you built the solution.
Imagine this scenario happening a dozen times a day:
You pull down the latest source code. You're paranoid, so before changing anything, you build the project to make sure your environment is set up correctly and the last guy to commit didn't break the build. Your VCS now thinks something has changed, even though nothing has.
So, you ignore those pending changes and go on with your work. You're a good developer, so you commit a half dozen small changes and submit them for review. When your coworkers go to review the changes, all they see is a dozen changed binaries. They have to sift through all those files in order to find the one line change you made.
Does this sound efficient to you?