We Keep Coding

How to get access to the files stored on another repository in code

I want to get the access (read) files with text which located on another repository. Is it possible to do at all?
We faced the problem of preserving the history of big files if we place them in the same repo. For every commit it saves another copy of these files in History, which leads to very understandable issues. So we decided to create another repo and store them there. But I have noe exp how can I access it from the code inside the current solution.
I'd be nice to get the filePath of this files in currect solution, so can read them and process.

If you want to reference something, it either needs to be placed alongside your project, or you need a build step that retrieves it and places it somewhere your project can reference.
If these are actual text files you're wanting to read at runtime, those text files need to be discoverable by some means... The fact they're in another repository doesn't help, because that's just another file path that you aren't aware of.
I'd recommend building/publishing your other repository to some discoverable location that your main project can reference at build time or run time.

You can use git clone operation, and just download files to your project. In your main project add rules to .gitingnore to skip those big files from main repo.

You should take a step back and revisit the original problem - large files bogging down the repo. As I noted in comments, what you say (that each such file is copied in every commit) is not accurate; but it is true that large files - especially large binary files - can cause problems in git repos.
And the standard tool to solve those problems is LFS. This creates a separate "LFS repo" and manages its relationship to the base repo automatically, which means questions about how to manually read files from a different repo can be avoided entirely.

Server or Local version when merging?

I started merging 2 branches, resolved all conflicts, now i have a lot of files to check-in. I started to look through all these files and the 1st file shows me this when i click compare to latest version:
I see that there is no changes were made but this file wants to check-in, what to do? I think I need to exclude this file from checking-in (with operation "undo") to keep commit clear. Am I right? Is it normal for operation "merge"? Or I have to commit everything? And why this file is in "check-in" section?

Just undo the change.
There is clearly no functional issue, just a formatting/encoding issue between your codebase and the one you are merging from. Often I see similar when different users select different line ending preferences in their local git configuration. There may be other options that could result in similar behaviour.
See the GitHub article on line endings

Perforce branching

I need to make some test changes on app. The app has version control (by Perforce). How to make a branch (from Perforce) that I don't intend on check back in so that I can do some test modification.

It depends on what you mean by not intending to check it back in. Do you mean never, or just not into the main branch?
If you really just want to make some local changes, and then throw them away, without needed any form of version control on the changes themselves, then you don't need to branch at all. Just sync up, check out what you're changing, and then revert the files afterwards. You can even re-sync the files while you're working (resolving conflicts) if you want to check your local changes in the later build. Just don't submit anything, and you're good (just remember that P4 has no backup of your local changes, so if your PC dies and you didn't back it up, tough).
If you want to be able to switch between your local changes and your normal build, you could 'shelve' your changes, which essentially submits them into P4, but keeps them in a changelist rather than having them actually integrated into the main branch. That way you can revert back to the "real" version of the files, and re-sync your own changes again later - possibly even on a different machine. This is a lightweight way of being able to make local changes, while still having a copy on the P4 server without polluting the depot.
If however you want a proper change-tracked branch of your own, you could integrate the version you want to base it on over into a fresh part of the depot, and then use a client-spec which syncs with that while working on it. You are free to integrate between your branches in either direction, whenever you want. You can branch either the whole tree, or just a sub-set of it, using client-specs to sort out which bits go where.
Alternatively the recent versions of P4 have "streams", which are an alterative way of handling your depot, more suited to running multiple development and release branches in parallel. It's probably not what you're looking for.
In terms of exactly how to do these things, I recommend checking out P4's website, which has pretty good documentation and lots of tutorials.

Actually you do not need to create new branch for test your change. Just make a client containing your app and sync your local computer. After that you need to change on specific files or add new or delete by shelve. Then just build your app with shelve. If you find your change at build artifact and if you think that your change is correct then you can submit it to perforce.

The easiest thing is to go to the "steams" tab. Create a new stream and check the check box for branch from where you want to branch from. Super easy.

Compare (and merge) two VS C# projects

I have two VS C# projects (specifically, for an Outlook plugin) that I believe to be very similar with the exception of perhaps 100 lines of code. I'm slightly worried that there might be other configuration options for the project that are different, so I'd like to compare those two.
What is the best way to see the differences between the two codebases?
I've tried putting the two projects in parallel directories and using diff, but since the projects are named differently, some of the files don't match up. I'm just wondering if there's an easier way to do this?

It sounds like you need something like WinMerge to go through and point out the differences between the two projects. It's free, and I know you can compare folder contents with WinMerge, so that's probably a good place to start. Run WinMerge on the project folders and it should generate a detailed comparison outlining the differences between the files.
See this tutorial on comparing folders:
http://manual.winmerge.org/CompareDirs.html

I strongly recommend Code Compare (not affiliated, just a happy user) for this kind of job - there is a free version and a more advanced commercial version.
It integrates nicely with VS and has syntax highlighting for C#, C/C++ etc.

One way: Make copies of both projects, rename the files and folders in one to match the files and folders in the other, then use your favorite folder compare tool to compare the two.
This won't help you unless there was a true copy-and-paste relationship between the two projects.
The better way would be to use refactoring. After creating unit tests for both projects and achieving an adequate level of code coverage, go class by class and method by method using refactoring to try to make pairs of methods identical. You may then identify methods that should be pulled into base classes or moved into other classes.
Eventually, you may find pairs of classes which are identical. Move those classes into a common library, then rename all uses of one of the classes to be a use of the other. Then delete the one no longer used.
Repeat until there is no more duplication.

If you've got modifications like renames or partial code moves, importing both versions into a single git repository (as two different commits of a single directory) could help. Git tracks contents of files, not the files themselves, so it is possible to find out e.g. a function that has been moved from one file to another.

Managing shared binary dependencies for multiple solutions

Ok we have a number of solutions all with a lot of shared binaries:
what we do is the following.
In a shared drive we have this following layout where there is a directory for every binary dependency and a sub directory for every version
BinaryDep1
-----------Volatile
-----------1.0
-----------1.1
-----------1.2
BinaryDep3
-----------Volatile
-----------1.0
-----------1.1
-----------2.2
BinaryDep3
-----------Volatile
-----------1.0
-----------1.1
-----------1.2
In our solutions we have a XML file that lists out all of the dependencies and versions. We have a script that then goes tothe shared drive and download the dependencies into a sub folder of a solution called /ext
This works very well but has a few flaws that we are looking to improve and i wanted to get people's feedback.
We have many solutions so if they all depend on the same version of a binary dependency then we get one copy per solution (as its supposed to be self contained). So if i have 5 solutions that all depend on Syncfusion, i get 5 copies of syncfusion on my desktop. The two issues here are 1) slow download time (5x more than i need to) and takes up lots of disk space.
We like the model where have a local sub directory per solution with /ext so we never have to change project references but these seem like competing forces.
any ideas on how to normalize teh download so we are not downloading 5x the data and same the disk size without having to go to manually updating project references where i have to change reference in VS for every version upgrade.

What about the same struture in all developer machines?
Like:
d:/projects
d:/projects/ext (the shared libraries you need here)
d:/projects/project1
d:/projects/project2
d:/projects/project3
d:/projects/project4
...
ps: I love conventions.

You may want to have a look at DEVPATH.
Other StackOverflow reference : Support for DEVPATH

Is any reason for not putting shared assemblies to GAC?