We Keep Coding

Visual Studio Addon that can warn developers when it detects that certain kind of references have just been added to a project?

We've all done it. We create a new class and type away the constructor adding dependencies and what not. Resharper is there to offer a helping hand and add missing references for us. It's only later on that we realise that we auto-imported references to other parts of our project that we shouldn't have.
So is there an addon for VS that one can configure (using wildcards etc) to have it issue warnings when/if certain .csproj projects are found to contain references to other .csproj projects that they aren't "allowed" to access (architecturally speaking).
Addendum: I am aware that I can achieve this by using pre-build msbuild-logic which parses the .csproj file using regexes and of course this would work. But I just find it kind of ... cumbersome and non-intuitive.

So is there an addon for VS that one can configure (using wildcards
etc) to have it issue warnings when/if certain .csproj projects are
found to contain references to other .csproj projects
AFAIK there's no such kind of extension that does the checking and warning job for you.
The reference to .csproj is actually project references in visual studio.
You can right-click project=>Build Dependencies=>Project Dependencies to check if current project depends on other projects in same solution.But this option will check both project references(add reference to xx.csproj in current.csproj) and project dependencies(ProjectDependencies section in .sln). So only use project references in your solution to manage dependencies between projects, then this option can easily check project references for you.
If the pre-build msbuild-logic which works need similar changes in every project in the solution, maybe Directory.Build.props can make some help if the changes in the project file have similar format. Fetch the pre-build logic into it and put this file in solution or repos directory, it reduces duplicate content in every project file.

How do I install a C# class library in Visual Studio?

I am trying to use a class library which I found on a different question here.
I am quite new to C#, Visual Studio, and OOP in general, so please excuse me if this is not the right question.
I followed the link and downloaded the zip. The help file does not seem to contain any directions on how to get Visual Studio to utilize the library. I figure that I have to tell it to use the library somehow, but I really don't know what to do. Or maybe I need to copy the .dll to a specific folder. I also assume I need using ... in the top of the .cs files that use it.
How can I use this library in a Visual Studio C# project?

You should add a reference.
In the project you are working on, you can add a reference to the dll (or a library) by doing navigating to:
(Project)->References->Add Reference
[You will find Properties, References and [class]files below your project]
According to your question, you should add "UltraID3Lib.dll" to your project references and use it through adding a using on top of your project files like this:
using HundredMilesSoftware.UltraID3Lib;
After you have successfully added the resource you should build the project and it will copy all the necessary files to your output directory (bin/Release or bin/Debug).

Step 1:
Open Debug Folder (you can find it In your project Folder => Bin => Debug). Copy .dll >files there.
Step2:
In Solution Explorer Right Click on References => Add References
Go to Project Tab.
Under the Project Tab you can find Added References (References added In Debug Folder). >Simply select needed references & hit OK. You're done
Happy Coding....! :D

Visual Studio : How to manage code shared between projects

This has probably been posted before, but I'm not sure what search terms to look for!
Quick explanation.
I have code that is shared between a few projects. This code is still work-in-progress itself. The issue is that whenever I need to update this code for whatever, I don't want to have to do it 3 times, this will become a nightmare.
Is there a way to add it to a project, without copying it into the project folder?
i.e. I want the shared class to be linked into my 3 projects as
C:\code repository\sharedclass.cs NOT \eachproject\bin\sharedclass.cs
Do I have to create it as it's own library project? It would be much better if the compiler could compile it as 'external' code.
Cheers.

As others have said, you can simply right-click on your solution in the solution explorer, select Add > Existing Project, and browse to the common project's .csproj file, and it will be included in the solution from its original location.
There are two problems with this however, which may or may not be an issue, depending on the size of your team:
The common project will be included in each solution with a relative path to the solution file (i.e.: ...\CommonProject\Common.csproj). This means all developers have to have the same working file structure or they will get errors when they try to open the main project.
In the scenario that the common project is referenced by multiple projects (say two - A and B) and a developer working on project A has to make changes to the common project as part of their task, there is no way for that developer to know if the changes they have made will break project B without them actually checking out project B and compiling it. As more and more projects reference the common project, the risk of this happening increases to the point where it becomes unmanageable.
Again, as others have said, there is no 'correct' way to do this. However, the approach I have taken is as follows:
Use continuous integration such as Cruise Control to manage the building of the projects and put the common project as a standalone project on the server.
Create a directory under your source control to house built common DLLs. Have this directory checked out on your build machine and whenever the common project builds, it copies the output DLL into the DLL folder and commits these changes to source control.
Use environment variables on all developers' machines and the build server to control the location of the common DLL folder and reference the DLLs using that variable rather than the hard-coded path. (i.e.: rather than C:\Source\MyCommonProjectDLLS\Common.dll, use $(MyCommonLocation)\Common.dll with the variable 'MyCommonLocation' set to C:\Source\MyCommonProjectDLLS)
For any project which references the common DLL, set up a CI trigger on the build server for that project to watch the common DLL folder. Whenever changes are committed to it, the build server should then build all consuming projects.
This immediately lets you know if you are committing breaking changes for any other project. The only drawback is that, in this model, consuming projects are forced to take updates to the common DLL as soon as they are made. An alternative is to version the Common DLL from the source control revision when it is built, and place each version in its own sub directory under the common DLL folder. So you would end up with:
Common DLLs
-1.0.0.1234
-1.0.0.1235
-1.0.0.1236
And so on. The advantage of this is that each project can then choose when to take updates to the common DLL by simply referencing the new version of the code. However, it cuts both ways as this can mean that some projects are left with older versions of the common code for longer than they should, which can increase the work involved when the time comes to finally bring in those changes.

Yes.
You can add a project from anywhere on your hard drive to a solution. So put the shared code into a class library and add that to your three projects.

Microsoft has been supporting an open source project which comes built into VS now, its called NuGet, you can output your shared project as a nuget file and consume it in your other projects.
It will actually deploy all the files you specify in the package upon build.
This is how .Net supports dependencies now. You will notice that even things like EF come through NuGet packages. You can even host it for free on places like MyGet.org I use this and it works quite well.
http://nuget.org/

I use git submodules to achieve this.
Create a new git repository for each module (project) that you want to share between solutions. I usually also include unit tests for that project in a separate project but in the same git repository.
Add a submodule to the git repository of the solution that will use the shared code. Adding a submodule creates a link to a specific commit of an external repository. When the code in the submodule is updated you will be able to pull the updates to your parent solution, which is essentially the same as updating the reference to the submodule commit. I find that the process is easier to visualise using an app like SourceTree.
Adding the submodule and pulling the latest commit will create a copy of the shared project inside the parent solution folder. Import the project into the parent Visual Studio solution by right-clicking on the solution and selecting "Add existing project".
Add a reference to the shared project in the other projects that will be using it by right-clicking on the project and selecting "Add Reference" and finding the shared project in the "Solution" tab.
Now that the shared project is included in the solution you will be able to push and pull changes to the submodule and these changes will automatically be incorporated into the solution. You will also be able to see the changes in other git repositories that reference the submodule.

Yes, put the code which need to be shared in a separate class library project, build it and reference the DLL created from this build into your other projects.

It is better to extract common part into a separate project library and add reference of this project to all the solutions/dependent projects.
Otherwise you can Add code/file/item as Link.

How do I build a multiple project solution in Visual Studio without dependencies between the binaries?

I'm using Visual Studio 2010 Pro to build a solution that contains two projects. Project A contains most of my source code, while Project B is intended to run independently, but must use some of the source code contained in Project A.
Under the current configuration, Project A is contained as a reference within Project B. I'd like to be able to build and maintain versions of each project independently, but it appears that when I build the entire solution, ProjectB.exe cannot run without ProjectA.exe in the same local directory. I would think and hope that when the .exe binaries are compiled that all of their dependencies are packaged within each, but that appears not to be the case. In fact, any attempt to run ProjectB.exe while ProjectA.exe is not present results in a System.IO.FileNotFoundException.
Is there a way to build a version ProjectB.exe that runs independently and avoids code duplication?

In cases where you want common code, the best solution is to break out the common classes into a third assembly to serve as a library. (As per Adriano's suggestion.) The other option he hints at is to use the "as link" option when using the "add existing file" to the second project.
If you don't know where it is, use the "Add existing file" option, then in the dialog box to select the file, the "Add" button has a drop-down selection where you can select "As Linked File" (or something to that effect.)
This allows you to compile the same classes into multiple projects. But keep in mind that the namespacing for the linked file cannot be changed for the second project. If the namespace was "ProjectA.Domain", this is how you need to access it in Project B. This was a useful trick for Silverlight projects back before the multi-platform assemblies were introduced.

If you want to get rid or the dependency on A, you will have to extract the common logic into another project (let's call it C), as Adriano suggested in a comment.
If you need even looser bond between the projects, you can reference A (or C) not as a project, but as a built assembly (.dll file) and check Specific Version reference property to True. Additionally, if your project/codebase structure is more complex, check more assembly sharing options here.

Some options:
The common option: Separate the common code into a third class library (DLL) project. And have both ProjectA and ProjectB dependent on it. The downside is that now in order to run the projects you need two files (the main exe and the dll.) This method is how most software is developed: a single executable and a bunch of DLLs.
The correct option: Separate the common code into a third project and modify the project files to create executables that contain both assemblies (similar to statically linked libraries in unmanaged code.) The downside is that Visual Studio does not support this out of the box and you need to modify the project files which are actually MS-Build definition files to do this.
The ugly option: Create shortcuts for the common files in ProjectA in ProjectB. This is the same as copying the common code to the other project, but you're still left with one source file. The downside is that you have to do this for every file and maintain the same structure in both projects. This is an ugly, if viable, option. Choose one of the others.

Rebuild Visual Studio Library Project Reference

I have a Visual Studio 2010 solution that contains multiple projects. One of these projects is a library, which I have added a method to. Within visual studio I can navigate from the method call in my main project to the method in the library, but when I attempt to build/run the solution it gives me a "does not contain a definition for 'My_Method'". What am I doing wrong?

Seems you are not rebuilding the library project and/or you are referencing the output binary (dll) directly. To solve this you can do one of the following
Make sure you rebuild the library project, and reference the updated binary/dll
Reference the project directly if it's part of your solution, this way, every time you rebuild the dependent project, it will rebuild the library project. The drawback to this is, if you have too many projects, it will slow you (re)builds

It looks as if the library project isnt being rebuilt on each run, assuming that the project reference is correctly added (right click on references -> add reference -> select your library project)
You should make sure that your library is being rebuilt when you run.
To do so :
Right click on your Solution
Click on Configuration manager (approximative translation)
Make sure that the build is checked, if not, check if for the library project