Is Visual Studio just an IDE

Visual Studio is so convenient that after working with it for a while it is difficult to use a different IDE. It has a lot of handy tools and a bunch of plugins available, so practically it has every feature you would need.

On the other hand, whatever language you learn, it is recommended to use command line at the beginning, so you can better understand how it works. C# isn't an exception.

is C# development effectively inseparable from the IDE you use?

Theoretically no, but practically yes. It is possible to write in C# using a text editor and command line, but if you have Visual Studio, you'd never do this. In fact very few programmers have ever executed C# code from command line.

BTW If you feel inconvenient with using foo, you can use the whole path when using a type.

I think you are doing great by splitting your Visual Studio Solution into several Projects that are creating libraries - as you and @antlersoft said in the comment.

This way you can have several other Solutions or even projects that create a standalone binary (like command line exe) referencing these library (Solution Explorer: add reference).

The one thing that git or Visual Studio is not doing for you (as the software architect of one or several solutions) is to untangle the references back and forth between your modules (I use this synonymous to library here).

It is a good idea to have a layered architecture in every bigger software system. When you go and re-architecture your whole system, you can follow these best practices:

• create a namespace for each library that spreads across all the source files in this library
• check the usage: which .cs file (and therefore it's namespace and the library that is compiled as a separate project) uses the class(es) in this library
• assign every namespace/library to one layer (you don't have to give names to the layers); you could do this on paper or use any UML tool that supports component diagrams (including the one in the higher valued Visual Studio Versions; some UML tools call it explicitly layer diagram)

At the end of the day, a good architecture is achieved if no library of a certain layer is using any library in a layer above (no upwards pointing arrows) or the same layer (sidewards pointing arrows). If you can't get this done easily you can go for the weaker form of allowing same layer access.

{ If you download the preview version of Visual Studio "15" (which is a ultimate VS; as long as it is still available) you can open your project and pick New Diagram from the Architecture menu (right next to Tools), chose Layer Diagram and play a little bit around - there is a how-to video linked after you created your first diagram. The following screenshot shows the generated diagram that you get when you drag in some of your libraries from the Solution Explorer, right-click on it and select generate dependencies. }

The following refactorings help you getting there:

• Move a whole class to a different namespace/library
• move a property/field up or down the inheritance hierarchy to move the dependency that originates from accessing this property/field into a different namespace
• move a method up or down the inheritance hierarchy for the same reason
• do some additional classification by a) adding a more general superclass that contains only the a subset of the properties/fields and/or methods or by b) creating more specific subclasses

The process of re-architecturing or refactoring your system to resolve inter-library (package/namespace/module) dependencies that prevent you from reusing your existing software in additional projects has produced a very significant amount of publications. I called it untangling above which is not really the scientific term. One outstanding book reference that covers this (and was written way before git times but is still a very good source) is the Gang-of-Four Book which uses the term software design (as in object oriented analysis and design). You can also find some very good books or articles using re-architecturing or just architecture or refactoring in your favorite book store or search engine.

Just to reconfirm again: once you re-adjusted the project lines this way, each project is a good candidate for also being used as a git repository and you can check it out to any number of additional solutions you want to reuse this library in.