-2

I'm using VS 2017 and I have a number of Utility class files (NetworkLib.cs, ImageLib.cs, etc) that I find myself constantly having to duplicate over and over again when creating new solutions.

Normally, I would just end up creating a dedicated separate solution, NetworkLib.csproj, compiling these into DLL files, and then adding a DLL reference whenever I need them in a new solution, but this isn't ideal for me.

I want to be able to use these in a shared library sense across multiple solution files but also when debugging if I step-into some function NetworkLib.Post() the debugger should step into the appropriate CS files. Additionally, if I make some changes to NetworkLib.cs from Solution1, all other solutions should pick it up on rebuilding.

I've given thought to creating a standalone Utility solution with a NetworkLib csproj, and then adding the project csproj as an existing project to each solution, but not sure if that's a good approach.

I also just read about the "Shared Project" but when I created it (in its own standalone solution) I can't seem to import it into other solutions. When I look in "Shared Projects" tab it just states "No Items Found".

zoombini
  • 124
  • 1
  • 11
  • 1
    This is what Git's Submodules are for. SVN has an equivalent. –  Oct 30 '17 at 17:04
  • You can use external references (svn:externals) in svn. – Ross Bush Oct 30 '17 at 17:05
  • This is all on my private machine, strictly local, I'm not using any source control. – zoombini Oct 30 '17 at 17:09
  • "I've given thought to creating a standalone Utility solution with a NetworkLib csproj, and then adding the project csproj as an existing project to each solution, but not sure if that's a good approach." -- that's what I do – M Y Oct 30 '17 at 17:09
  • In TFS you can probably get away with workspace mapping and/or branching. – Ross Bush Oct 30 '17 at 17:10
  • 4
    "I'm not using any source control" <- you should be using source control, even for private, "strictly local" projects. – crashmstr Oct 30 '17 at 17:14
  • in addition to what @crashmstr says. i'm running teamcity, it's free for the 20 builds and can create and host nuget packages. so you could have a separate project, that builds packages up a nuget package and all your other projects can reference the nuget package. then your changes are isolated until you want to upgrade the other projects with the latest package. – Fran Oct 30 '17 at 17:22
  • Doing any kind of development *without* source control is just begging for trouble. –  Oct 30 '17 at 17:32
  • I know I know. It just seems like in the past, it always gets in my way when I'm trying to do RAD. And I have everything on periodical and incremental local/cloud backups. The only times I find myself using git is when I'm working on a collaborative project. – zoombini Oct 30 '17 at 17:35
  • Just consider it to be collaboration with past and future versions of yourself. – crashmstr Oct 30 '17 at 17:39

2 Answers2

2

Normally, I would just end up creating a dedicated separate solution, NetworkLib.csproj, compiling these into DLL files, and then adding a DLL reference whenever I need them in a new solution

That's the solution. You should publish your shared DLLs into a "shared" folder, somewhere on your desktop/server/network/... and reference these DLLs in your solutions. If you rebuild the shared library, every solution referencing it will automatically use the new version.

To debug external libs, you will need the .pdb file generated alongside with the .dll file. Look here for complete answer : How to debug external class library projects in visual studio?

greyxit
  • 693
  • 3
  • 13
1

Use "Linked items" - where the .csproj project has a soft reference to a *.cs file (or other file type) located anywhere in the filesystem, including outside of your source-control workspace or even a network share - just so long as the file exists your project will build. Use this technique judiciously because it's easy to break CI/CD systems for obvious reasons.

"How to: Add Existing Items to a Project": https://msdn.microsoft.com/en-us/library/9f4t9t92(v=vs.100).aspx

Dai
  • 141,631
  • 28
  • 261
  • 374